Baseline: The Secret to Shipping Way Less JavaScript

Baseline: The Secret to Shipping Way Less JavaScript

Remember the good old days of jQuery? You’d drop a 90KB file into your project and suddenly `$(document).ready()` made everything feel buttery smooth. Then we got smarter, split our bundles, and traded jQuery for React, Vue, and a cabinet full of micro-libraries for every little thing.

But here’s the thing I keep catching myself doing: reaching for a 20KB date formatting library when the browser I’m targeting literally ships an API that does the same thing. For free. No network request. No version bump. No future maintenance.

That’s where **Baseline** comes in.

If you haven’t heard of it yet, Baseline is a W3C-backed initiative that gives us a simple, universal label for “when can I use this feature safely?” It answers the most annoying question in web development with one word: **today**. And by helping you identify what the web platform can already handle, Baseline can dramatically shrink the JavaScript you ship. Let’s get into how.

What Is Baseline, Really?

Baseline is a shared understanding of browser support across all the major players: Chrome, Edge, Firefox, Safari, and Opera. Instead of checking a matrix of “works in 97% of browsers,” Baseline tells you if a feature is **available** (works in current browsers) or **newly available** (just landed in the latest versions). The idea is to remove the guesswork.

Think of it as “caniuse, but with a friendlier verdict.” When a feature becomes Baseline, it means every browser in the common ecosystem supports it. That’s your green light.

And the best part? Baseline is baked into places you probably already use. Visit the MDN compatibility tables, search for a feature, and you’ll see a Baseline badge right next to it. Or check out [web.dev/baseline](https://web.dev/baseline) for a dashboard of what’s ready today.

Why This Matters for Your Bundle Size

The gap between “you need a library for this” and “the browser does this” keeps closing. Every year, browsers add APIs that used to require polyfills, helper libraries, and utility functions. If you’re still shipping `moment-timezone` for timezone math or `lodash` for `_.debounce()`, you’re paying for something the platform already provides—both in bytes and in complexity.

Let me show you three practical examples where Baseline can help you cut dead weight.

Scenario 1: Date Formatting Without the 50KB Dependency

I once worked on a project that imported `date-fns` just to format a few dates in a dashboard. The entire app was a static dashboard. We were shipping 16KB of localized date functions to render strings like “Aug 9, 2026.”

But here’s a little experiment: open your browser console right now and type:

```js
new Intl.DateTimeFormat('en-US', { dateStyle: 'full' }).format(new Date())
```

That’s it. **No import, no npm install, no version pinning.** The `Intl` object has been a Baseline feature for years. It handles locale-specific formatting, time zones, even date-fns-style relative time with `Intl.RelativeTimeFormat`.

Want the whole bundle gone? Map your date-fns functions to their native equivalents:

- `format` → `Intl.DateTimeFormat`
- `formatDistance` → `Intl.RelativeTimeFormat`
- `parseISO` → `Date.parse()` (or `new Date()` with care)
- `zonedTimeToUtc` → `Intl` with `timeZone` option

Yes, edge cases exist, but for 90% of projects, the native Intl API does the job. And it’s Baseline available, so every modern browser handles it.

Scenario 2: Replacing Lodash with the DOM

I still see `lodash.debounce` in some codebases. Five kilobytes to force a function to wait a bit before running. But the browser has this built-in:

```js
function debounce(fn, delay) {
let timer;
return (...args) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), delay);
};
}
```

Or if you’re lazy like me, a simple `setTimeout` in an event listener works fine for most cases. Same for `_.throttle`, `_.clamp`, `_.range`—all just a few lines of vanilla JavaScript.

But it goes deeper. Ever use `_.forEach`? The Array prototype has `forEach`, `map`, `filter`, `reduce`—all Baseline. `_.get` for safely accessing nested properties? Optional chaining has been a Baseline feature since 2020. `_.unique`? That’s just `Set`.

The DOM itself is a goldmine too: `classList.toggle()` replaces `_.toggleClass`, `Element.matches()` replaces `_.is()` selectors, and native `IntersectionObserver` replaces entire scroll-spy libraries. Next time you’re about to add a dependency, ask yourself: “Is this just a fancy wrapper around something `document.querySelectorAll` already gives me?”

Scenario 3: HTTP Requests Without axios

Axios is a beautiful library, but in 2026, the native `fetch` API is Baseline and handles nearly every use case. Streaming? `fetch` supports `response.body.getReader()` for streaming. Authentication? You can set headers, credentials, and interceptors with a small wrapper. Aborting? That’s `AbortController`, also Baseline.

For a small project, I replaced axios entirely with a 20-line helper:

```js
async function request(url, options = {}) {
const res = await fetch(url, {
headers: { 'Content-Type': 'application/json', ...options.headers },
signal: options.signal ?? (options.timeout && AbortSignal.timeout(options.timeout)),
...options,
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}
```

No npm, no node_modules bloat, no circular dependency warnings. Just fast, native, and reliable.

How to Actually Audit Your Dependencies Using Baseline

You’re sold, so now what? Here’s a practical process you can do this afternoon.

1. List Your Runtime Dependencies

Run `npm ls --production` or just look at your `package.json`. Highlight anything that isn’t your framework or a state management library. Those small utility packages are the prime targets.

2. Check Each One Against Baseline

For every library on your list, ask two questions:

- What problem does this solve?
- Can I solve it with a web API that’s Baseline available?

Search MDN for the feature. If you see the green “Baseline available” badge, you’re good. If you see “Newly available” and you only target modern browsers, it’s still worth considering. If it’s red “Limited,” maybe keep the library for now.

A quick tip: open your developer tools in Chrome, Safari, or Firefox and test the API directly. If it works without a flag, that’s a great sign.

3. Grep Your Code for Telltale Signs

Search for patterns like `import * as _ from 'lodash'`, `from 'date-fns'`, `from 'axios'`, or `from 'jquery'`. Then look at how often those functions are actually used. Sometimes you discover you only use three methods out of a 200-method library. That’s a clear opportunity.

4. Replace and Compare

Do the migration one library at a time. Keep a PR separate so you can measure the bundle size change. Use your build tool’s size report or just check the file size in devtools. I recommend running Lighthouse before and after. Watching that “JavaScript execution time” drop is a beautiful feeling.

The Human Side of Shipping Less JavaScript

Why do we care, beyond the smug satisfaction of a smaller bundle? Because JavaScript is the single most expensive resource we send to browsers. Each byte must be downloaded, parsed, compiled, and executed. Every API saved means a faster page load for someone on a cheap Android phone with a spotty 3G connection. Not everyone has a MacBook Pro connected to fiber.

Shipping less JavaScript is also about less brain overhead for you, the developer. Every dependency is a potential security vulnerability, a potential migration headache, and a potential source of weird bugs when its maintainer decides to retire. Native APIs are maintained by the browser vendors, which means they’ll be updated, documented, and supported for years to come.

And there’s a deeper benefit: you start to understand the web platform itself. When you use `Intl`, `URL`, `Promise`, `Map`, `Optional Chaining`, and `fetch` directly, you become a better web developer. You’re not just a consumer of abstractions; you’re a builder who knows the grain of the wood.

Are There Caveats? Yes. Don’t Be Silly.

Baseline is not a magic wand. Some advanced APIs are still too new to be Baseline available everywhere. For example, the Popover API or the View Transitions API are “newly available” but not fully landed in all browsers. If you’re building a public site for a broad audience, you might want to wait or provide a graceful fallback.

Also, dropping a library doesn’t always mean writing less code. Sometimes you have to write a bit more vanilla JS to achieve the same behavior. But hey, a few extra lines of your own code are more maintainable than a monolithic utility library you don’t fully understand.

And finally, don’t become a “native API zealot.” If a library completely changes your productivity and makes your life easier, use it. The point of Baseline isn’t to shame you for using fancy libraries. It’s to help you make informed trade-offs. Just don’t ship `safe-password-generator` when `crypto.getRandomValues()` has been Baseline since 2015.

Bonus: How to Stay Up to Date with Baseline

The web platform evolves quickly. To stay on top of what’s becoming Baseline available, I do two things:

1. Check the **Web Platform Features** dashboard at [web.dev/baseline](https://web.dev/baseline) every month or so.
2. Read the **MDN Baseline news** section, which lists newly available features each month.

You can also follow the WebDX community group’s GitHub repo at [github.com/web-platform-dx/baseline](https://github.com/web-platform-dx/baseline). That’s where the magic happens.

Frequently Asked Questions

What exactly does “Baseline available” mean?

It means a feature is supported in the current and recent versions of all major browsers—Chrome, Edge, Firefox, Safari, and Opera. You can use it without a polyfill or fallback for those browsers.

Is Baseline the same as “caniuse.com”?

No, but they’re related. Caniuse gives you detailed compatibility tables, including older versions. Baseline distills that data into a simple “ready or not ready” label. It also ensures the information is context-aware—just because something works in Chrome 120 doesn’t mean it works in Safari 12.

What if I still need to support an older browser like IE11?

IE11 is dead, and even before that, it was an exception. Baseline explicitly excludes legacy browsers like IE11. If you must support such ancient environments, you’ll need to check individual tables and perhaps include polyfills for the APIs you pick. But in 2026, it’s safe to ask why you’re still supporting IE11—your users are the ones deciding to stick with old tech, and you’re paying the price.

How can I convince my team to start using Baseline?

Show them the numbers. Pick one dependency, estimate the bundle size and maintenance cost, then demonstrate the native replacement in a quick prototype. I did this with `lodash` in a previous job, and once my lead saw the diff—a 5KB utility replaced by two lines of vanilla JS—they were sold. Also point them to this post. 😉

The Bottom Line

Baseline isn’t just another compatibility tool—it’s a mindset shift. Instead of asking “what library should I use for this?” you start asking “what can the browser already do for me?” The moment you make that shift, JavaScript bloat starts to melt away.

Your users get a faster site. Your future self gets a cleaner codebase. And the web gets a tiny bit lighter for everyone.

Now go open your devtools, look at your project’s bundle, and see what you can cut. Your browser is probably already waiting with the answer.