![]()
2024年还在用Lodash的新项目,相当于2024年买燃油新车——不是不能用,是有更好的选择你却不知道。
npm周下载量92M的Lodash,这个数字看着吓人,实则水分不小。Toss团队在2024年推出的es-toolkit,周下载量已经冲到850万,Storybook、Recharts、ink、CKEditor这些生产级项目全切过去了。差距在哪?打包体积97%的缩减,从Lodash的60KB+压到2KB左右。
Core Web Vitals(核心网页指标)现在直接挂钩搜索排名, bundle size不是美学问题,是业务问题。es-toolkit的tree-shaking做得干净,你import一个debounce,最终包里就这一个函数,不会拖进来半套工具库。
速度差2-3倍,不是优化出来的,是重写出来的
benchmark数据上,es-toolkit比Lodash快2-3倍。这不是算法优化,是前提条件变了——Lodash的代码要兼容IE时代的运行时,es-toolkit只认现代JS引擎。相当于一个背着历史包袱,一个轻装上阵。
TypeScript支持是另一道分水岭。Lodash的类型定义靠@types/lodash维护,和源码分开迭代,运行时和编译时偶尔对不上号。es-toolkit的类型和实现同仓库,isNotNil这种type guard直接内置,不用自己写断言。
迁移成本被压得极低。es-toolkit/compat层让你渐进式替换,Vite用户更省事,vite-plugin-es-toolkit自动改写import路径。测试覆盖率100%,不是"我们认为稳定",是CI里每一行都被跑过。
那Lodash的92M下载量到底是谁在用
![]()
拆开看,72M是lodash本体,加上lodash-es约92M。但这里面大量是传递依赖——你装了个老工具库,它依赖Lodash,你的node_modules里就多了一份。直接调用的比例在下降,存量项目的惯性在维持数字。
维护老代码库的团队,熟悉的API本身就是资产。Lodash的文档厚度、边缘case处理、社区问答沉淀,都是切换成本。问题是:新项目为什么要主动跳进这个成本?
ES2024+的原生能力已经填掉不少坑。以前用_.isArray是因为typeof array === 'object'太蠢,现在Array.isArray原生可用。库的存在需要重新justify自己的价值,而不是默认被需要。
2026年选工具库的三条新规则
第一,TypeScript支持必须是first-class,不能是外挂的类型定义。第二,bundle size要可审计,CWV分数会反馈到业务指标上。第三,性能基准要针对现代引擎, backwards compatibility不再是美德,是债务。
es-toolkit符合全部三条,所以850万周下载量不是 hype,是生产环境的投票。Storybook这种被数百万项目依赖的工具链切过去,相当于给整个行业做了尽职调查。
还在用Lodash的新项目,相当于2024年买燃油新车——不是不能用,是有更好的选择你却不知道。而那个"更好的选择",安装命令只有一行:npm install es-toolkit。
你的新项目启动时,package.json里第一个工具库会写什么?
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.