Stop shipping the polyfill you no longer need

The most valuable thing about the Web Platform Baseline project is not any individual feature. It is that a question which used to take twenty minutes of squinting at a support matrix now takes five seconds.

A feature is Baseline Newly available when it works across Chrome on desktop and Android, Edge, Firefox on desktop and Android, and Safari on macOS and iOS. One label. Either it is interoperable everywhere that matters or it is not.

That sounds administrative. It has a practical consequence most teams have not acted on.

The accumulated workarounds

Front-end codebases accrete compatibility debt in a way that is almost invisible, because each individual piece was correct when added.

A flexbox hack for an old Safari bug. A polyfill for something now native. A JavaScript library doing what CSS does now. A build target set to a browser version nobody has used in four years, dragging transpilation and shims through every bundle. A vendor-prefixed property kept "just in case".

None of it is wrong. All of it is dead weight, and it compounds: larger bundles, slower builds, more surface area, and a codebase where nobody is sure which workarounds are still load-bearing.

The reason it never gets cleaned is that removing a workaround feels risky and produces no feature. Baseline makes the risk assessment cheap enough to actually do.

What is now safe that changes real code

Several things reached interoperability recently that replace a genuine dependency rather than adding a nicety.

Container queries let a component respond to its own container rather than the viewport — which is what component-based design wanted all along, and the reason a lot of teams shipped JavaScript resize observers. Style queries extend that further.

Anchor positioning handles tooltips, popovers and dropdowns natively. That is a category where most teams pulled in a positioning library, and those libraries are not small.

shape() gives a readable way to define complex paths for clip-path and offset-path, replacing the write-only string syntax that made these effects unmaintainable.

image-rendering controls the scaling algorithm — genuinely useful for pixel art, QR codes and low-resolution images where interpolation ruins the thing.

The pattern is consistent: each replaces a JavaScript dependency with a platform feature. That is fewer bytes, less to maintain, and behaviour that survives your framework being replaced.

The audit worth an afternoon

This is the rare piece of maintenance with a clear method and a visible payoff.

Look at your build targets first. If you are transpiling for browsers with negligible share in your actual analytics, you are paying a bundle-size tax on every user to serve a population that may not exist. Check your own numbers rather than a default config.

Then list your front-end dependencies and ask which exist to paper over a browser gap. Positioning libraries, smooth-scroll polyfills, resize observers, focus-visible shims, CSS-in-JS features now covered by nesting and custom properties — check each against Baseline.

Then remove one and see what breaks. Not all of them at once.

The caveat that matters

Baseline says a feature works in current versions of the core browsers. It does not say every user has a current browser.

"Newly available" and "Widely available" are different — the latter means the feature has been interoperable for long enough that stragglers have largely updated. For a product whose users are on recent devices, Newly available is usually fine. For a product used on old Android phones on cheap data plans, it is not, and that is a real population in a lot of markets.

So the honest rule is to check Baseline and your own analytics. The label answers whether the browsers support it. Only your data answers whether your users are on those browsers.

That combination is still dramatically faster than what we used to do, which was to guess conservatively and carry the workaround forever.