Somewhere between 60KB and 90KB of minified, gzipped JavaScript in a typical mid-sized app is now redundant. The browser already does the work. Date formatting, HTTP requests, deep cloning, array grouping: these were real gaps once. Most of them are not gaps anymore. The question teams never ask is whether a library is still doing something the browser cannot. So the libraries stay, and the bundles stay fat.
The article builds a practical audit process around Baseline, the WebDX Community Group's framework for tracking cross-browser feature availability across Chrome, Edge, Firefox, and Safari. Baseline Widely available means 30 months of consistent browser support, and that is the threshold where you can drop a dependency today without a polyfill. The audit works in clusters, not one-by-one line reads. The internationalization cluster alone shows replaceable libraries including timeago.js at 1KB, numeral at 3.9KB, and humanize-duration at 6.6KB, all sitting on top of Intl namespace APIs that are already Widely available. The piece also builds a three-question decision framework: Is the replacement Baseline-safe for your specific audience? What does the swap actually cost in polyfill weight? Does the platform feature cover your real use case, not just the obvious one?
The framework is the reason to read the full piece, not just the dependency list. The axios-versus-fetch section is a good example of where the article stays honest: interceptors, retries, and request cancellation are real features that fetch does not cover, and the article says so directly. The Temporal polyfill section shows a case where the native replacement is heavier than the library it would displace, which is the kind of math most audits skip. The piece ends with a repeatable process you can run against your own package.json using webstatus.dev, MDN Baseline badges, and the web-features npm package.
[READ ORIGINAL →]