Your Design System Still Ships a JavaScript Library CSS Replaced Years Ago
Somewhere in your component library right now is a positioning library — Popper, Floating UI, something homegrown — calculating where a tooltip should render relative to its trigger, recalculating on every scroll and resize, shipping its own bundle weight to solve a problem the browser has been able to solve on its own since Safari 26 landed anchor positioning support. Nobody's going to rip it out this quarter. It works. That's exactly the problem — "it works" is doing a lot of quiet, expensive covering for "it's obsolete."
This isn't a hypothetical. It's the predictable output of how design systems actually get built: architected once, under real constraints, then left running on those constraints long after the platform underneath them changed. And the platform has been changing fast enough, and specifically enough, that most systems built even two years ago are now carrying real, measurable debt they haven't been audited for — because the workaround doesn't throw an error. It just sits there, doing in JavaScript what CSS can now do for free.
What Interop 2026 Actually Shipped
Interop is the annual collaboration between WebKit, Chrome, Firefox, Microsoft, and Igalia to converge browser behavior on a shared set of features, and Interop 2026 covers 20 focus areas — 15 new, five carried over from 2025 because they weren't fully interoperable yet. The carryover list is the more interesting one for design systems specifically: anchor positioning, scroll-driven animations, view transitions, scroll snap, and custom highlights — all features that, as of Interop 2025, were close enough to universal support to be worth finishing, but not yet solid enough to build production systems on without a fallback.
That gap is closing in real time. Anchor positioning shipped in Safari 26; Firefox landed it behind a flag with version 145, putting all three major engines within reach of full support inside a single release cycle. Container queries — the size-based kind, not this year's newer container style queries focus area — aren't new at all. They reached full cross-browser Baseline status back in 2023: Chrome 105 in August 2022, Safari 16 the following month, Firefox 110 by February 2023. That's three-plus years a feature has been safely usable in production, and a large share of component libraries built in that window still ship a JavaScript-driven responsive-breakpoint system instead, because the architecture decision was made before the platform caught up and nobody's gone back to revisit it since.
Why "It Still Works" Is the Wrong Test
The reason this debt survives audit cycles is that design system health checks almost never ask the right question. They check for broken components, accessibility regressions, visual drift from the source Figma file, token consistency across platforms. They don't typically ask "is this JavaScript still necessary," because a JS-based tooltip positioning library that's functioning correctly doesn't fail any of those checks. It just costs more than it needs to — more bundle weight shipped to every user, more runtime computation on every scroll and resize event, more surface area for the exact class of positioning bugs (a tooltip clipped at a viewport edge, a popover that doesn't reposition on a rotated device) that native anchor positioning was specifically built to eliminate at the browser level instead of the application level.
The cost is invisible in the way most technical debt is invisible: not broken, just heavier than it should be, in a hundred places nobody's individually motivated to fix because each one, alone, looks trivial. A tooltip library is a few kilobytes. A scroll-animation library handling effects that animation-timeline: scroll() now does natively is a few more. None of it triggers a postmortem. All of it adds up to a design system quietly carrying JavaScript for problems that stopped being JavaScript problems, in some cases, years ago.
The Replatforming Question Nobody's Scheduling
Design system teams schedule audits for token drift, for accessibility compliance, for component adoption rates across product teams — the things that show up in dashboards and quarterly reviews. Almost none schedule a recurring audit for "which parts of our architecture were built around a browser limitation that no longer exists." That's a different kind of check, and it requires someone to actually track what Interop ships each year against what the system currently does in userland — which is exactly the kind of unglamorous, cross-cutting maintenance work that gets deprioritized in favor of new component requests, because replacing a working library with a native CSS feature doesn't ship a visible feature. It ships a smaller bundle and a shorter changelog entry nobody outside the team will read.
That's a mistake, and it compounds specifically because Interop's whole design is annual and cumulative. Each year's carryover list is next year's near-certain shipped feature — anchor positioning is not going to un-ship from Safari 26 or arrive-then-vanish from Firefox. The trajectory is one direction. A system that reviews its JavaScript-dependency list against the current year's Interop focus areas once a year would catch this drift before it's three years deep. A system that never runs that check will keep shipping the 2022 solution to a 2026 problem indefinitely, because nothing in its normal review cycle will ever surface the question.
What an Actual Audit Looks Like
The check itself is not complicated, which is part of why it's worth doing rather than treating as aspirational. Grep the component library for positioning libraries and cross-reference against current anchor positioning support. Grep for scroll-triggered animation libraries and cross-reference against animation-timeline: scroll() and view transitions support. Grep for JavaScript-driven responsive logic — media-query polyfills, resize-observer-based breakpoint systems — and cross-reference against container query and container style query support, given the size-based version has been safely production-ready since 2023 and the newer style-query variant is this year's Interop focus. None of this requires a rewrite sprint. It requires someone to run the comparison and file the tickets, the same unglamorous work that keeps a codebase from becoming an archaeology site.
The systems that will feel this gap first aren't the ones that never modernize — those at least know what they're carrying. It's the systems that modernized once, confidently, a few years ago, and assumed the platform would stay roughly where it was. It didn't. It rarely does. Interop ships every year specifically so that assumption keeps quietly going stale, one focus area at a time, whether or not anyone on the design system team is watching for it.
Related: our earlier piece on design system adoption failure covers the organizational side of this — the same neglect pattern, one layer up from the code.