The Great Unbundling: How Modern Web Browsers Are Replacing Your package.json

For as long as modern frontend development has existed, an unwritten rule has governed our workflow: if you need to do something non-trivial in the browser, you need a library for it.

Need to format a date relative to now? Install a package. Need to make an HTTP request with advanced capabilities? Install a package. Need to trap focus within a modal dialog or deep-clone a complex JavaScript object? Install a package. Developers have routinely dropped these dependencies into their projects, verified that tests pass, and moved on, rarely looking back.

However, the web platform has not remained static. Over the past few years, the gap between "you need a library for this" and "the browser handles this natively" has steadily narrowed. Today, in a typical mid-sized JavaScript application, developers can shed anywhere from 60KB to 90KB (minified and gzipped) of third-party code. By leveraging modern browser APIs categorized under the "Baseline" initiative, engineering teams can significantly shrink their JavaScript bundles, improve application performance, and offload maintenance overhead directly to the browser vendors.

Main Facts: The Shifting Boundary of the Web Platform

The core issue facing modern web development is not developer laziness, but institutional momentum. Teams rarely re-audit their dependency trees on a regular cadence. While npm audit is routinely run to check for known security vulnerabilities, the question—“Is this library still doing something the browser cannot?”—is seldom asked. Consequently, redundant code lingers in projects for years.

The modern browser ecosystem has evolved to absorb many common utilities natively:

• Internationalization: Built-in APIs like Intl.RelativeTimeFormat, Intl.NumberFormat, and Intl.ListFormat now handle formatting tasks that once required dedicated external libraries.
• HTTP Communication: The native fetch API, paired with modern additions like AbortSignal.timeout(), covers the vast majority of standard network requests previously handed off to heavy clients like axios or superagent.
• User Interface Primitives: Native elements like the HTML <dialog> tag, the Popover API, and CSS anchor positioning eliminate the need for complex, hand-rolled accessibility scripts, focus traps, and third-party tooltip libraries.
• Data Utilities: JavaScript built-ins such as Object.groupBy(), Map.groupBy(), structuredClone(), and native Set operations (like intersection and union) replace fragmented Lodash imports.

Chronology: The Evolution of Baseline and Browser Standardization

To understand how safely we can remove these libraries, we must examine the concept of Baseline—a project introduced by the WebDX Community Group to provide clear, reliable data on web feature support across major browsers (Chrome, Edge, Firefox, and Safari).

• The Pre-Baseline Era: Historically, developers relied on complex matrix tables, CanIUse lookups, and extensive polyfills to determine if a feature was safe to deploy. This friction encouraged the widespread adoption of helper libraries that abstracted browser inconsistencies away.
• The Introduction of Baseline: Baseline categorizes features into clear states—specifically distinguishing between features that are Newly available (supported across major engines relatively recently) and those that are Widely available (having crossed the threshold of mainstream availability for 30 months).
• Recent Milestones (2024–2026):
  • March 2024: Object.groupBy and Map.groupBy arrived as Baseline Newly available features.
  • June 2024: Native Set operations launched, providing built-in mathematical methods like intersections and unions.
  • January 2025: The Popover API reached Baseline Newly available status, transforming lightweight UI overlays.
  • March 2025: Intl.DurationFormat debuted in major engines.
  • January 2026: CSS anchor positioning reached Baseline Newly available status with Firefox joining Chrome and Safari in support, completing a massive puzzle piece for native tooltips and menus.

This rapid cadence of browser updates means that features once deemed bleeding-edge are now standard tools ready for production use.

Supporting Data: Bundle Math and Dependency Clusters

To execute a meaningful dependency audit, developers must work in clusters rather than isolated packages, as performance wins tend to compound when entire categories of libraries are removed.

Cluster 1: Internationalization (The Immediate Win)

Legacy packages like timeago.js, numeral, and pluralize add unnecessary weight to applications.

• Relative Time: Intl.RelativeTimeFormat natively handles localized strings like "3 hours ago" or "yesterday" when paired with a tiny, straightforward arithmetic helper.
• Numbers and Lists: Intl.NumberFormat manages currency, compact notations (e.g., "1.2M"), and thousands separators, while Intl.ListFormat handles complex sentence joining, including the Oxford comma.
• The Impact: Implementing these native tools allows teams to drop roughly 14 KB gzipped of internationalization dependencies immediately.

Cluster 2: HTTP Clients

Libraries such as axios (~17 KB gz) and superagent (~19 KB gz) are often included out of habit.

• While axios offers implicit conveniences like automatic JSON parsing and interceptors, the native fetch API—combined with AbortSignal.timeout()—provides a robust, standards-compliant alternative.
• The Impact: For applications relying primarily on straightforward GET and POST requests, switching to a lightweight fetch wrapper saves roughly 17 KB gzipped.

Cluster 3: UI Primitives

Accessibility and positioning libraries have traditionally bloated frontend bundles. Packages handling modal dialogs, focus trapping (focus-trap), body scroll locking (body-scroll-lock), and tooltips (tippy.js) often total 24 KB gzipped or more.

• The native <dialog> element automatically manages focus-moving, background inertness, Escape key listeners, and top-layer rendering.
• Combined with the Popover API and CSS anchor positioning, developers can achieve bulletproof accessibility and dynamic positioning without writing fragile JavaScript event listeners.

Cluster 4: Lodash Utilities

While entire Lodash packages are less common today, cherry-picked utilities (lodash.clonedeep, lodash.groupby) remain prevalent.

• structuredClone() provides a native, high-performance deep cloning mechanism for plain data.
• Object.groupBy and native Set methods (intersection, difference) eliminate the rationale for importing utility functions for array and set manipulation.
• The Impact: Removing these specific helpers routinely recovers 8 KB gzipped or more.

Official Responses and Strategic Exceptions: The Case of Temporal

While the platform is aggressively expanding, a professional audit requires restraint. Not every modern API is ready to replace existing libraries today.

A prime example is Temporal, the long-awaited modern replacement for JavaScript’s legacy Date object. Reaching TC39 Stage 4 and entering ES2026 specifications, Temporal offers immutable objects, robust time zone management, and intuitive syntax. Major browsers like Chrome and Firefox have integrated it, but Safari has yet to release stable support.

Consequently, Temporal is not yet Baseline Widely available. To use it across all browsers today, developers must rely on a polyfill (@js-temporal/polyfill), which weighs between 19 KB and 44 KB gzipped.

• The Strategic Decision: Replacing a lightweight date library like dayjs (~3 KB gz) with Temporal plus its polyfill would drastically increase the application’s bundle size rather than reduce it.
• Therefore, the framework dictates keeping established date libraries until Temporal achieves true Baseline status and can be conditionally loaded for legacy environments.

Implications: Building a Repeatable Audit Framework

Reducing JavaScript bundle size is not a one-off cleanup project; it requires a systematic engineering habit. To safely transition away from redundant dependencies, teams should adopt a practical, four-step decision framework during quarterly maintenance cycles:

1. Verify Baseline Safety for Your Audience: Evaluate whether a native feature is Widely available or Newly available. Check your application’s analytics or browserslist configuration to ensure your specific user base can safely run the native code without relying on heavy polyfills.
2. Calculate the True Swap Cost: Determine whether adopting a native feature requires a polyfill that might inadvertently inflate your bundle size.
3. Audit Real-World Usage: Ensure the platform feature actually covers your specific use cases. Do not assume a drop-in replacement exists if your code depends heavily on advanced edge cases (such as HTTP request interceptors or custom retry logic).
4. Embrace Progressive Enhancement: For newly available features, guard your implementation with simple feature checks (typeof ... === 'function') to serve native code to modern browsers while maintaining reliable fallbacks for older clients.

By systematically auditing dependencies against the evolving web platform, engineering teams can reclaim dozens of kilobytes of dead code, improve runtime performance, and embrace a cleaner, browser-native future.