JavaScript 工具链的“中年危机”
The JavaScript Midlife Crisis
JavaScript 从未像今天这样无处不在，却也从未像现在这样在自己的后花园里迷失。曾经由 JavaScript 构建的工具链，如今正被 Rust、Go 和 Zig 等语言以十倍速重写。我们追求毫秒级的构建速度，却逐渐失去了对工具内部的控制权。当开发者不再能读懂自己依赖的工具代码，当开源社区的大门因语言壁垒而关闭，我们是否正在用速度换取生态的透明与活力？这场工具链的“中年危机”，或许比语言本身的更迭更值得深思。
我们正在为喜欢慢悠悠的蒸汽火车铺设越来越快的轨道。
HN 评论区
54- Klonoar
用 Rust 重写一个打包器，你不仅让它变快了，还缩小了能维护它的 JavaScript 开发者群体。新工具看起来像鸭子，叫声也像鸭子，但本质上完全是另一回事。它的内部退化成黑盒，掌握钥匙的人越来越少。源码或许仍是开源的，但贡献的大门正在关闭。
或者换个角度想，本来就不应该由那群 JavaScript 开发者来维护关键基础设施。
这并非黑盒，那些代码库通常是开源的，唯一阻碍你或任何人的，只是不愿走出 JavaScript 这个小池塘去学点别的东西。
用快速语言写非浏览器端的东西。这概念并不复杂——在这个很多东西都能自动生成的时代，尤其如此。
- cisc
我不禁开始琢磨，我们该拿它刚刚还给我们的那些宝贵毫秒做什么？
速度很重要。WebAssembly 之所以能从 JavaScript 手中抢走工作，正是因为它更快。
Google Sheets 的计算引擎在切换到 WebAssembly 后速度提升了一倍：https://web.dev/case-studies/google-sheets-wasmgc
Amazon Prime Video 应用在切换到 WebAssembly 后速度也提升了一倍，且性能波动更小：https://www.amazon.science/blog/how-prime-video-updates-its-...
编译为 WebAssembly 让每种语言都能在浏览器中运行。Google 用的是 Java，Amazon 用的是 Rust。
- msteffen
异端观点：JavaScript 之所以如此成功，很大一部分原因在于解释型语言实际上可以极快——能与编译型语言媲美，甚至在许多情况下更快，而 V8 arguably 是现存最快的解释器。
参见 Mike Pall（LuaJIT 的作者，其性能与 V8 相当甚至更快，尽管这基本上是一个单人项目）的这篇帖子，解释了原因：https://web.archive.org/web/20180603053407/http://article.gm.... 基本上，在 JIT 解释器中添加高质量的运行时追踪感知重编译要容易得多，而非追踪感知的编译型语言往往无法战胜这一点。
- agentultra
你可以选择等待那些运行缓慢且占用大量多余内存的程序，当然。
或者，你也可以拥有运行快速且内存使用高效的程序。
只是你没法用 JavaScript 做到这一点。当然，通过精心工程化，JavaScript 也能达到很高的性能……但即便有所有的 JIT 编译和追踪垃圾回收机制，收益递减的墙依然很高。
没什么能阻止那些同样的 JavaScript 开发者去学点 Zig 或 Rust 之类的语言。这实际上可能比死记硬背 JavaScript 所有的隐式类型转换规则还要容易。
但如果这要求太高，那就待在 JavaScript 的世界里，并确保有 JavaScript 开发者来编写工具吧！
- hn_submit
JavaScript 是个不该被留活的怪物。
是的，我也自问：“哪个理智的人会想在服务器上运行 JavaScript，甚至用它写业务逻辑？”看来这世上傻瓜真不少。JavaScript 就是导致如今我们的文本编辑器需要 16GB RAM 才能运行，而一个简单的天气应用也要 1GB 内存的罪魁祸首。
在老日子，汇编程序员大概能用几 KB 就写出那个天气应用（那可是少了一百万倍的内存，伙计们）。