In defense of polyfills • Lea Verou

In defense of polyfills

13 July 2026

13 min read

On this page

It’s not the polyfills<br>Polyfills decouple API design from implementation<br>Are separate namespaces the solution?<br>Is dropping feature detection the solution?<br>Are ponyfills the solution?<br>Do polyfills discourage native implementations?<br>Polyfills only get in the way when the standards process failsThe WHATWG process invites these failures

Polyfills restore power balance in the ecosystem<br>Polyfills make the Web faster, inclusive, and more robust<br>Can we stop trying to solve the wrong problem?

A highly influential spec editor expressed the opinion that polyfilling is harmful. I beg to differ.

Web Standards,

Polyfills,

Web Platform

If you’re a web developer, you may find the title baffling.<br>“Polyfills need defending? Who’s against them?!” you might ask.

Two weeks ago, I’d be in the same boat.

Polyfills and I go way back.<br>I dug up a JSConf EU talk of mine from 2011 on exactly this topic.

Trying not to think about how young I look here 😅

One of the few opinions I have held strongly over the years is that polyfills are a net positive for the Web , and the good outweighs the rare failure cases where polyfills became too popular, too soon, and restricted the design space for the native API.

As with most things in life, it’s all about the cost-benefit.<br>We don’t stop flying planes because crashes happen.<br>We do a post-mortem and figure out how we can prevent the same accident from happening again.<br>And crucially, the point of a post-mortem is to find the root cause — not to ground the entire fleet.

Don’t get me wrong, concerns about polyfills are well-intentioned.<br>They come from implementors and standards folks who want to preserve the design flexibility to build the best API surface possible — a goal I share deeply.<br>Being both a spec editor and a library author, striking that balance is something I navigate all the time.

Still, I was under the impression that seeing polyfills as a net positive was the consensus view of the web standards community as a whole.<br>That while we may not have consensus on the specific tradeoffs or solutions, we see polyfilling as a good thing and we generally do want web platform features to be polyfillable.

So, you can imagine my surprise when in a recent WHATWG meeting where I presented a proposal for extending mutation observers to observe shadow root attachment, Anne van Kesteren expressed the view that polyfilling is harmful .

It’s important to note that Anne is not some rando.<br>He is the main active editor of most WHATWG specs (HTML, DOM, Fetch, import maps, etc.), a WebKit engineer at Apple, and has tremendous overall influence on the direction of the Web platform.

I had to find out if Anne’s comment reflected broader committee consensus, so<br>I brought the topic up in the WHATWG Matrix and asked some folks privately.

Thankfully, it became clear that no, Anne’s comment did not reflect broader consensus (😮‍💨), but some of the views expressed about polyfills were more ambivalent than I’d have expected.

As I said, these concerns are well-intentioned — but I believe they are generally misplaced.<br>Most fail to consider the system holistically, and especially the human factors that drive developer behavior.

Let me explain.

It’s not the polyfills

Authors want to use native behavior when it exists, without breakage when it doesn’t.<br>That’s the crux of it.<br>That’s what restricts design flexibility.

Whenever this happens too early, by too many people, you can have a problem.<br>It doesn’t matter whether the code using it is a polyfill, a fallback, “progressive enhancement” or “graceful degradation”.

Fundamentally, every pattern that uses the native feature when it exists and a userland implementation (or even nothing) when it doesn’t risks breakage if the feature changes in a way that is incompatible with that usage.

This includes:

Using CSS properties for progressive enhancement, accepting that they won’t work everywhere

CSS fallbacks via the cascade or @supports

Conditional imports after feature detection

Using a modern HTML element, with a script that converts it to (or wraps it with) a web component if not supported

Build tools that include fallbacks alongside the native feature

JS let foo = nativeThing?.() ?? fallbackThing()

etc etc

In all of these cases, if the native API were to change in a way incompatible with the fallback usage, stuff could break.

Eliminating polyfills does not eliminate the need for them.

The benefit of polyfills over the techniques above is author-facing: polyfills are portable, maintainable, and typically more correct than ad-hoc fallbacks.

When a bug is identified in a polyfill, it can be fixed centrally.<br>When a bug is identified in an ad-hoc fallback strategy, good luck finding all the callsites and fixing them.

Bottom line: eliminating polyfills does not eliminate the need for them and all other avenues of satisfying that need are...