Every product team runs a silent, constant calculation: “Do we build this from scratch, or do we pull in a library?”
For a decade, the answer was almost always the latter. If you needed a date picker, you installed Moment.js or date-fns. If you needed a tooltip that didn’t clip off the edge of the screen, you brought in Popper.js or Floating UI. If you needed a modal that actually trapped focus for accessibility, you added a focus-trap library and a body-scroll-lock utility. These weren’t just convenience choices; they were survival strategies. The web platform was too fragmented, and the “browser gaps” were too wide to risk a custom implementation that would break for 15% of your users on an outdated version of Safari.
But the calculus is shifting. We are entering an era where the Baseline web platform has turned the vague promise of “the platform will eventually do this” into a trackable, stage-gated signal. For product designers and engineers, this means the “safe” choice is no longer the library—it’s the native API.
The cost of this legacy dependency is measurable. A typical mid-sized application can easily harbor 60KB to 90KB of minified, gzipped JavaScript that exists solely to fill gaps the browser has already closed (Smashing Magazine). When you combine a tooltip library, a popover manager, and focus-trap scaffolding, you’re often shipping roughly 24KB of code just to handle the basic physics of an overlay. That is dead weight that slows down the Time to Interactive (TTI) and increases the maintenance burden of your design system.
Baseline web platform as a product signal, not just a browser compat badge
In the past, we relied on “Can I Use” tables. These are excellent for developers but poor for product strategy because they provide raw data without a risk threshold. Seeing that a feature is supported in “Chrome 121, Firefox 115, and Safari 17” doesn’t tell a product manager or a lead designer whether it is safe to delete a critical dependency from a production app.
The Baseline project changes this by introducing maturity stages that map directly to product risk:
- Baseline Newly Available: The feature has shipped unflagged across all core engines. It is safe for progressive enhancement. You can start using it for users on modern browsers while maintaining a fallback for the minority.
- Baseline Widely Available: The feature has been stable across engines long enough that it is safe to drop polyfills and libraries for the vast majority of broad audiences.
This is a shift from “wait for Safari” folklore to a gated release model. It allows a design system team to say, “Once CSS anchor positioning hits Widely Available, we are deleting the Popper.js dependency from the core bundle.”
Cluster 1: Date and time — from Moment.js to Temporal
The saga of date handling is the most cautionary tale in front-end history. For years, Moment.js was the industry standard, but its 67KB footprint and mutable API became a liability. Teams migrated to date-fns or Day.js to reduce JavaScript bundle size, but these were still just smaller versions of the same problem: shipping a library to fix a broken native <Date> object.
The Temporal API JavaScript is the platform’s definitive answer. Unlike the legacy Date object, Temporal is immutable, timezone-aware, and handles calendar math without the cognitive load of manual offsets.
Currently, Temporal is moving through the pipeline. It has seen implementations shipping behind flags and is progressing toward a stable Baseline status. The strategic decision here is timing. Because Temporal is a fundamental API change rather than a UI tweak, the migration is “all or nothing.” The rule for product teams is simple: maintain your lightweight library (like date-fns) until Temporal hits Baseline Widely Available. At that point, you drop both the library and any polyfills in one sweep, eliminating the dependency entirely without risking a regression in date calculation.
Cluster 2: Tooltip and popover positioning — CSS anchor positioning changes the math
For years, “positioning” was one of the most fragile parts of any UI. Creating a tooltip that stays attached to a button, flips when it hits the screen edge, and doesn’t get cut off by a overflow: hidden container required complex JavaScript calculations. This is why libraries like Floating UI became essential.
The arrival of CSS anchor positioning, which reached Baseline Newly Available in January 2026, fundamentally changes this. Instead of using JavaScript to calculate X/Y coordinates and updating them on every scroll event, you can now declaratively link a “follower” element to an “anchor” element using CSS, as detailed in the CSSWG specification.
When you combine anchor positioning with the Popover API, the result is a total replacement for the traditional tooltip/popover stack. The Popover API handles the “top layer” (solving z-index battles), native dismissal (clicking outside to close), and basic accessibility. Anchor positioning handles the physics.
The impact is immediate. As documented by practitioners, rewriting a complex dropdown menu using these native tools can replace 150 lines of JavaScript with a few lines of HTML and CSS, potentially dropping bundle sizes by 35KB in specific component clusters (Medium). The migration path here is progressive enhancement: use the native API for modern browsers and keep the library as a fallback until the feature hits Widely Available.
Cluster 3: Collection manipulation — Object.groupBy and the quiet death of Lodash
Not every platform shift is a visible UI change. Some are “invisible” utility shifts that nonetheless bloat the bundle. For a decade, Lodash and Underscore were mandatory for any project that needed to group arrays or find the last element of a collection. These utilities were small individually but added up across a large project.
We have now reached a point where methods like Object.groupBy, Map.groupBy, Array.findLast, and Array.findLastIndex are Baseline Widely Available. These are pure JavaScript additions—they don’t rely on the DOM—meaning they are exceptionally stable and performant.
For a senior designer or lead engineer, this is the easiest “win” for tech debt. There is no longer a reason to ship 8KB of Lodash collection helpers when the browser does it natively. These utilities were the “glue” of the early 2010s web, but that glue has been integrated into the platform.
Cluster 4: Modal dialogs and focus management — the <dialog> element and inert
The “modal” is perhaps the most deceptively complex component in any design system. To do it right, you need:
- A backdrop that blocks interaction with the rest of the page.
- A focus trap that prevents the Tab key from leaving the modal.
- An ESC key listener to close the dialog.
- Focus restoration to return the user to the trigger button after closing.
Historically, this required a combination of the <div> element and a heavy-duty library to manage the focus state. The native <dialog> element, combined with the inert attribute, now solves this natively. When a <dialog> is opened as a modal, the browser automatically handles the backdrop and the focus trapping.
The inert attribute is the final piece of the puzzle. It allows you to declaratively tell the browser, “ignore everything inside this section,” which replaces the need for imperative JavaScript “focus-trap” libraries. Because these features are now Widely Available, the accessibility wins are baked into the specification level. You are no longer relying on a library author’s interpretation of WAI-ARIA; you are relying on the browser engine’s implementation.
Reading Baseline as a product roadmap input
For product designers, the Baseline web platform status should be treated as a primary input during discovery and planning, not just a footnote in a technical spec. When you are mapping out a new feature or auditing a design system, you can now use Baseline as a trigger for tech debt sprints.
A practical framework for this is as follows:
- Audit the Dependency Map: Identify every UI primitive currently handled by a library (e.g., “We use
react-datepickerfor dates,Popper.jsfor tooltips, andfocus-trap-reactfor modals”). - Assign Baseline Targets: Tag each dependency with its native equivalent and its current Baseline stage.
- Newly Available: Plan for progressive enhancement in the next quarter.
- Widely Available: Schedule for immediate removal/replacement.
- Communicate in Terms of Risk and Performance: Instead of telling stakeholders “we want to modernize the code,” frame the conversation around measurable outcomes: “By moving to native Popovers and Anchor Positioning, we can remove 24KB from our bundle and improve our accessibility score without adding new feature risk.”
This systemic approach to platform leverage mirrors how we handle other emerging interaction constraints, such as the multimodal fallback patterns required for 2026 apps, where we balance cutting-edge capability with reliable stability.
Where the platform still falls short
To be clear, the shrinking gap does not mean the death of libraries. The platform provides primitives, but it does not provide composed experiences.
Temporal solves the math of date handling, but it does not provide a calendar UI component with range selection and localized formatting. CSS anchor positioning solves the physics of a tooltip, but it doesn’t manage the trigger logic, the delay timers, or the content orchestration for a complex onboarding tour. Similarly, while the platform is catching up on basic lists, virtualized lists for datasets of 100,000 rows and advanced data grids still require specialized libraries.
The strategic implication for product designers is to shift the focus of the design system. Stop investing effort in reimplementing primitives (like focus traps or positioning logic) and start investing in the composition layer. This is where the real product value lives—not in fighting the browser, but in composing a cohesive, accessible, and performant user experience. For those moving into staff designer roles, this means shifting the conversation from component implementation to platform strategy.
The platform has caught up. The question is whether your product is still carrying the weight of the gaps that used to be there.
