es-toolkit: A Faster, Smaller Lodash Replacement with a Compatibility Layer
A modern JavaScript utility library that's 2-3 times faster and up to 97% smaller-a major upgrade to lodash.
At a glance
- What is it?
- es-toolkit is a TypeScript utility library that claims 2-3x speed and up to 97% smaller bundles than Lodash, offering a compat mode for drop-in replacement. This review covers its mechanism, setup, limitations, and alternatives.
- Who is it for?
- Adopt es-toolkit if you need a modern, tree-shakeable utility library with strong TypeScript types and are willing to verify the 2-3x performance claims in your own runtime. Its compat mode makes it a low-risk Lodash replacement for most codebases, but you should test edge cases in functions you rely on, especially those not yet covered by the compat layer.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What es-toolkit Solves and Who It Is For
es-toolkit targets a specific pain: Lodash is battle-tested but carries a heavy payload and often slower performance in modern JavaScript engines. The README claims 2-3x better performance and up to 97% smaller code after tree shaking. That is a bold promise, and it matters for front-end bundles where every kilobyte counts. The library is aimed at developers who already use Lodash-style utilities but want faster load times and better TypeScript inference. It is also for teams migrating to modern build tooling that supports tree shaking natively. The README lists Storybook, Recharts, ink, and CKEditor as users, which suggests it has found traction in real projects, though the README does not say how those projects measure the benefits.
The Mechanism: Modern Implementations and Tree Shaking
The core idea is not a novel algorithm but a reimplementation of common utilities with modern JavaScript features. The README lists examples like debounce, delay, chunk, sum, and pick. These are written in TypeScript and designed to leverage current engine optimizations. Tree shaking works out of the box because the library is modular: each function is a separate export, so bundlers can drop unused code. The claimed 97% reduction is relative to other libraries, presumably Lodash, and depends on your bundler and usage patterns. The performance gain likely comes from avoiding legacy patterns that older libraries carry for compatibility with outdated environments. The README does not specify which JavaScript features are used, but the emphasis on modern environments implies that es-toolkit may not support older browsers without transpilation.
Getting It Running: Installation and Basic Usage
Installation is standard. The README shows importing from 'es-toolkit' on npm, and from '@es-toolkit/es-toolkit' on JSR. You can install it with your package manager, for example npm install es-toolkit. The example code is straightforward: import { chunk, debounce } from 'es-toolkit'; then use debounce to wrap a function and chunk to split an array. The debounce call returns a debounced function that you invoke later. The chunk example splits [1,2,3,4,5,6] into [[1,2],[3,4],[5,6]]. No configuration is needed beyond the import. For a Lodash drop-in, you can import from 'es-toolkit/compat', which the README describes as a complete compatibility layer. That is the path for existing Lodash codebases.
The Compat Layer: A Real Path for Migration
The most significant feature for adoption is es-toolkit/compat. The README calls it a complete compatibility layer to seamlessly replace Lodash. This means you can change your import statements from 'lodash' to 'es-toolkit/compat' and expect your code to work. The value is huge: you get the size and speed benefits without rewriting every utility call. However, 'complete' is a strong word. The README does not list which Lodash functions are covered, nor does it mention edge-case behaviors. Lodash has years of accumulated quirks that some code depends on. A compatibility layer that matches the common API but not the obscure corner cases could introduce subtle bugs. You should test your own usage patterns, not assume parity.
A Genuine Limitation: Performance Claims Need Verification
The README links to a performance page and a bundle-size page, but the supplied material does not include those numbers. The 2-3x and 97% figures are claims, not verified in this review. Performance claims in JavaScript libraries are notoriously environment-specific. A function that is faster in V8 might be slower in SpiderMonkey or JavaScriptCore. Also, the 97% reduction is for tree-shaken bundles, which depends on your bundler and how many functions you use. If you import the entire library without tree shaking, the savings shrink. The README says es-toolkit is battle-tested with 100% test coverage, but that does not guarantee that every Lodash edge case is replicated in the compat layer. For a project that relies on Lodash's exact behavior in rare cases, this library could be the wrong tool.
Alternative: Lodash Itself and Its Differences
The obvious alternative is Lodash, the library es-toolkit aims to replace. Lodash is older, larger, and slower in many cases, but it has a decade of production use and a massive ecosystem. The key difference in approach is that Lodash prioritizes compatibility and feature completeness over bundle size. Lodash also offers a modular version, lodash-es, which supports tree shaking but still carries more code than es-toolkit. Another alternative is native JavaScript methods: many utilities like chunk or sum can be written in a few lines with reduce or slice. For simple cases, you might not need a library at all. But if you need a drop-in replacement with a familiar API, Lodash is the safe baseline. es-toolkit's advantage is only realized if you measure it in your own bundle.
Maintenance and License Implications
es-toolkit is actively maintained. The last push was August 2026, with releases every few weeks: v1.52.0 in August, v1.51.0 in August, v1.50.0 in July. That cadence suggests ongoing bug fixes and feature additions. The license is MIT, which is permissive and allows commercial use, modification, and redistribution. The copyright is held by Viva Republica, Inc., the parent company of Toss. MIT means you can include it in proprietary software without paying fees, but you must retain the license notice. The maintenance cost for you is low: you can update the package regularly, but you should watch for breaking changes in minor versions, as the project is still pre-1.0? No, it is at v1.52.0, so semver applies. The README mentions an AI integration with Agent Skills, which is a niche feature, but it does not affect the core library.
Who Should Not Use It and What to Verify First
If your codebase relies on Lodash's exact behavior in obscure cases, or if you support very old browsers without transpilation, es-toolkit may not be ready. The README does not state browser support, so you should check the documentation. Before adopting, run your test suite against es-toolkit/compat. Measure your bundle size before and after. Benchmark the specific functions you use, not the whole library. The README claims 100% test coverage, but that covers es-toolkit's own functions, not your usage. Verify that the functions you need exist in the compat layer. The AI integration is a separate feature that you can ignore. The final decision should be based on your own measurements, not the README's marketing numbers.
Editorial conclusion
Adopt es-toolkit if you need a modern, tree-shakeable utility library with strong TypeScript types and are willing to verify the 2-3x performance claims in your own runtime. Its compat mode makes it a low-risk Lodash replacement for most codebases, but you should test edge cases in functions you rely on, especially those not yet covered by the compat layer. Do not adopt it if you require the exact behavioral quirks of Lodash in obscure cases, or if your project cannot tolerate the risk of a less mature ecosystem. Verify first by running your test suite against es-toolkit/compat and comparing bundle sizes with a tool like webpack-bundle-analyzer.
Community notes