The gap between “you need a library for this” and “the browser does this” is closing at an unprecedented rate. For years, the JavaScript ecosystem has operated under the assumption that the platform is insufficient, leading developers to lean heavily on npm to bridge the divide. However, a significant portion of the typical package.json file—often ranging from 60KB to 90KB of minified, gzipped code—is now entirely redundant.

As the WebDX Community Group’s "Baseline" project gains momentum, it is becoming increasingly clear that many of the utilities developers import as dependencies are now native browser features. Auditing these dependencies is no longer just a matter of security; it is a matter of performance, maintainability, and respecting the evolution of the modern web platform.

The Evolution of the Web Platform: A Chronology of Capability

The landscape of web development has shifted dramatically over the past few years. Not long ago, tasks such as formatting dates, handling HTTP requests, managing modals, and performing complex array manipulations required dedicated libraries.

• 2020–2022: The era of "Library-First." Developers relied heavily on axios for HTTP, moment.js (and later date-fns) for time, and complex UI libraries like tippy.js for tooltips.
• 2023–2024: The "Baseline" movement matures. Browser vendors aligned on the Intl API, structuredClone, and the native <dialog> element.
• 2025–2026: The arrival of sophisticated CSS and API features. Anchor positioning, the Popover API, and Object.groupBy reached stable, widely supported states, effectively rendering several legacy utility packages obsolete.

The concept of "Baseline" is the compass for this transition. It defines a feature’s availability across the major engines: Chrome, Edge, Firefox, and Safari. By categorizing features as "Newly available" or "Widely available," developers can make informed, risk-adjusted decisions about when to purge a dependency.

A Decision Framework for Strategic Auditing

Before rushing to delete dependencies, it is essential to establish a rigorous framework. Indiscriminate removal can break functionality or introduce subtle regressions. When evaluating a library for removal, ask three critical questions:

1. Is the native feature Baseline-safe for my audience? While a feature might be "Widely available," your specific user base may still be on legacy browsers. Consult your browserslist configuration. If you are serving a B2B dashboard, you have more flexibility than a site catering to the long-tail of older Android devices.
2. What does the swap actually cost? Sometimes, replacing a small library with a large polyfill to achieve cross-browser compatibility results in a larger bundle size. Always measure the "net weight" of the change.
3. Does the platform feature cover my real use case? Libraries often provide "batteries included" features. If you are using axios specifically for interceptors and automatic retries, replacing it with a raw fetch call will require you to write the boilerplate you were previously outsourcing.

Cluster 1: Internationalization (The Low-Hanging Fruit)

Internationalization (i18n) remains the most significant area for potential bundle reduction. The browser’s Intl namespace has become remarkably powerful.

• Relative Time: Instead of timeago.js, the native Intl.RelativeTimeFormat provides a robust, localized way to handle timestamps. While the library might have offered "unit picking" (deciding whether to say "seconds" or "days"), implementing this logic natively requires only a few lines of arithmetic.
• Numbers and Currency: Intl.NumberFormat has largely replaced libraries like numeral. It handles currency, percentages, and compact notation (e.g., "1.2M") with native performance.
• List Formatting: Intl.ListFormat now handles the "Oxford comma" and localized sentence structures, eliminating the need for custom string-manipulation helpers.

Cluster 2: HTTP Clients and the fetch API

Many teams default to axios or superagent for HTTP requests. While these libraries provide excellent abstractions, the standard fetch API, combined with AbortController, can replicate most of these features with minimal effort.

The primary friction point is usually the difference between the "automatic" behavior of library-based clients and the "explicit" nature of the platform. For example, fetch requires an explicit call to .json(). However, for developers who are not utilizing advanced interceptors or complex custom request-retry logic, this shift is almost always beneficial. By moving to a thin, custom wrapper around fetch, teams can shed roughly 17KB of gzipped code.

Cluster 3: UI Primitives and the "Top Layer"

The most satisfying wins often occur in the UI layer. Historically, accessibility requirements for modals and tooltips necessitated heavy libraries like focus-trap or tippy.js. Today, the browser handles these via the "Top Layer."

• The <dialog> Element: This native element handles focus trapping, background inertia, and Escape-key listeners out of the box. By calling .showModal(), developers gain native accessibility that is often superior to hand-rolled solutions.
• Popover API and Anchor Positioning: For floating elements, the Popover API offers "light-dismiss" behavior natively. When paired with the recently introduced CSS Anchor Positioning, the need for external positioning libraries like Popper (bundled within tippy.js) vanishes.

Cluster 4: The Lodash Reckoning

Lodash is rarely used in its entirety in modern applications, but individual functions are ubiquitous. The platform is catching up here as well:

• Object.groupBy: Replaces the need for lodash.groupby.
• structuredClone: A native method for deep-cloning objects that handles complex types like Map, Set, and Date far more reliably than JSON.parse(JSON.stringify()).
• Set Operations: The new Set prototype methods—such as intersection, union, and difference—have officially moved common utility logic into the core engine.

Implications: The Case of Temporal

Not every library is ready to be retired. A prime example is the Temporal API, the long-awaited successor to the problematic Date object. While Temporal is objectively superior, it is not yet "Widely available."

Forcing Temporal into a codebase today requires a hefty polyfill (ranging from 19KB to 44KB gzipped). If your current date library (like dayjs) is only 3KB, the swap is a net performance loss. The intelligent approach here is to monitor the status of Temporal and wait for native support to hit the "Baseline" threshold across all major browsers before executing the migration.

Implementing a Repeatable Audit Process

To maintain a lean dependency tree, teams should adopt a quarterly audit ritual:

1. Inventory: Use npm ls --omit=dev --depth=0 to identify your production footprint.
2. Analyze: Use tools like source-map-explorer or vite-bundle-visualizer to see what is actually consuming your bandwidth.
3. Evaluate: Cross-reference your candidates against the Baseline status on webstatus.dev or MDN.
4. Refactor: Apply the three-question framework. Where a native feature is "Newly available," implement a feature check:

   if (typeof FeatureName === 'function') 
     // Use platform feature
    else 
     // Use fallback or library
   

Conclusion: The Path Forward

The "unbundling" of the web is not a destructive process; it is a maturation of the development lifecycle. By periodically auditing package.json against the capabilities of the modern web platform, developers can significantly reduce bundle sizes, improve site performance, and leverage better-tested, natively optimized features.

The web platform is no longer a static target—it is an evolving, capable foundation. As we move through 2026 and beyond, the most efficient applications will be those that rely less on external dependencies and more on the increasingly robust capabilities built into the browser itself. Start your audit today; the browser can likely handle more of your logic than you think.