How Baseline Can Help Ship Less JavaScript

The evolution of the web platform has accelerated at an unprecedented rate, systematically eroding the necessity for many third-party JavaScript dependencies that were once considered industry standards. For years, developers have relied on extensive libraries to bridge gaps in functionality, ranging from date formatting and HTTP requests to modal windows and complex array manipulation. However, a significant portion of these dependencies—often totaling between 60KB and 90KB of minified and gzipped code—can now be offloaded to the browser’s native capabilities. This transition is not merely an exercise in code minimalism; it is a fundamental shift in how modern web applications should be architected to maximize performance and maintainability.

The "Baseline" project, spearheaded by the WebDX Community Group, serves as the primary metric for this transition. By categorizing web features into "Newly available" and "Widely available," the project provides developers with a clear roadmap for determining when it is safe to deprecate a dependency. A feature labeled as "Widely available" indicates it is supported across all major browsers (Chrome, Edge, Firefox, and Safari) and has been for at least 30 months, making it a safe candidate for native implementation. Conversely, "Newly available" features are those that have recently reached cross-browser consensus, requiring developers to evaluate their specific audience demographics or utilize feature detection before making the switch.

The Economic and Performance Costs of Legacy Dependencies

To understand why so many applications remain bloated with redundant code, one must look at the traditional development lifecycle. Often, a library is installed to solve a specific problem, and once the feature is integrated and tested, it is rarely revisited. The standard industry practice of using npm audit focuses exclusively on security vulnerabilities, yet it fails to account for "feature obsolescence"—the state where a browser’s native API renders an external library redundant.

Data from performance monitoring tools suggest that every kilobyte of JavaScript adds to the total blocking time and time-to-interactive metrics. For mobile users on constrained network conditions, the cumulative weight of unnecessary libraries can lead to significant bounce rates. A mid-sized JavaScript application typically carries several dozen dependencies. When these are audited against modern standards, the potential for bundle size reduction is substantial. By eliminating redundant dependencies, teams can improve load times, reduce energy consumption on the client device, and decrease the long-term maintenance burden associated with patching and updating external packages.

Internationalization: Reclaiming the Native Edge

The most immediate area for bundle reduction lies in internationalization. Historically, developers relied on packages like timeago.js, pluralize, and numeral to handle localized formatting. Today, the Intl namespace provides a robust suite of tools that are widely supported.

The Intl.RelativeTimeFormat API, for instance, allows developers to generate localized strings like "yesterday" or "in three hours" with minimal overhead. Similarly, Intl.NumberFormat and Intl.ListFormat have effectively replaced the need for custom logic or heavy helper libraries. These native features are not only more performant but are also maintained by browser vendors, ensuring they remain compliant with the latest Unicode Common Locale Data Repository (CLDR) updates. While the newer Intl.DurationFormat is currently categorized as "Newly available," its adoption is expected to reach "Widely available" status by 2027, signaling the end of the line for specialized duration-handling libraries.

Reframing HTTP Requests and UI Primitives

The dominance of HTTP client libraries like Axios and Superagent is another area ripe for re-evaluation. While these libraries offer convenience features such as interceptors and automatic JSON parsing, the native Fetch API—when paired with the AbortController—covers the vast majority of use cases.

The decision to migrate from a dedicated HTTP client to native Fetch requires a careful audit of existing implementations. If a project relies heavily on interceptors or complex request retries, those will need to be re-implemented as thin wrappers around Fetch. However, for most applications, this shift eliminates approximately 17KB to 20KB of gzipped code.

A similar consolidation is occurring in the UI space. The introduction of the <dialog> element, the Popover API, and CSS anchor positioning has provided developers with standardized ways to handle modals, tooltips, and pop-ups. Previously, these interactions required heavy libraries such as tippy.js, focus-trap, and body-scroll-lock. By utilizing native browser APIs, developers can achieve better accessibility—inherent in the browser’s implementation—and reduce the footprint of their UI layer by over 20KB. The use of CSS properties like anchor-name and position-anchor represents the cutting edge of this trend, moving logic that was once trapped in JavaScript into the browser’s layout engine.

The Strategic Decision Framework

Before initiating any refactoring, engineering teams should apply a three-part decision framework to ensure stability and user experience:

1. Audience Compatibility: Is the native replacement "Widely available" for the specific users visiting the site? If the application caters to legacy browsers or specific enterprise environments, "Newly available" features must be gated behind feature detection or polyfills.
2. True Cost Calculation: Will replacing a library with a polyfill result in a larger bundle? In cases like the Temporal API, the current polyfill is significantly larger than existing lightweight date libraries. In such instances, waiting for broader native support is the more rational architectural choice.
3. Functional Parity: Does the native feature replicate all necessary functionality? If a library provides edge-case features—such as deep cloning with specific class instance handling—that the native structuredClone cannot replicate, the library should remain.

The Case of Temporal: Patience as an Architectural Virtue

The development of the Temporal API provides a cautionary tale. While Temporal is designed to eventually replace the dated Date object, it has not yet reached "Widely available" status across all major browsers, particularly Safari. Consequently, implementing Temporal today requires a polyfill that can weigh up to 44KB. For most teams, the performance cost of the polyfill outweighs the benefits of the new API. This illustrates that the goal is not to remove libraries at all costs, but to align the codebase with the browser’s current maturity.

The Path Forward: A Quarterly Audit

The shift toward a "platform-first" development mentality is becoming a prerequisite for building high-performance web applications. The recommended process is to perform a quarterly audit:

• Dependency Inventory: Execute npm ls --omit=dev to identify exactly what is being bundled.
• Bundle Analysis: Utilize tools like source-map-explorer or vite-bundle-visualizer to identify which packages are the heaviest contributors to the total bundle size.
• Platform Alignment: Check the MDN or webstatus.dev documentation for the features used by those dependencies.
• Progressive Enhancement: Implement native features and provide fallbacks only for the small percentage of users on older browsers.

As browser engines continue to evolve, the gap between what developers "need" and what the browser "provides" will continue to narrow. This transformation allows for a leaner, faster, and more accessible web, provided that developers remain vigilant in auditing their dependencies and embracing the capabilities of the modern web platform. The responsibility now lies with engineering teams to move away from the "install-and-forget" mentality and toward a model of continuous optimization.