Lea Verou argues polyfills are a net positive for the web platform

Confession: your last "shim" is probably still in production, silently duct-taping some API you needed six months before every engine shipped it. (We've all done it. It's fine. It's not fine.) Lea Verou has a new post out arguing you should stop apologising for it, because polyfilling the web is a feature, not a bug. And she is throwing hands with a WHATWG spec editor to do it.

What set her off

Per the source, Verou's post is a response to Anne van Kesteren, the main active editor of most WHATWG specs (HTML, DOM, Fetch, import maps) and a WebKit engineer at Apple, who at a recent WHATWG meeting said polyfilling is harmful. His actual words in the post: "I would much rather people write a library that demonstrates the need for something as opposed to something that attempts to mimic the exact API shape of a proposal while simultaneously trampling all over our design flexibility."

The trigger is Verou's own WHATWG proposal to extend mutation observers to observe shadow root attachment. She wanted the polyfill route to stay open for it. Anne pushed back on the whole class of thing.

Two things to note, because they matter for how you read the rest of this piece. Per the source, Verou says she checked in the WHATWG Matrix room and privately, and Anne's view is not the broader committee consensus, though views on polyfills were more ambivalent than she expected. She also cites her own 2011 JSConf EU talk on the same topic, so this is not a Tuesday-afternoon hot take. Fifteen years of holding the same position gets you a hearing.

The mechanism, not the vibe

Here's the rad part of the argument. Verou goes straight at the mechanism.

Per the source, polyfills decouple API design from implementation. That is the whole trick. When authors code against a standardised surface, swapping the underlying implementation is cheap, and the coupling flips from O(M × N) authors-times-implementations to O(1). Every polyfill you ship against a real spec is a bet that pays off the moment browsers implement it: the shim goes away, the code stays.

Then she names the historical receipts. Per the source: IE7.js. html5shiv. That is a lot of the reason you got to use anything modern during the IE era at all. She frames these as the counterweight to market dominance, the thing that let authors keep moving when a vendor did not want to.

And here is the claim I did not see coming, which is actually the sharpest bit. Per the source, native implementations end up more performant, more accessible and more i18n-inclusive than the userland libraries that precede them. So the polyfill is not a substitute for the real thing. It is the demand signal that gets you the real thing. In her words: "Demonstrating developer need is exactly what drives implementor interest in the first place!"

The line that will get quoted

The image she reaches for is worth the price of the post on its own. Per the source: "Assigning blame to polyfills is like blaming car accidents on the ambulances that show up on the scene."

Read that twice. The framing is that a popular polyfill did not cause the design pressure on the standards process. It responded to it. Per the source: "A popular polyfill is a consequence." If a shim ends up locking in an ugly API shape, that is a process failure. The standards track was too slow, or design validation happened in the wrong order. Blame the process, not the shim.

She has a counterexample teed up too. Per the source, AppCache is the canonical case of shipping a native API before the design was validated in the wild; Service Workers replaced it once the real shape was known. That is not an argument against native APIs. It is an argument for using userland to validate before you paint yourself into a spec corner.

Where Anne's point still lands

Fair is fair. Anne's concern in the quoted line is not silly. A polyfill that mirrors an in-flight proposal's exact API shape does hand designers a fait accompli, and once developers ship against that shape, moving it hurts. Per the source, Verou's answer is that this is a process failure and not a polyfill failure: the shape got locked in because the standards track was too slow to pressure-test alternatives, not because the shim existed. Different fix. Same symptom.

The disagreement, in other words, is not really "polyfills good vs polyfills bad." It is about which layer eats the risk of a bad API: the vendors' design flexibility, or the authors trying to ship today. Verou is voting for the authors, loudly, and reminding the room that authors shipping today is what tells vendors what to design next.

Score

The web still moves me a little on this one. The bit I keep thinking about is her "the first implementation is the hardest" beat, because it is exactly why the modern web looks the way it does. Someone shimmed the shape, developers voted with their imports, and browsers noticed. A verdict, in the score-out-of-ten register we like around here: 8.5 out of 10. A point off because the piece would land harder with a paragraph on the failure mode Anne is actually worried about, the polyfill that mimics an unfinished proposal, and how you would police that without banning the tool that got us most of the modern platform in the first place.