Most of us install a dependency once and never look at it again.
It does its job, the tests pass, and we move on.
But the web platform keeps moving too, and a surprising number of the libraries sitting in your today are now built into the browser.
In a typical mid-sized JavaScript app, you can often find somewhere between 60KB and 90KB (minified and gzipped) of dependencies that the platform can now handle on its own.
Date and number formatting, HTTP requests, modals, tooltips, deep cloning, grouping arrays: these were all real gaps a few years ago.
A lot of them aren’t gaps anymore.
The reason those libraries stick around isn’t laziness.
It’s that most teams don’t re-audit their dependencies on a Baseline cadence, or are simply not aware of how fast browsers are shipping these days.
You check for security, but is this library still doing something the browser can’t? is a question that rarely gets asked.
So the libraries stay.
In this article, we’ll run that audit together.
Instead of going through dependencies one by one, we’ll work in clusters, because the wins tend to come in groups.
We’ll do the bundle math, build a small decision framework you can reuse, and stay honest about the cases where the platform still falls short.
By the end, you’ll have a repeatable process you can run on your own .
What “Baseline” Actually Means Before we start deleting things, let’s quickly recap what Baseline is.
Feel free to skip this section if you’re already familiar.
Baseline is a project from the WebDX Community Group that tells you, in plain terms, how safe a web feature is to use across the major browsers (Chrome, Edge, Firefox, and Safari).
A feature can be in one of three states: Limited availability The feature hasn’t shipped in all the major engines yet.
Not safe to rely on without a fallback.
Baseline Newly available The feature has just landed in all the major engines.
It works for users on up-to-date browsers, but older devices in the wild may not have it yet.
Baseline Widely available The feature has been in all the major engines for 30 months.
At this point, you can reach for it without much thought.
That 30-month gap between “Newly” and “Widely” matters a lot for this audit.
A feature that’s Widely available is something you can usually drop a library for today.
A feature that’s only Newly available is something you can drop a library for if you check your audience first, or if you’re comfortable with a small feature check.
We’ll treat those two cases differently throughout.
You can look any feature up on webstatus.dev, on MDN (every reference page shows a Baseline badge near the top), or programmatically with the npm package.
We’ll use all three later when we run the audit on a real project.
A Decision Framework Before You Delete Anything It’s tempting to read “the browser does this now” and start ripping libraries out.
Let’s not do that.
A swap that looks free on paper can quietly break things for a chunk of your users, or cost you a feature you were relying on without realizing it.
So before dropping any library, ask three questions.
We’ll reuse these in every cluster below.
1.
Is the replacement Baseline-safe for my audience?
Not “is it Baseline” in the abstract, but “is it safe for the people who actually use my app.” If the native feature is Widely available, this is usually a yes.
If it’s only Newly available, check your analytics or your config and see what share of your users would miss out.
A B2B dashboard where everyone’s on the latest browser is a very different situation from a public-facing site with a long tail of old Android devices.
2.
What does the swap actually cost?
Dropping a library isn’t always free.
Sometimes the native feature isn’t supported widely enough yet, so you’d reach for a polyfill.
If that polyfill is heavier than the library you’re removing, you’ve made your bundle bigger, unless you load it conditionally.
We’ll see exactly this with Temporal later.
3.
Does the platform feature cover my real use case?
Libraries often do more than the platform feature they resemble. isn’t just with automatic JSON parsing; it has interceptors, request cancellation, and retries.
If you’re using those, a straight swap to will leave you reimplementing them.
Check what you actually use before assuming it’s a drop-in replacement.
Keep these three in mind.
Every cluster below is really just these questions applied to a different corner of your dependencies.
Cluster 1: Internationalization (The Biggest Drop Today Win) This is the cluster where you’ll usually find the most KBs sitting on top of features that are already Widely available.
The browser ships a whole family of formatting tools under the namespace, and a lot of small, popular libraries became unnecessary.
Here are the usual suspects and what replaces them: (1 KB gz) → (2.3 KB gz) → (3.9 KB gz) → (6.6 KB gz) → list-joining helpers → Let’s walk through some of them.
Relative Time exists to turn a timestamp into “3 hours ago”. does the same thing, and it’s Baseline Widely available.
The option is the nice touch here: it gives you “yesterday” instead of “1 day ago” where the language has a word for it.
You pass a number and a unit, and you get a localized string back.
You may be wondering about the one thing does that this snippet doesn’t: it picks the unit for you.
Given a date, decides whether to say “seconds” or “days.” expects you to do that part.
It’s a few lines of arithmetic (work out the difference, find the largest unit that fits), and once you’ve written that helper, you don’t need the library anymore.
Numbers, Currency, And Lists covers most of what number-formatting libraries do: thousands separators, currency, percentages, and compact notation.
And , Widely available, handles the “join an array into a sentence” problem, including the Oxford comma, which is the kind of thing people write fiddly helper functions for: The One Caveat: Durations turns a number of milliseconds into “1 hour, 30 minutes”.
The platform equivalent is : One thing to keep in mind is that is Baseline Newly available at the time of writing, not Widely available.
It landed in all the major engines in March 2025, and it’s on track to become Widely available in
2027.
So this one fails question 1 for broad-audience apps unless you check your traffic first or add a fallback.
For an internal tool on modern browsers, it’s fine today.
For a public site with old devices, give it another year or guard it with a feature check.
The Math On This Cluster If your app uses the full set (, , , ), that’s roughly 14 KB gzipped of dependencies, most of it replaceable right now with Widely available APIs.
The internationalization cluster is usually the easiest win in the whole audit.
Cluster 2: HTTP Clients This cluster is more nuanced, so it’s a good one to slow down on.
The browser HTTP libraries people reach for are (17 KB gz) and (19 KB gz).
For most requests, plus covers what you need, and both are Widely available.
A basic GET looks like this: The one extra line () is being explicit where was implicit.
That’s the pattern across this whole cluster: does less for you by default, and you decide whether you want the things it leaves out.
Timeouts has a option. has : Where Doesn’t Replace This is where question 3 does most of the work, so let’s be specific about the gaps: doesn’t reject on HTTP errors.
A or is a resolved promise, not a rejection.
You have to check yourself. rejects on any non-2xx status.
No interceptors.
If you rely on interceptors to attach auth tokens or handle 401s in one place, has no equivalent.
You’d wrap in your own function or class to get the same behavior.
No automatic retries. (with a plugin) can retry failed requests.
With , that’s your code to write.
No upload progress. still can’t report upload progress in a first-class way.
If you have a file uploader with a progress bar, that’s a real reason to keep a library.
I personally heavily rely on interceptors in my interactive online courses,