|
作者｜Nicholas Yang
译者｜核子可乐
策划｜褚杏娟 假如大众正在编写前端代码，那样会选取哪种编程语言？日前来看，最有期盼的选手重点有三个：首要是最常规的 JavaScript，而后是能编译为 WebAssembly（Wasm）的语言，最后则是能编译成 JavaScript 的语言。
常规 JavaScript 需要的配套工具最少，但代价是调试起来相当麻烦，代码可读性亦差。虽然选取 JS 确实门槛较低，不外除了一味痴迷“极简主义”的铁粉以外，我个人觉得这个选项只能说通常。
能编译为 Wasm 的语言虽然越来越多，但总体上还是新生事物。这些语言常常带有海量的二进制文件，由于其中大多需要协同额外的运行时。Interop 距离发展成熟还差得远。另一，即使两种语言都能编译成 Wasm，亦不表率它们之间就能良好实现互操作。再有，这个阵营的生态贮存还远远比不上累积了几十年的 JavaScript DOM 库。在 Wasm 这边，React 和 Svelte 应该是最好的选项了。大家千万别误会，我可不是在唱衰 Wasm。它已然持有专属于自己的表现舞台，倘若大众想要在浏览器中运行高计算量原生代码，但 Wasm 便是最完美的选项。可倘若不是这种状况，我个人不太举荐用它进行平常前端研发。
最后剩下的便是能编译成 JavaScript 的语言了。但这个阵营形成为了一家独大的局面，其中的老大咱们稍后会详细讨论。相比之下，ClojureScript、Elm、ReScript、Dart 等语言都形成为了颇详细量的社区，但将来市场份额还能不可进一步扩大尚未可知。这就很尴尬了，毕竟能编译成 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 可能是第1种更加多关注研发者体验、而非自己语义的编程语言。它并无添加任何运行时结构、不插手性能，而是添加了一套类型系统，并让全部语言社区接纳了这种不消类型亦行、没高质量工具亦行，还不强调正确性的生态氛围。这简直是个难以置信的壮举。
下一代前端语言是什么样？
所有这一切都显示，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 输出任意类型。这类需要听起来简单，但确实能大大提高语言的可用性，消除“我该怎么输出这个？”或“为何 + 表率整数加法，而 +. 表率浮点加法？”之类尤其劝退的问题。再有，我还想去掉有些没用的东西，例如对象、链表、多态变体等。这些都是 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 翻译，未经许可禁止转载。 今日好文举荐
反Twitter平台用户激增250万，这名29岁程序员怎样凭一己之力扛住超8倍流量增长？
张勇、刘强东、马化腾接连“发飙”，痛批内部问题；头条抖音飞书起始优化，部分员工零赔偿；推特自马斯克接管败兴首次大范围宕机｜Q新闻
取代搜索，“干掉”艺术家？顶流「AIGC」的疯狂与争议
市场增速超20%，国产操作系统“浴火重生” | 诠释操作系统的 2022
| 
发表于 2024-7-29 10:22:35
