每 10 年 JavaScript 都会发生一次改朝换代式的变革。在我看来，JavaScript 当前正处于一次快速变革的开始，而这段时期未来可能会被称为 JavaScript 第三纪元。

本文最初发布于 shawn swyx wang 博客，经原作者授权由 InfoQ 中文站翻译并分享。

历说从头

JS 的第一纪元（从 1997 至 2007） 堪称虎头蛇尾。大家都知道 Brendan Eich 的故事，但是关于 ES4 是如何与诸如 Flash/Actionscript 之类的封闭生态系统艰难地进行激烈竞争的故事却鲜为人知。我推荐大家读读《JavaScript：20 年发展史》来了解 JS 起源的前前后后，我认为这本书是一个非常合适的选择, 因为该书是由 JS 的主要作者 Brendan Eich 和 Allen Wirfs-Brock 联手发布的。

JS 的第二纪元（从 2009 至 2019） 是从关键的 2009 年开始的，这一年诞生了 npm，Node.js 和 ES5。随着 Doug Crockford 在《JavaScript 精粹》一书中向我们展示了 JS 的精妙之后,JS 的使用者们创造出了一大堆的 JS 构建工具和库，并将 JS 的应用范围扩展到了台式机和新型智能手机。到了 2019 年，我们甚至看见，在手机端出现了诸如 Facebook 的 Hermes 之类的定制 JS 运行时系统，以及诸如 Svelte 3 之类的预编译前端框架。

译者注：

《JavaScript 精粹》，这本书的作者是 Doug Crockford，书中他主要从以 JS 的语法、对象、函数、继承、数组、正则表达式、编码格式以及一些优秀的功能等方面，向大家展示 JS 的精妙之处，同时也指出了 JS 的很多缺陷。

Hermes，是 Facebook 推出的一款运行在安卓系统中的 JS 引擎，该引擎对运行在安卓系统中的 React Native 应用做了性能优化，该引擎最大的特点是，会提前对代码进行静态优化和字节码压缩。

Svelte，是一个全新理念的前端框架，该框架最主要的 2 大特性是：

第一，将诸如代码检查、状态管理、动画等功能都做了封装；

第二，构建时会将源码直接转换为目标运行代码，而不是在运行时再处理（这里大家可以回想下在使用 webpack 构建的过程中，那个在运行时处理代码的 runtimechunk.js）。

JS 的第三纪元

2020 年感觉像是一个新纪元的开始。如果说第一个纪元是关于一个语言的诞生，第二纪元是关于人们对这个语言的探索和扩展，那么第三纪元则是与摒弃历史观念和工具层级折叠相关。

注：作者早期提出过层级折叠的观点

在当前的 JS 生态里，如果我们希望将编写的代码投入目标环境（例如浏览器环境）运行的话，大部分代码都需要通过几层工具的转换，如 TS 编译器、ESLint/JSLint、Less/Scss 、Babel、uglify 等，那么作者认为未来的趋势是，这些处理层会被尽可能的折叠。

首当其冲要摒弃的历史观念是：JS 生态需要依赖 CommonJS 模块系统，这种观念是不断妥协的结果。ES Modules 作为替代者已经伺机而动很久了，只是缺少一个一蹴而就的机会，主要的原因是，当前在使用中的工具虽然慢但是“已经够用”，于是大家缺乏更换的动力。在前端，现代浏览器虽然已经具备了处理一些 ES Modules 功能的能力，但一些重要的细节依然没有得到很好的解决。

译者注：

由于这些重要的细节没有解决，所以 V8 官方建议大家，在现代浏览器上使用 ES Modules 功能时，依然通过诸如 webpack、Rollup 之类的构建工具对源代码进行构建。

Pika 的 Snowpack 项目希望通过提供一个外观模式（facade）来加快 ES Modules 功能的提前应用，该模式会随着 ES Modules 的完善而逐步消失。最后来点鼓舞人心的消息，IE11 从今年开始至 2029 年将逐步结束其缓慢的发展历程。

另一个要摒弃的历史观念是：必须使用 JavaScript 构建 JavaScript 工具。 在热路径中，类型安全性和性能提升（10 到 100 倍）的潜力太大了，不容忽视。这种“只使用 JS 为 JS 构建工具”的想法，随着 TypeScript 几乎完全接管了 JavaScript 而逐渐消失，同时最近崭露头角的 Deno 和 Relay 也进一步证明了，人们将会通过学习 Rust 来向 JS 核心工具库做贡献。Brandon Dail 预测这种转变（工具的构建形式）将会在 2023 年完成。不过大部分使用中的非核心工具，由于其易用性相对性能更加重要，因此我们将依然会使用 JavaScript 和 TypeScript 进行编写。以前我们考虑的是“功能内核，命令式 Shell”，而现在我们应该考虑的是“系统内核，脚本 Shell”。

注：上面的观点也是有争议的。Python 的解析器 PyPy 就表明这不是一个既定的结论。

层级也在以有趣的方式进行折叠。Deno 采取了激进的方式，它编写了一个全新的运行时，同时将诸如测试、格式化、代码校验和打包等一堆常用的任务工具折叠到一个二进制文件中，针对 TypeScript 甚至直接包含了一个标准库。而 Rome 则采用了不同的方式，它还是基于 Node.js 将这些层折叠了起来（据我所知，这些使用起来很简单）。

10 年前，诸如 AWS、Azure、GCP 等公有云都还不存在，但是今天，它们已经是生活的一部分了。JavaScript 和云之间的关系非常微妙，以至于我都很难清晰的表述出来。云平台的开发者不会直接使用 JS，但是 JS 却又是他们最大的客户。AWS Lambda 第一个推出对 JS 的支持，它的一个明显变化是，折叠了 IDE 层和云服务层，移除了中间那个令人讨厌的笔记本电脑。许多诸如 Glitch、Repl.it、Codesandbox、GitHub Codespaces、Stackblitz 的云服务发行者都在利用 JS 来探索这个领域。与此同时，像 Netlify 和 Vercel 一样，JAMstack 从 PoV 开始，合并了 CI/CD 层和 CDN 层，移除了其间令人厌烦的运行时服务。

即使在前端框架中，层级折叠的发展同样鼓舞人心。从动画到状态管理，Svelte 将所有的事情都折叠到了编译器里。React 也在探索元框架和客户端与服务端集成的方案，同时 Vue 正在致力于开发一个称为 Vite 的“无需打包”的开发服务项目。

总结：

在 JS 第三纪元中，其构建工具的发展将会是下面几个方面：

更快
ES Modules 优先
层级折叠（事半功倍，而非事倍功半）
类型安全 / 类型安全检查（以强类型语言为核心进行构建，同时允许用户零配置支持 TS）
安全 / 安全检查（避免依赖注入攻击，或者不严格的权限）
新的同构策略（充分的认识到，JS 应该首先在构建时运行，或者在到达客户端之前在服务器端运行）

所有这些工作，最终都是促使开发体验（更快的构建，行业标准的工具化）和用户体验（更小的构建包，更快的功能交付）变得更好。这是 JavaScript 从脚本编程语言到完整应用平台的最终蜕变。

JavaScript 将死？

如果 Gary Bernhardt 的预言成真，那么第三纪元将是 JavaScript 的最后一个发展纪元（Gary Bernhardt 给出的时间结点是 2035 年）。Web Assembly 总是在 JavaScript 的周围若隐若现，甚至连 Brendan Eich 都改变了他的名言称：“永远押宝在 JS 和 WASM”，他最初认为 JS 可能是“通用虚拟机”，但是曾经有人告诉我，现在 WASM 就是这个想法的最终实现。

如果真如上面所说，那么我们现在正处于 JavaScript 消亡的边缘。

轮到你了

大约到 2030 年的时候，JavaScript 的第三纪元接近尾声，那时 JavaScript 将会有什么样的发展？请在下面评论区说出你的预测：

原文链接：https://www.swyx.io/writing/js-third-age/

创作场景

我们现在正处于 JavaScript 消亡的边缘？