--- title: "Baseline is a delete list." date: 2026-08-21 url: https://remiam.co.uk/notes/baseline-is-a-delete-list tags: [Web, Tooling, Performance] read_time_minutes: 6 description: "Baseline is usually read as permission to use new web features. Read it the other way round and it becomes a list of dependencies you can delete. How we run the audit." --- # Baseline is a delete list. *Published 2026-08-21 · 6 min read · by Liam (Remiam)* Smashing Magazine published a piece on 7 August arguing that Baseline is best read as an audit rubric for your dependencies rather than a permission slip for new syntax. That is the right way round. Most codebases are still shipping shims for problems the browser solved eighteen months ago. Smashing Magazine ran a piece on 7 August called How Baseline Can Help You Ship Less JavaScript (Smashing Magazine, 2026). The argument is a small inversion and a good one. Baseline is normally read as a permission slip: this feature is safe now, you may use it. Read it the other way round and it becomes something more useful. It is a list of things you are still paying for that the browser now does for free. We run client systems that were specified two, three, five years ago. Every one of them carries a layer of libraries chosen to paper over a gap in the platform. The gap closes quietly. The library stays, because nothing ever forces the question. ## What actually landed Baseline tracks when a feature is supported across the major browser engines. Newly available means it has just crossed that line everywhere. Widely available means it has held for roughly two and a half years, which is the point most teams can stop thinking about it. A few things crossed recently that matter for the kind of work we do. - CSS anchor positioning reached Baseline Newly available in January 2026 when Firefox 147 shipped it. Tooltips, dropdowns, popovers, anything that has to sit next to something else and stay there while the page scrolls. - Container style queries reached Baseline Newly available in May 2026 with Firefox 151, and Chrome 148 shipped name-only container queries the same month (web.dev, 2026). Components can now respond to the container they are in rather than the viewport. - Temporal, the replacement for the Date object, hit TC39 Stage 4 in March 2026 and is part of the ES2026 specification. Time zones and durations without a date library. - The Navigation API gives single-page apps an event-driven way to intercept navigations, in place of the popstate and hashchange patterns most routers were built around. The Smashing piece puts a figure on one cluster of that. The dialog element, the Popover API and anchor positioning together replace shims worth roughly 24 KB gzipped, and the native versions come with better accessibility defaults than most of what they replace (Smashing Magazine, 2026). Twenty-four kilobytes is not a headline. It is also three fewer things to keep patched. > A dependency is not a one-off cost. It is a subscription you forgot you signed, paid in upgrades, audits and the odd Friday afternoon. ## The dependency that outlived its problem The reason this accumulates is that nobody is assigned to notice. A library gets added on a Tuesday to solve a real problem. It works. It goes into the lockfile and from that moment it is infrastructure. Two years later the platform grew the feature, and the only signal you get is a security advisory or a peer dependency conflict during an unrelated upgrade. The cost is rarely the bytes. It is that every dependency has an opinion about your build, a release cadence you do not control, and a maintainer who may or may not still be interested. A date library that ships a breaking change is a sprint. Temporal is a language feature. It does not have a roadmap that can surprise you. ## How we run the audit This is an hour of work once a year per codebase, and it is worth booking. We do it in the same week as the dependency upgrade pass, because the two feed each other. - Open package.json and read it top to bottom. Not the lockfile, the direct dependencies. For each one, write down in a sentence what it is there for. - Cross-check each of those sentences against Baseline. If the platform now does it, mark the package as a candidate. - Sort candidates by how deeply they are wired in. A positioning library used in four places is a morning. A date library threaded through every model is not this quarter, and that is a fine answer. - Delete the easy ones and ship them. Leave the hard ones on a list with a date on it. An audit with no written outcome is a conversation. - Check your analytics before you commit. Baseline describes the major engines, not your users. ## The part people get wrong Newly available is not the same as safe for your traffic. It means the feature has just arrived in the current version of every major engine. It says nothing about the two-year-old Android handset in a warehouse, or the locked-down tablet bolted to a wall in a venue, which is a real constraint on half the installations we build. Widely available is the conservative line, and for anything running on hardware we do not control we hold to it. So the honest version is narrower than the headline. Baseline is not a green light. It is a prompt to go and check something you last checked in 2023, on the devices your users actually hold. Most of the time the answer will be that you can delete something, and the codebase gets a little smaller for the first time in a while. ## References 1. [Smashing Magazine, How Baseline Can Help You Ship Less JavaScript, 2026](https://www.smashingmagazine.com/2026/08/how-baseline-can-help-ship-less-javascript/) 2. [web.dev, Baseline monthly digest, May 2026](https://web.dev/blog/baseline-digest-may-2026) 3. [web.dev, Baseline (overview and definitions)](https://web.dev/baseline) 4. [MDN Web Docs, Baseline (compatibility) glossary entry](https://developer.mozilla.org/en-US/docs/Glossary/Baseline/Compatibility)