Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

HTML5 and polyfills – one script to rule them all?

DZone's Guide to

HTML5 and polyfills – one script to rule them all?

· Web Dev Zone
Free Resource

Learn how to build modern digital experience apps with Crafter CMS. Download this eBook now. Brought to you in partnership with Crafter Software

A common discussion about HTML5 and whether to use it, and touched on in the HTML5 Hurdles article, is usually about fallback support and making it work in every web browser. But do we really need that?

Polyfills

When it comes to making various things offered in HTML5 working in older web browsers, both new elements with connected functionality and HTML5 APIs, we have the option of using polyfills. It’s a smart approach which will make their existence automatically obsolete over time as people upgrade their web browser to later versions.

It’s a mindset I really approach, as opposed to writing your own libraries where you need to change the syntax from the default API one offered. I personally think respecting native APIs is important, both for code understanding and handover. Also, I don’t like introducing syntax dependency on a library/syntax if not completely necessary.

The beauty of conversation

While I think polyfills definitely play their part in offering HTML5 experiences for older web browsers, another thing I think it’s important to reflect on is whether we should really try and give the same experience for every web browsers. While polyfills are great, we’re giving all this extra JavaScript to already weak and slow web browsers (meaning mostly older versions of Internet Explorer), and even if they do manage to render things/make the APIs work I’m not convinced it is always for the best.

I think we need take the varying support and also speed of web browsers into consideration, and focus more on offering the best experiences for the latest web browsers who can give that. Same goes for mobile: while the technical support might be there, it doesn’t necessarily mean that the performance is up to the task.

Somewhere I get the feeling we have sort of missed out on one of the ideas of progressive enhancement, when we offer something basic for everyone and then enhance it for those web browsers which have better support. I think that offering a poor user experience on older/weaker web browsers can do more harm than good, and that those users would be better off with a basic well-working version instead.

I find the beauty of coding is like the beauty of conversation – it completely depends on who you are talking with. You adapt your words, sentences and topics through the interaction with the other person(s). Same with web browsers. Evaluate the support for code, performance and other upsides and shortcomings, and then deliver the best based on that.

Choose wisely

To summarize: I’m not saying that polyfills are the salvation, nor something to shy away from. But consider your specific situation: what are you building, how should it work and what is the best time, money and effort spent in creating that end user experience. There’s no ultimate solution for everything, but rather an opportunity to make each thing you work on as special as it can be.

Disclaimer: This blog post is based on talks I have had with Christian Heilmann, and consider that as an inspiration.

Crafter is a modern CMS platform for building modern websites and content-rich digital experiences. Download this eBook now. Brought to you in partnership with Crafter Software.

Topics:

Published at DZone with permission of Robert Nyman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}