In the early to mid 2000’s, a surge of Web 2.0 sites opened a new use case for the web. Dynamic, user-driven, and real-time—social media platforms, bookmarking services, photo sharing services, et. al—these new applications demanded something different from the web.

Discussion around how web technologies like HTML and CSS could adapt to the needs of web applications eventually caused a fissure in the web standards process, after a group of browser makers and standards advocates split from the W3C and created the WHATWG. By the time those two groups came back together in the 2010’s, they had produced what would become known as HTML5 and CSS3, a varied set of new standards meant to address the needs of Web 2.0. It was a major step towards recognizing the web as a runtime for fully featured applications rather than just static documents.

As the joint effort of the WHATWG and W3C propelled HTML and CSS into a new era, developers and web builders eagerly looked to begin using these technologies as soon as possible. In the midst of this excitement, some developers began creating a clever new type of scripts, inspired by the classic programming concept of a ‘shim.’ These scripts mimicked these new HTML and CSS features using JavaScript, bridging the divide for browsers that lagged behind in support. This innovation allowed web developers to stay on the cutting edge, even when browsers couldn’t.

One of the more popular of these shims was HTML5shiv. After the release of new elements in HTML via the HTML5 specification, some developers noticed that they couldn’t use that HTML because Internet Explorer wasn’t able to recognize the element as valid. Developer Sjoerd Visscher, however, suggested a fairly simple workaround that only required one line of JavaScript that he had been holding on to for about half a decade.

That made HTML5 adoption considerably easier. In early 2008, Jon Resig, the creator of jQuery, took to his blog to share this tip with the world. In a slight oversight, he used the name shiv instead of the correct term, shim. But the name stuck. By the following year, developer and standards advocate Remy Sharp had evolved this small piece of code into a downloadable, and widely shared script that came to be known as html5shiv. That package was instrumental in growing the adoption of HTML5 features, even when older versions of Internet Explorer were involved.

Html5shiv was soon joined by an array of other shims, each addressing different gaps in technologies introduced through web standards. These shims collectively formed a robust support net, enabling smoother transitions and faster adoption of new technologies. And they fostered a culture of collective problem solving and open innovation that was essential for the spread of new features and technology. These were more than mere patches. They showcased the adaptability of the tech community in the face of major changes.

It was around this time that Faruk Ates left Apple, looking for his next challenge. During his time there, he had been a UI engineer working for tools like MobileMe, but had recently turned more of his attention to the web. In the months during this hiatus, he began creating a JavaScript library that made it possible to detect if browsers supported these new, modern HTML and CSS features. It was called Modernizr.

This had been tried before. In the early days of the web, when Netscape and Internet Explorer clashed in an feature-driven arms race for market dominance. Certain features soon become exclusive to one browser and absent in another. Developers began crafting scripts capable of identifying a site visitor’s browser, tailoring their experience based on what that browser made available, or even redirecting them to an entirely different page. This approach was undeniably divisive and clunky, but it was sometimes necessary.

Modernizer operated in another way entirely. It detected features, not browsers. The script was not at all concerned with what browser it was running on. Instead, it quickly assessed what modern CSS and HTML features the current site visitor could use. Based on that, Modernizr added useful hooks enabling developers to generate code aimed specifically at those features, and fallbacks to everyone else.

In the months that followed, Ates was joined by Paul Irish from Google Chrome and developer Ben Alman to create a more complete version of the Modernizr library. Contained within the library was a simple idea—feature detection over browser detection—but it represented a profound shift in thinking. Developers could more confidently embrace what was new, and target implementations based on available features without the need to hold some mental map of each browsers’ capabilities. And if all else failed, they could provide fallbacks for visitors without the latest feature.

As thinking evolved, and the web advanced, so did shims. Some scripts would do more than just fill the gap of some old feature. They would use a library like Modernizr to try and detect if a feature was available or not. If the feature wasn’t there, the script would go ahead and load the shim. But if was, the script would simply do nothing at all.

In 2010, Remy Sharp gave that kind of script a name. It was called a polyfill. Writing in his blog, Sharp provided an explanation for the word he coined.

I wanted a word that was simple to say, and could conjure up a vague idea of what this thing would do. Polyfill just kind of came to me, but it fitted my requirements. Poly meaning it could be solved using any number of techniques – it wasn’t limited to just being done using JavaScript, and fill would fill the hole in the browser where the technology needed to be.

A couple of years later, Sharp would refine the definition of a polyfill in the second edition of Introducing HTML5, which he co-wrote alongside Bruce Lawson. In that book, the authors drew a more distinct line in the sand between polyfills and shims.

What makes a polyfill different from the techniques we have already, like a shim, is this: if you removed the polyfill script, your code would continue to work, without any changes required in spite of the polyfill being removed.

The introduction of the term ‘polyfill’ marked a significant milestone in web development. It gave space to browser to continue to evolve. As polyfills became standard practice, they have significantly enhanced the flexibility and compatibility of web applications across different browsers. And now browsers build features with polyfills in mind, using them as a way to prove out new additions to web technologies in a practical, forward-thinking way.