es-toolkit in 2026: The Lodash Replacement That's 2× Faster and 97% Smaller

For more than a decade, lodash was the reflex answer to “which utility library should I use?” It was everywhere, it was reliable, and it quietly shipped in almost every JavaScript project on earth.

But the JavaScript of 2026 is not the JavaScript lodash was designed for. We have native Array.prototype methods, optional chaining, nullish coalescing, structured clone, and engines that optimize modern code aggressively. Meanwhile bundle size has become a first-class performance budget: every kilobyte you ship is paid back in slower LCP, heavier cold starts, and worse Core Web Vitals.

That is the gap es-toolkit was built to close. It bills itself plainly: a modern JavaScript utility library that is 2-3 times faster and up to 97% smaller — a major upgrade to lodash. This article unpacks what that means in practice, shows the migration path, and is honest about when you do not need it.

What es-toolkit actually is

es-toolkit is a state-of-the-art, high-performance utility library written in TypeScript. It gives you the familiar toolbox — debounce, throttle, chunk, groupBy, pick, omit, sum, delay and dozens more — but rebuilt for the modern ecosystem.

The headline numbers, straight from the project:

• 2-3× faster than lodash on the library’s own benchmarks.
• Up to 97% smaller bundle footprint per function.
• 100% test coverage, written almost entirely in TypeScript (99.4%).
• MIT licensed, maintained by Toss (Viva Republica) with hundreds of contributors and 11k+ GitHub stars.

It is not a hobby project. es-toolkit is already a production dependency inside tools from Microsoft, IBM and Yarn, as well as Storybook, Recharts, MUI, ink and CKEditor — software that millions of developers rely on every day.

Why it is smaller: tree-shaking by default

The biggest practical win is bundle size, and it comes from one architectural choice: es-toolkit tree-shakes cleanly out of the box.

When you import a single function, you get that function and its minimal dependencies — nothing else.

npm install es-toolkit

import { chunk, debounce } from 'es-toolkit';

const groups = chunk([1, 2, 3, 4, 5], 2);
// [[1, 2], [3, 4], [5]]

const onResize = debounce(() => {
  console.log('resized');
}, 200);

With lodash, naively importing from the package root could pull in a large chunk of the library’s internals. The community worked around this for years with lodash-es, lodash.debounce micro-packages, and Babel plugins. es-toolkit makes all of that unnecessary: the slim, modern build is the default, not an opt-in.

For a bundle-sensitive frontend, swapping a handful of lodash helpers for es-toolkit can shave a meaningful slice off your JavaScript payload — and you can confirm the exact delta on the project’s bundle-size page (es-toolkit.dev/bundle-size.html).

Why it is faster: modern engines, no legacy ballast

lodash carries years of compatibility code for environments that no longer matter. es-toolkit starts from a clean slate: it leans on native language features and is implemented for the way today’s engines actually optimize.

The result is that the common hot-path utilities — array transforms, grouping, debouncing — run measurably faster. The maintainers publish reproducible benchmarks at es-toolkit.dev/performance.html, so you do not have to take the claim on faith.

For most apps the per-call difference is invisible. But in tight loops, data-processing pipelines, and high-frequency event handlers, 2-3× adds up.

TypeScript-native, with type guards built in

es-toolkit is written in TypeScript, so the types are first-class rather than bolted on through a separate @types package. You get accurate inference, and the library ships practical type guards that improve both safety and ergonomics.

import { isNotNil } from 'es-toolkit';

const values = [1, null, 2, undefined, 3];

// TypeScript narrows this to number[]
const clean = values.filter(isNotNil);

Helpers like isNotNil do double duty: they remove the noise at runtime and narrow the type at compile time, which removes a whole category of as casts and non-null assertions from your codebase.

The migration path: one line, not a rewrite

The fear with any “replace lodash” pitch is the migration cost. es-toolkit answers it directly with a compatibility layer: es-toolkit/compat, which mirrors the lodash API.

The simplest migration is to alias lodash to the compat layer in your bundler. In webpack:

module.exports = {
  resolve: {
    alias: {
      lodash: 'es-toolkit/compat',
      'lodash-es': 'es-toolkit/compat',
    },
  },
};

Or, if you prefer to be explicit, just change the import path and keep your call sites untouched:

// before
import { cloneDeep } from 'lodash';

// after — same API, modern engine
import { cloneDeep } from 'es-toolkit/compat';

The recommended rollout is staged:

1. Swap to es-toolkit/compat and confirm your test suite stays green.
2. Migrate the hot paths and the most-imported helpers to the slim main es-toolkit entry to claim the full speed and size wins.
3. Leave anything exotic on compat until an equivalent lands.

This is what makes the switch realistic for a large codebase: you do not stop the world to do it.

es-toolkit vs lodash vs native: a quick map

A useful way to think about it in 2026:

• Reach for native first. Array.prototype.map/filter/flat, Object.entries, structuredClone, and optional chaining cover a surprising amount of what people used to import lodash for.
• Reach for es-toolkit when native is awkward or missing: debounce, throttle, chunk, groupBy, pick, omit, sum, delay, deep clone/merge, and robust type guards.
• Reach for lodash only when you genuinely depend on a long-tail function es-toolkit has not covered yet — a shrinking list.

es-toolkit sits exactly where it should: it picks up where the language stops, without the weight lodash brings.

Beyond the basics: fp, JSR, and agent skills

The project is not standing still. A few things worth knowing in 2026:

• es-toolkit/fp — a functional, pipeline-friendly module for those who like point-free, data-last composition.
• JSR support — es-toolkit is published on JSR (@es-toolkit/es-toolkit) as well as npm, which makes it first-class for Deno and modern toolchains.
• AI agent skills — you can pull the library’s usage guidance into an agent with npx skills add toss/es-toolkit, so AI assistants generate idiomatic es-toolkit code instead of lodash habits.

These are signals of a library investing in where the ecosystem is going, not just where it has been.

When you do not need it

Honesty matters more than hype, so here is the counter-case:

• If your project already standardized on lodash-es with working tree-shaking and bundle size is not a concern, the upside is smaller.
• If you only use one or two helpers, a native implementation or a single micro-package may be all you need — no dependency required.
• If you depend on a niche lodash function with no es-toolkit equivalent, staying put for that one path is fine; use compat for the rest.

The point of es-toolkit is not to chase novelty. It is to stop paying the lodash tax — in bytes and milliseconds — when you no longer have to.

Verdict

For new code in 2026, es-toolkit is the sensible default: faster, dramatically smaller, TypeScript-native, battle-tested in major open-source projects, and backed by an active maintainer in Toss. For existing code, the es-toolkit/compat layer turns what used to be a daunting migration into a one-line change you can roll out gradually.

If you are still importing lodash out of habit, this is the year to revisit that reflex. Install es-toolkit, alias your imports, watch your bundle shrink, and move on.

npm install es-toolkit