Back

Using es-toolkit for Everyday JavaScript Utilities

Using es-toolkit for Everyday JavaScript Utilities

If you’ve reached for Lodash to debounce an input, chunk an array, or pick keys from an object, you already know the value of a well-designed JavaScript utility library. The question worth asking today is whether Lodash is still the right default, or whether a leaner option fits better in modern TypeScript and ESM-based projects.

es-toolkit is an actively maintained JavaScript utility library built from the ground up with TypeScript, ESM, and modern JavaScript APIs in mind. It covers the helper functions frontend developers reach for most often — and it does so with a noticeably smaller footprint than Lodash.

Key Takeaways

  • es-toolkit is a modern, TypeScript-first utility library that ships with its own type definitions and supports clean tree-shaking out of the box.
  • It is production-ready, with adoption by Storybook, Recharts, and CKEditor, and an official recommendation from Nuxt.
  • Bundle size can be significantly smaller than Lodash, making it well-suited for client-side JavaScript where load time matters.
  • A compatibility layer (es-toolkit/compat) eases migration from Lodash, though the standard package is the better long-term choice.

What Is es-toolkit and Why Does It Matter?

es-toolkit is a modern JavaScript utility library that provides typed, tree-shakeable implementations of common helper functions. It’s written entirely in TypeScript, ships its own type definitions, and requires no separate @types/ package.

As noted in the es-toolkit documentation, the library is already used by projects and ecosystems including Storybook, Recharts, CKEditor, Material UI, and Nuxt. That level of adoption is a good indicator that the project is actively maintained and suitable for production use.

The library is organized into clear categories — array, object, function, string, math, and async utilities — each in its own module. That structure makes tree-shaking straightforward with any modern bundler.

Everyday Helper Functions, Covered

Here’s a practical look at the kinds of utilities es-toolkit handles well:

Array Utilities

import { chunk, groupBy, uniq, difference } from 'es-toolkit';

chunk([1, 2, 3, 4, 5], 2);                          // [[1, 2], [3, 4], [5]]
groupBy(['one', 'two', 'three'], (s) => s.length);  // { 3: ['one', 'two'], 5: ['three'] }
uniq([1, 2, 2, 3]);                                 // [1, 2, 3]
difference([1, 2, 3], [2, 3]);                      // [1]

Object Utilities

import { pick, omit, mapValues } from 'es-toolkit';

pick({ a: 1, b: 2, c: 3 }, ['a', 'c']);    // { a: 1, c: 3 }
omit({ a: 1, b: 2, c: 3 }, ['b']);         // { a: 1, c: 3 }
mapValues({ a: 1, b: 2 }, (v) => v * 2);   // { a: 2, b: 4 }

Function Utilities

import { debounce, throttle, once } from 'es-toolkit';

const handleSearch = debounce((query: string) => fetchResults(query), 300);
const handleScroll = throttle(() => updatePosition(), 100);
const initialize = once(() => setupApp());

Null-Checking and Type Guards

import { isNotNil } from 'es-toolkit';

const values = [1, null, 2, undefined, 3];
values.filter(isNotNil); // [1, 2, 3] — typed as number[]

TypeScript infers the narrowed type correctly here — something that requires more manual effort with Lodash and @types/lodash.

Bundle Size: A Practical Difference

When you import a single function from es-toolkit in a Vite project, only that function’s code is included in the bundle. Depending on the utility, the added bundle size can be extremely small compared to equivalent Lodash imports.

The gap is most visible when you import from the full lodash package without tree-shaking, which can add over 20 kB compressed.

The difference matters most for client-side JavaScript, where bundle size directly affects load time and Core Web Vitals.

Migrating from Lodash

If you’re moving an existing codebase, es-toolkit provides a compatibility layer:

// Before
import _ from 'lodash';

// After (compatibility mode)
import _ from 'es-toolkit/compat';

es-toolkit/compat is tested against Lodash’s own test suite and aims for full Lodash compatibility. That said, the standard es-toolkit package is the better long-term choice — it’s smaller, faster, and the TypeScript types are tighter.

The standard package also has a smaller and more modern API surface than Lodash, so reviewing the official documentation before large migrations is still a good idea.

When es-toolkit Makes Sense

Use es-toolkit when:

  • You’re starting a new TypeScript or ESM project and want typed utilities without a heavy dependency.
  • Bundle size is a concern and you want clean tree-shaking.
  • You need modern async helpers like delay with AbortController support.
  • You want built-in types without installing a separate @types/ package.

Stick with Lodash (or native JavaScript) when:

  • You have a large existing Lodash codebase and migration cost outweighs the benefit.
  • You rely on Lodash-specific patterns throughout an older application.
  • Your runtime environment predates modern JavaScript tooling.

Conclusion

es-toolkit is a practical, well-maintained Lodash alternative for modern JavaScript and TypeScript projects. It won’t replace every Lodash workflow immediately, but for new projects — or any codebase where bundle size and type safety matter — it’s worth considering as a default utility library.

FAQs

Not entirely. The standard es-toolkit package has tighter types and a smaller surface area than Lodash, so some function signatures differ. For easier migration, the es-toolkit/compat module mirrors Lodash's API and is tested against Lodash's own test suite. Most projects can migrate gradually by starting with compat and switching to the standard package over time.

It works in both. es-toolkit runs in modern Node.js, browsers, Deno, and Bun environments, and integrates cleanly with frontend bundlers like Vite, webpack, and Rollup.

Often, yes — especially if your current Lodash usage imports from the root package. es-toolkit is designed for modern tree-shaking and many utilities add very little to a production bundle. Exact bundle size differences depend on the functions you import and how your application is bundled.

No. es-toolkit is written in TypeScript and ships its own type definitions, so there is no need to install a separate @types/ package. Type inference also tends to be more accurate than Lodash with @types/lodash, particularly for type guards like isNotNil and generic helpers like pick and omit.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay