The Rise of the Baseline Standard and Web Interoperability
The movement toward a more robust native web platform gained significant momentum with the formation of the WebDX Community Group. This collective, featuring representatives from Google, Microsoft, Mozilla, and Apple, sought to resolve the historical fragmentation of browser features. In 2023, they introduced "Baseline," a classification system designed to provide developers with clear signals regarding the stability and support of web features across the four major engines: Chrome, Edge, Firefox, and Safari.
Under this framework, a feature is categorized as "Newly Available" the moment it becomes supported across all major engines. After a period of 30 months—a window intended to allow the vast majority of users to update their browsers—the feature transitions to "Widely Available." This standardization has accelerated the deprecation of many utility libraries that were once considered essential. For the first time in the history of web development, engineering teams have a data-driven metric to decide when to stop shipping a polyfill or a library in favor of native code.
The Economic and Performance Cost of Dependency Inertia
The persistence of legacy libraries in modern codebases is rarely a result of intentional neglect. Instead, it stems from a lack of "Baseline-cadence" auditing. While many organizations perform security audits via tools like npm audit, fewer teams ask whether a library is still necessary. This "dependency inertia" carries measurable costs.
From a performance perspective, every kilobyte of JavaScript must be downloaded, decompressed, parsed, and executed. On low-powered mobile devices or unstable networks, an extra 90KB of gzipped JavaScript can delay the Time to Interactive (TTI) by several seconds. Beyond performance, there is the issue of "supply chain security." Each third-party dependency represents a potential entry point for vulnerabilities. By shifting logic to the browser’s native APIs, developers effectively hand off the maintenance and security of that logic to browser vendors, who are incentivized to optimize and patch those features at the engine level.
Cluster 1: The Transformation of Internationalization
Perhaps the most significant area of native advancement is the Intl namespace. Historically, formatting dates, numbers, and lists required heavy libraries such as numeral.js, timeago.js, or pluralize. Today, the Intl API is Widely Available and provides high-performance, localized formatting without the overhead of external data sets.
For instance, Intl.RelativeTimeFormat allows developers to convert timestamps into human-readable strings like "3 hours ago" or "yesterday." Unlike older libraries that required developers to ship locale-specific strings, the browser uses its internal ICU (International Components for Unicode) data, which is already present in the user’s system. Similarly, Intl.NumberFormat handles complex currency conversions, thousands separators, and compact notation (e.g., "1.2M" instead of "1,200,000") with minimal code.
The most recent addition to this cluster, Intl.DurationFormat, reached the "Newly Available" status in early 2025. While it requires a 30-month window before reaching "Widely Available" status, it signals the eventual end for libraries like humanize-duration. Engineering teams focusing on modern browser support can already realize a saving of approximately 14KB gzipped by migrating this entire cluster to native APIs.
Cluster 2: Re-evaluating HTTP Clients and Networking
For over a decade, axios and superagent have been the industry standards for handling HTTP requests, primarily because the original XMLHttpRequest API was cumbersome. The introduction and subsequent maturation of the fetch API, combined with AbortController and AbortSignal, has changed the landscape.
fetch is now Widely Available and provides a cleaner, promise-based interface. While axios offers automatic JSON parsing and request interceptors, the gap is narrowing. Modern browsers now support AbortSignal.timeout(), allowing for native request timeouts—a feature that previously required complex wrapper logic.
However, the decision to drop a library like axios requires a nuanced analysis of specific use cases. axios remains superior in handling upload progress and offers a more ergonomic API for intercepting requests and responses globally. For simple REST API consumption, the 17KB gzipped cost of axios is increasingly difficult to justify when a thin wrapper around fetch can provide 90% of the same utility for zero additional bytes.
Cluster 3: UI Primitives and the Top Layer
The most visually impactful shift involves UI components such as modals, popovers, and tooltips. Traditionally, ensuring these elements were accessible and correctly positioned required a suite of libraries like a11y-dialog, tippy.js, and focus-trap.
The introduction of the <dialog> element has revolutionized modal implementation. It natively handles "focus trapping," which prevents a user from tabbing out of the modal, and it automatically closes on the "Escape" key. Furthermore, the browser’s "Top Layer" rendering ensures that a dialog will always appear above other elements, regardless of CSS z-index configurations.
In early 2025, the Popover API became Newly Available, followed closely by CSS Anchor Positioning in early 2026. Together, these features allow developers to create complex floating menus and tooltips without any JavaScript positioning logic. By using the anchor-name and position-anchor CSS properties, the browser handles the mathematical calculations needed to keep a tooltip pinned to a button, even as the page scrolls. This cluster represents a potential saving of roughly 24KB gzipped while simultaneously improving the accessibility and robustness of the user interface.
Cluster 4: The Obsolescence of Utility Helpers
The lodash library was once the most downloaded package on npm, providing essential helpers for object manipulation and array grouping. Today, the JavaScript language itself has absorbed many of these functions.
The structuredClone API is now the standard for deep-cloning objects, replacing lodash.clonedeep. It handles circular references and complex types like Map, Set, and ArrayBuffer natively. Similarly, Object.groupBy and Map.groupBy, which became Newly Available in March 2024, have made lodash.groupby redundant. Even complex set operations, such as intersections and differences, are now built directly into the Set object as of mid-2024.
While some lodash functions like debounce and throttle still lack a native equivalent, the practice of importing the entire library—or even multiple standalone utilities—is no longer defensible. By utilizing native grouping and cloning, teams can shed approximately 8KB to 12KB of gzipped code.
Cluster 5: The Temporal API and the Importance of Timing
While the trend is toward native adoption, the "Temporal" API serves as a cautionary tale for developers. Intended to replace the notoriously flawed Date object, Temporal offers an immutable, time-zone-aware API. However, as of mid-2026, it is not yet Baseline Widely Available.
Using Temporal today requires a polyfill that can weigh up to 44KB gzipped. For an application currently using dayjs (approximately 3KB), switching to Temporal prematurely would actually increase the bundle size by 41KB. This highlights a critical rule in dependency auditing: a native feature is only a "win" if it does not require a polyfill heavier than the library it replaces. The technical recommendation for Temporal is to remain on existing libraries until Safari provides stable support and the feature moves toward the Widely Available tier.
A Strategic Framework for Dependency Auditing
To transition from a library-heavy codebase to a platform-native one, engineering departments should adopt a formal auditing process. This process is built on three central questions:
- Is the replacement Baseline-safe for the specific audience? Teams must cross-reference their
browserslistconfiguration with the Baseline status of a feature. A B2B application where users are required to use modern browsers can adopt Newly Available features much faster than a public-facing e-commerce site with a significant tail of older mobile devices. - What is the total cost of the swap? If a native feature requires a large polyfill to support 5% of the user base, the swap may not be economically viable. The goal is to reduce the total bytes shipped, not just the number of entries in
package.json. - Does the platform feature cover the specific use case? Native features are designed to be general-purpose. If a library provides a specific, high-value feature (like
axiosinterceptors orlodashdebouncing) that the native API lacks, the library should be retained.
Conclusion and Future Outlook
The web platform is no longer the "broken" environment that necessitated the massive expansion of the npm ecosystem a decade ago. The success of the Baseline initiative and the rapid release cycles of modern browsers have created a platform that is increasingly self-sufficient.
By conducting quarterly audits and leveraging tools like webstatus.dev and bundle analyzers, developers can systematically remove layers of redundant code. This shift not only results in faster, more responsive applications but also aligns development practices with the long-term trajectory of the web. As features like the Navigation API and the File System Observer API move toward Baseline status, the opportunity to ship less JavaScript while delivering more functionality will only continue to grow. The modern developer’s greatest skill is no longer knowing which library to add, but knowing which ones the browser has already made obsolete.
