365 - 《Mako 开发日志（5） - Why Mako》

1、背景是同事在重庆前端交流会 2023 上分享了「Rust 在前端构建高性能前端打包工具」，有人评论「还不如直接基于 Rspack 封装个 Rsfish，重复造轮子」（后来好像删了？），我回复了「评估过 Rspack，不满足内部需求。如果写一个功能类似的工具就是重复造轮子，那有了 Webpack 就没必要有 Rollup、Vite、Parcel、esbuild、… 了」，群里有人感兴趣，我就展开写下原因。

2、先说「重复造轮子」，这种无脑的评论可以针对任何一个工具或产品。比如看到 Linux，有 Unix 了，重复造轮子；比如看到 Vue，有 Angular 了，重复造轮子；比如看到 Preact、Solid，有 React 了，重复造轮子；比如看到 Rollup、Vite、Parcel、esbuild…，有 Webpack 了，重复造轮子；比如看到 Next.js，有 PHP 了，重复造轮子。但是，轮子有高低级之分，有些是为了造而造，有些则是问题驱动。

3、回到 Mako。项目 Kickoff 时就调研过社区的各个方案，结论是不合适。Farm 开发人员少，没大厂背书，落地少 edge case 会是个问题；Rspack 不喜欢其兼容 Webpack 的设计，兼容意味着权衡和潜在的性能消耗，既然重新用 Rust 写了，不如就更彻底一些；Turbopack 是最想和他摩擦出火花的一个，但无奈太封闭，商业公司的开源商业气息有点重，Next.js only，且当时只有 dev，同时也是我们太菜，看了好久他的代码没看懂。

4、我们在蚂蚁工作，Mako 肯定也是蚂蚁业务优先的。随着 Mako 开发的深入，以及和其他团队的沟通，Mako 对于我们来说，可能不仅仅是类 Webpack 构建工具那么简单。兼容 Webpack 不是我们想要的，服务 Umi 和蚂蚁的业务，