未来是否不再需要构建工具？

有时候在咖啡店里听朋友抱怨，老旧的构建链子像拖拉机一样慢，甚至把调试时间拉到凌晨。于是我不禁想：如果浏览器和运行时已经能直接理解 TypeScript、CSS‑in‑JS 甚至图形化的 UI 描述，我们还需要像 webpack 那样的「打包神器」吗？

原始需求的演变

最初，构建工具是为了解决模块化的碎片化：把分散的 .js、.css、.svg 合并成浏览器能直接加载的文件。那时候的浏览器只会识别 <script src="...">，于是「打包」成一个大文件成了唯一的出路。后来，热更新、代码分割、Tree‑shaking 让工具链越来越厚重，甚至出现了「构建即服务」的概念。

原生支持的萌芽

近几年，ESM 在浏览器里已经是标配，甚至有实验性的 import "<url>" 能直接拉取远端模块。Deno 把 TypeScript 当作第一语言，运行时会在后台悄悄把它编译成 JavaScript。想象一下，如果所有主流浏览器都把 .tsx、.scss 当作可直接解析的资源，开发者只需要写代码，交给浏览器的「即时编译」去完成剩下的事。

边缘计算与平台即代码

边缘节点已经能跑 WebAssembly，甚至直接执行 Rust、Go 编译后的二进制。把业务逻辑、UI 描述、数据验证全部写在同一个「函数」里，部署到 CDN 边缘，省去本地打包、上传、再部署的环节。这样一来，构建工具的价值从「把代码变成浏览器能跑的东西」转向「提供更细粒度的性能分析」或「生成离线缓存清单」之类的辅助功能。

仍然需要的场景

• 企业内部的私有库，需要统一的代码审计和压缩策略。
• 大型单页应用，仍然依赖代码分割和懒加载来控制首屏加载时间。
• 对旧浏览器的兼容性支持，必须把现代语法降级成 ES5。

所以说，构建工具或许不会“一刀切”消失，而是会从「必须」变成「可选」的角色。你觉得在不久的将来，打开编辑器敲几行代码就能直接在浏览器里跑出来的日子会不会成为常态？如果真的如此，今天我们花在配置 Babel、调研插件的时间，或许会被重新分配到业务创新上。