作者｜Nicholas Yang
翻译者｜原子武器果汁
策画｜褚杏娟
倘若我们正在撰写后端标识符，那么会优先选择何种程式设计词汇？目前来看，最有希望的球手主要有三个：首先是最常规性的 JavaScript，然后是能校对为 WebAssembly（Wasm）的词汇，最终则是能载入 JavaScript 的词汇。
常规性 JavaScript 须要的基础建设工具最多，但付出是增容起来相当麻烦，标识符时效性也差。尽管优先选择 JS 确实门槛较高，不过除了盲目著迷“Becoming主义者”的蒙杜布洛县以外，我对个人真的那个快捷键只能说一般。
能校对为 Wasm 的词汇尽管越来越多，但总体上却是信息时代。这些词汇往往带有大量的十进制文件，因为当中大多须要配合附加的运转时。Interop 距离发展成熟还近在咫尺。另外，即使两种词汇都能载入 Wasm，也不代表者它之间就能较好实现互操作性。Longpr，那个派系的自然生态储备还远远远不如积累了几十年的 JavaScript DOM 库。在 Wasm 那边，React 和 Svelte 倘若是最好的快捷键了。我们千万T6670，我没错在雪藏 Wasm。它已经拥有专属于自己的表现T台，倘若我们想要在应用程序中运转高计算量原生植物标识符，但 Wasm 是最轻松的快捷键。可倘若不是此种情况，我对个人不太推荐用它进行日常后端开发。
最终剩下的是能载入 JavaScript 的词汇了。但那个派系逐步形成了四分五裂的局面，当中的大哥我们接著会具体内容讨论。相对而言，ClojureScript、Elm、ReScript、Dart 等词汇都逐步形成了颇具体内容量的街道社区，但今后市场占有率还能不能进一步扩大Montguyon。这就很难堪了，即便能载入 JavaScript 的词汇代表者的基本是应用程序上的最差程式设计新体验。在它的全力支持下，我们既能享受 JS 所不具备的较好功能，比如动态类别、强类别、相对性、宏等，同时也能通过 bindings 全力支持 JS 及其广泛的自然生态系。而且，它还不须要僵硬的大型运转时。
由于 Wasm 的存在，我怀疑 JS 校对派系会有所保留，即便很多人真的前者才是应用程序上的最差校对目标。我其实并不同意此种观点，能载入 JavaScript 的词汇却是圣埃卢瓦。总之，我想借这首诗跟我们谈谈现有及今后可能出现的后端词汇，倘若向着哪个方向发展。
TypeScript 还行吗？
这是我前文提到的 JS 校对派系中的“大哥”——TypeScript。TypeScript 是种很棒的词汇，显著改善了开发者新体验。它还新增了安全层，促进工具质量提升，并大大降低了使用准入门槛。考虑到自然生态系的繁荣现状以及对 JS 类别检查难题的妥善解决，TypeScript 确实取得了非凡的成就。
当然，也有不少针对 TypeScript 的非议值得关注。首先是这门词汇的性能和健全性问题。须要注意的是，TypeScript 团队其实很清楚这两大顽疾，而其根源是开发团队在项目之初做出的明确权衡。在我看来，这些权衡是当时为了提高执行效率而做出的正确优先选择。
话虽如此，但性能确实是 TypeScript 最受诟病的问题。TypeScript 是自实现的，而且此种实现非常复杂。它的类别系统本身可以算是种迷你程式设计词汇，这导致类别检查的速度极其缓慢。
第二个问题是健全性。这事的讨论热度没那么高，但在程式设计爱好者群体内部还挺受关注。概括来讲，TypeScript 一身都是“缺陷”——allwJs 配置快捷键、any 类别和 intersection 类别，其类别系统根本无法保证标识符的类别安全。换言之，我们撰写的 TypeScript 很可能会触发运转时 bug。另外，除了极其简单的场景之外，TypeScript 还缺乏可靠的类别推断，所以开发者在很多地方都得明确标出类别注释。
但同样的，这两点也是项目权衡的结果。
引导校对器的存在对于 TypeScript 的内部测试至关重要，这能帮助项目开发者理解 TypeScript 此种词汇用起来的真实感受。具体内容来讲，项目团队要新体验如何撰写大型 JS 标识符库，再逐步采用标识符库中的类别。在健全性方面放松一点，开发者才能在现有 JS 标识符库中逐步引入 TypeScript，也能轻松使用 any 类别来直接摆脱类别系统的束缚。
光是这部分就够单独写首诗了。在我看来，TypeScript 可能是第一种更多关注开发者新体验、而非自身语义的程式设计词汇。它并没有添加任何运转时结构、不插手性能，而是添加了一套类别系统，并让整个词汇街道社区接纳了此种不用类别也行、没高质量工具也行，还不强调正确性的自然生态氛围。这简直是个不可思议的壮举。
新一代后端词汇是什么样？
所有这一切都表明，TypeScript 早在十年前就做出了一众对自身产生巨大影响的权衡。而随着时间推移，我真的是时候通过新词汇再做一轮权衡了。确切来讲，我们须要一种具备健全性、类别推断和更快校对速度的词汇。
要求明确了，但我们该拿什么来换？
健全性
先从健全性说起。新一代词汇不再努力对各种 JS 模式进行类别检查，而是以独立词汇的形态通过更简单的类别系统将标识符载入 JS。它会将现有 JS 标识符视频外部互操作性对象，对 JS 标识符执行显式运转时类别检查，而且依靠不同的原生植物词汇来实现。
为什么要这样？首先，我对个人特别喜欢具备既健全、又相对简单的类别系统的词汇。我希望此种词汇能够在应用程序中运转较好，而且能顺畅适配现有 Web 自然生态系。那些能载入 Wasm 的词汇经常忽略 Web 自然生态系中的其余部分，总想在应用程序中建立起基于像素的原生植物 UI。我真的那个想法不错，只是跟我的观念相悖。我只想用新一代词汇开发常规性网站；我不想要纯函数式词汇，而更倾向于跟 C 的老派风格相似的词汇（对不起了，Elm！）；我希望此种词汇能体现出我在工具设计上的想法。
那为什么新一代后端词汇倘若诞生在现在那个时间点？俗话说得好，种一棵树最好的时机是十年前，其次是现在。这十年来，JS 街道社区已经发生了很大变化。人们开始学习 TypeScript，也习惯于关注校对器并通过类别进行数据建模。现在，很多开发者开始使用 Rust、Swift 和 Kotlin 等词汇，也意识到高质量工具的重要性。我不是说十年前的人们会抵抗强调类别安全的词汇，但那时候的普及难度确实更高。
明确表达了需求，有些朋友可能真的这说的不是 ReScript/ReasonML 吗？没错，确实有几分相像。但在理想情况下，我期待的新一代词汇倘若能对 JS 标识符和特性进行显式运转时类别检查。运转时类别检查是达成较好互操作性性的前提，这样我们就能更轻松地随意使用 JS 库。
同样地，我真的 traits 对用户来说也很重要，它可以跟其他词汇特性映射起来，比如 Java 接口和 C++ 概念。这可太方便了，比如轻松通过 Display trait 输出任意类别。这类需求听起来简单，但确实能大大提升词汇的可用性，消除“我该怎么输出那个？”或者“为什么 + 代表者整数加法，而 +. 代表者浮点加法？”之类特别劝退的问题。Longpr，我还想去掉一些没用的东西，比如对象、链表、多态变体等。这些都是 ReScript/ReasonML 做不到的，而且我上次试用的时候，ReScript 的开发新体验和错误消息也没给我留下深刻印象。
也是说，我不排除 ReScript 代表者着正确方向的可能性。即便上次尝试已经是几年之前了，也许是我记错了、也许它已经变得更好了。而且随着同 OCaml 的剥离，ReScript 确实成了很好的后端词汇快捷键，我有必要再确认一下。
类别安全
对于新一代后端词汇，我希望能用一种更系统的方法实现类别安全。具体内容来说，我真的用 Rust 处理非安全标识符块的方式实现 JS 互操作性性的好办法。基本上，在调用 JS 的过程中，我们须要将标识符打包在一个非安全标识符块中。这会是个明确的标志，提醒开发者要认真阅读这段标识符。接下来的目标，是在这些指向 JS 库的非安全标识符块上实现 bindings。起初那个过程须要手动完成，但后续倘若会有类似 bindgen 和 cxx 的工具出现。
在 JS 中使用非安全标识符块好像有点反直觉，即便 JS 的安全性又不像 C 那么糟糕。但很多人似乎没意识到，安全的意义并不仅限于安全本身。所谓安全，是指可以任意使用一个值、而不必担心其是否为 null 的保障能力。所谓安全，是在不致引入 Bug 或混乱的前提下保证可变性的能力。Rust 的非安全块概念允许用户既维护自己的安全区，又能与大量非安全标识符交互。新一代应用程序词汇也该做到这一点。
至于运转时检查，我真的它仍然物有所值。我们已经在 JS 当中进行过大量模式验证，只是以往只能通过 zod 这类临时性机制完成。在新一代后端词汇中，这类功能也许是在运转时出错时对词汇类别执行自动转换，也许能对 JS 值进行模式匹配。
对于 WebAssembly，我却是很看好它的发展前景的。但要说它一定能成为应用程序的通用运转时，我对个人却是持怀疑态度。也许今后我的态度会有转变，但目前我更多是将 Wasm 看作一种硬件加速器。
当用户的高强度计算任务要求调用固定宽度整数和动态函数时，我们就会使用 Wasm；这就像在须要执行并行计算时，我们会优先选择 GPU 一样。在这样的模型中，我看到了全力支持异构校对的潜力——当中部分标识符可以被载入 JS，另一部分标识符则可校对为 Wasm。这项工作可以由用户显式完成，由分析自动完成，甚至可以即时完成。通过对 JS 和 Wasm 标识符的同时控制，校对器就能最大限度减少跨越词汇边界的次数，从而提高性能水平。我真的今后甚至可以有某种机制将部分标识符发送给 WebGPU。
在这样的模型之上，也许我们可以更轻松地撰写计算密集型程序，比如机器学习模型、电子游戏和渲染软件。
此种对 Wasm 和 JS 进行分别校对的概念，可以在新一代后端词汇中体现出来。我希望当中能有显式整数和浮点类别，最好还能有 Rust 中 usize 那样的显式索引类别。这样倘若须要把标识符载入 Wasm，新词汇就能利用 Wasm 的固定宽度整数。
还有另一种可能性，是为词汇创建一个子集，在这里整合闭包、垃圾收集等动态特性以提升 Wasm 校对质量。要跟那个子集交互，开发者须要使用 unsafe 标识符块，比如 strict 块，或者让该子集通过 dynamic 块跟外部标识符交互。这些都是假设，但我真的当中确有探究的价值。
具体内容实现
此种新词汇可能会用 Rust 来实现。即便我对个人是 Rust 的粉丝，而且相信代数数据类别、相对更高的标识符性能、受限但可用的可变性，以及比较丰富的库组合足以支撑起一套优秀的校对器。
倘若 Wasm 后续发展得够好、性能几乎逼近原生植物水平，那我也会考虑使用由校对为高速 Wasm 标识符的词汇子集来引导校对器。但这倘若不着急，即便一个 Rust 校对器倘若就够用好多年了。
总 结
我们可能已经注意到，类别安全和 Wasm 部分其实是在从系统词汇（例如非安全概念和硬件加速）中汲取灵感，再把它应用到基于应用程序的词汇当中。这是设计使然，即便不少最有趣的程式设计词汇都是从系统层面衍生出来的。我只希望这些好点子也能在应用程序上有所体现。
这里我要澄清一下，我所指的新一代后端词汇绝不是单一词汇，我希望能有多种词汇齐头并进、向着前面提到的方向共同探索。我想激励更多朋友在应用程序词汇领域不断创新。当然，我对个人也会参与当中，目前正在研究的是名叫 vicuna 的实现方案，但还处于非常早期的阶段。
https://uptointerpretation.com/posts/the-next-browser-language/
声明：本文为 InfoQ 翻译，未经许可禁止转载。
