Chapter 1. The Current State of Web Polyfills
Like many things in the world of technology, the practice of polyfilling is far older than its name. And even though the term itself is a recent addition to the web platform canon, as long as we’ve had multiple browsers with varying and inconsistent implementations of web platform features—which is to say, always—we’ve had the practice of polyfilling in one form or another. Every developer who mucks with the string prototype to add a trim() function for oldIE is creating a polyfill, as is the developer who lovingly adds a homegrown window.addEventListner() function to IE8 in the hopes of simplifying her event management code. As a practice, polyfilling has been around for a while, but its naming coincides with a time in which its use on the Web exploded: the advent of HTML5.
Polyfilling: Past, Present, and Future
Much as the term Ajax was minted at a time when JavaScript and XHR apps were a daily occurrence, the practice of polyfilling was given a name at a time when developers were increasingly looking at HTML5 and thinking, “How can I get some of that in my site?” Part of the answer at the time was polyfilling and, in many ways, it’s been an adequate answer. For the last several years, polyfilling has allowed developers to target multiple browsers with new technologies, while not leaving those oldIE users behind. This is polyfilling’s past, and also its present. We still live in a world where the predominant use case for a polyfill is ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access