tossJun 24, 2026

es-toolkit: How a Small Internal Library Became a Global Project (opens in new tab)

es-toolkit began at Toss as a modern alternative to lodash, addressing its outdated architecture, legacy-browser code, lack of native ECMAScript Module support, and inefficient implementations. By removing unnecessary logic and relying on modern browser APIs, es-toolkit achieved 2–10× performance improvements and, in some cases, reduced bundle sizes by more than 30×. Its open-source momentum attracted global contributors, eventually helping it become widely adopted. ## The Beginning of es-toolkit - Toss developers needed dependable utilities such as `throttle`, `debounce`, and `uniq`. - Although lodash was widely used, it had several limitations: - Outdated code structure and implementations. - Defensive logic for legacy browsers such as Internet Explorer. - Little use of native APIs like `Array#map`. - No ECMAScript Modules, making tree-shaking difficult. - `lodash-es` added ESM support but retained much of lodash’s older and inefficient implementation. - Toss’s internal `@toss/utils` library required significant effort to maintain and handle edge cases. - es-toolkit was created to provide a modern, efficient utility library for current web development. - Initial results showed: - At least 2× and sometimes over 10× faster execution. - Bundle-size reductions of more than 30× in some cases. ## Open-Source Adoption and Community Growth - Toss initially announced es-toolkit through its frontend social media channels. - Developers contributed missing functions, bug fixes, and performance improvements. - After gaining attention in Korea, the project was shared on Reddit and received over 100 upvotes and tens of thousands of repository visitors. - International discussions led to coverage in blogs and newsletters. - Community members created bundler plugins and migrated dependencies in established libraries from lodash to es-toolkit. ## From Contributor to Toss Developer - Dayong Lee discovered es-toolkit through Toss’s announcement and began contributing despite not being a Toss employee. - Starting with small pull requests, he gradually became the project’s second-largest contributor. - Code reviews helped him develop stronger skills in: - JavaScript language features. - API and interface design. - Open-source collaboration. - His involvement with es-toolkit eventually contributed to his joining Toss Bank. ## Making Migration Easier with `es-toolkit/compat` - Although the library was becoming more complete, adoption remained slow because many projects depended heavily on older utility libraries. - Migrating individual lodash functions across a large codebase would be tedious and risky. - es-toolkit therefore introduced `es-toolkit/compat`, a drop-in replacement designed to preserve lodash’s interfaces and behavior while modernizing its internal implementation. - This compatibility layer reduced migration effort and allowed projects to gain performance improvements by changing imports rather than rewriting utility usage. - The layer was particularly important because es-toolkit’s streamlined behavior could otherwise differ from lodash in edge cases and cause runtime errors. es-toolkit’s story demonstrates how a focused modernization effort can replace entrenched legacy dependencies. Providing both a faster native-style library and a compatibility layer made adoption more practical while enabling broad open-source participation.

tree-shakingjavascriptfrontend-developmentes-toolkit+3

tossJun 22, 2026

es-toolkit: How an Internal Little Library Became a Global Library (opens in new tab)

es-toolkit began as Toss’s effort to create a modern alternative to lodash, removing legacy code and optimizing for current JavaScript environments. By focusing on common use cases, it achieved 2–10× faster performance and reductions in bundle size of more than 30×. Community adoption, compatibility tooling, and contributions to major projects eventually pushed it beyond 20 million weekly npm downloads. ## Why es-toolkit Was Created - Developers frequently needed utilities such as `throttle`, `debounce`, and `uniq`, but existing options had drawbacks. - lodash contained legacy implementations, Internet Explorer workarounds, and limited ECMAScript Modules support. - Even `lodash-es` mainly added ESM support without modernizing the underlying code. - Toss had maintained its own `@toss/utils`, but handling utility-function edge cases internally was burdensome. - es-toolkit’s goal was to remove unnecessary logic, improve performance, and produce smaller bundles for modern web applications. ## Performance and Bundle-Size Improvements - Reimplementing core lodash-style functions produced: - At least 2× faster execution for some functions. - More than 10× faster execution for others. - Using modern built-ins such as `Array#map` eliminated compatibility code. - Bundle sizes were reduced by more than 30× in some cases. - The project was designed around the most common use cases rather than every historical edge case supported by lodash. ## Growth Through the Open-Source Community - The first release was shared through Toss’s frontend social channels and quickly attracted users and contributors. - Contributors added missing functions, fixed bugs, and optimized implementations. - After promotion on international developer communities, the project received more than 100 recommendations and tens of thousands of repository visitors. - Blogs and newsletters helped extend its reach. - Community members created migration plugins and independently replaced lodash dependencies in other libraries. ## From Contributor to Maintainer - Toss Bank developer Dayong first joined as an external contributor, submitting small pull requests. - Reviewing and designing interfaces for es-toolkit provided valuable experience with JavaScript and API design. - Continued contributions eventually made her the project’s second-largest contributor and helped lead to her joining Toss Bank. - The project also demonstrated how an open-source initiative can connect contributors across companies and countries. ## Lowering the Migration Barrier with `es-toolkit/compat` - Adoption was initially slow because applications often imported many lodash functions throughout their codebases. - Replacing every import manually would make migration expensive and risky. - es-toolkit’s standard implementations also differed from lodash in some edge cases. - `es-toolkit/compat` was introduced as a drop-in replacement: - It preserves lodash-compatible interfaces and behavior as much as possible. - It modernizes the internal implementations. - Projects can gain performance and bundle-size benefits with minimal code changes. - This helped major projects such as Storybook, Mermaid, Yarn Berry, and Recharts adopt es-toolkit. ## Future Direction - es-toolkit plans to help more JavaScript libraries reduce their bundle sizes and improve efficiency. - It aims to add modern utilities, including: - `filter`-style functions for `Map` and `Set`. - Promise-based helpers such as `delay`. - Server-oriented utilities for Node.js, Deno, and Bun. - New functions such as `exec` are intended to provide essential functionality with smaller implementations than competing libraries. - The project plans to maintain its core principle: optimize for more than 80% of common use cases while remaining small, fast, and high quality. es-toolkit’s success shows that a focused, modern implementation can replace widely used legacy utilities when it combines measurable technical benefits with strong migration support and active community participation.

tree-shakingopen-sourcetypescriptjavascript+3