谁将取代 JavaScript？

有些编程语言很受欢迎，还有些语言只是一种"必需品"而已。对于许多程序员来说，JavaScript就属于后者——每一位前端开发人员都需要理解这门语言，但人们用不着真心喜爱它。

十年前，我们还很难看出JavaScript将会统治世界。Java、Flash和Silverlight等平台曾位于舞台中心。这三大技术都需要使用浏览器插件来完成工作，它们也都用另一种用户界面方法取代了HTML。这种方法使它们在功能层面遥遥领先于JavaScript——比如，早在video元素、CSS动画规范或HTML画布诞生之前，我们就可以添加视频、动画和绘图。但这种方法也让它们走入了黄昏。当移动浏览需求爆炸式增长，HTML开始拥抱这一趋势的时候，其他平台就成为了时代的眼泪。

这段讽刺的历史如今要重演了。在JavaScript征服世界的同时，有人播下了一颗小小的种子，这颗种子可能在将来的某一天成长为参天大树，敲响JavaScript的丧钟——这就是名为asm.js的实验性技术。

不过展开这个故事之前，我们先退后一步看一看现状。

转译：当前方法

自从我们有了JavaScript，开发人员就一直在设法绕开它。早期的一种方法是使用插件把代码从浏览器中剥离（结果失败了）。另一个想法是开发出可以转换代码的开发工具，换句话说就是采用另一种更受人尊敬的语言编写代码，然后将其转换为JavaScript。这样开发人员就可以获得他们需要的全平台支持，同时并不会弄脏自己的双手。

将一种语言转换为另一种语言的过程称为转译（transpiling），其存在一些明显的缺陷。高级语言有着各自不同的功能、语法和习惯表达，你不可能把一种语言中的每一行都映射到另一种语言中的等效构造上。就算你能做到这一点也会留下许多坑。如果社区停止开发你最喜欢的转译器该怎么办？如果转译器自己就引入了许多错误该怎么办？想要插入Angular、React或Vue这样的JavaScript框架又要怎么解决？如果你会的语言和同事不一样，你又该如何与团队协作？

编程行业中很多情况本质都是一样的，那就是一种工具的水平主要取决于它背后社区的繁荣程度。

如今转译器是很常见的，但它们的用途几乎只有一条——那就是处理向后兼容性。

开发人员可能会编写最前沿的JavaScript，然后使用Babel这样的转译器将其代码转换为等效（但不太优雅）的老式JavaScript代码，以便在所有位置运行。或者更好的办法是，他们使用TypeScript（一种现代化的JavaScript，添加了强类型、泛型和非空类型等功能），然后将其转换为JavaScript。但不管是哪种方法，你都逃不出JavaScript的手掌心。

Asm.js：垫脚石

全新可能性的第一缕曙光来自asm.js，这是Mozilla的开发人员在2013年完成的一项古怪的实验。当时他们正在寻找在浏览器中运行高性能代码的方法。但asm.js并没有像插件那样尝试在浏览器外部运行；相反，它的目标是直接通过JavaScript虚拟机打出一条通道。

从本质上讲，asm.js是简洁且优化的JavaScript语法。它比普通的JavaScript运行得更快，因为它避免了这种语言中较慢的动态部分。而且支持它的Web浏览器也可以应用其他优化，从而显著提升性能。换句话说，asm.js遵循黄金法则——不要破坏Web——同时提供了一条未来改进的途径。Firefox团队使用asm.js以及称为Emscripten的转译工具把用C++构建的实时3D游戏放入Web浏览器中，需要的条件仅仅是JavaScript和达成目标的雄心壮志。

运行在asm.js上的虚幻引擎

asm.js的最大意义在于，它迫使开发人员重新思考JavaScript扮演的角色。Asm.js代码是JavaScript，但这些代码并不是让程序员手工读写的。相反，asm.js代码是由自动化流程（转译器）构建，并直接提供给浏览器的。JavaScript是媒介，但不是信息本身。

WebAssembly：一项新技术

尽管asm.js实验做出了一些令人眼花缭乱的演示，但主流开发人员大都无动于衷。对他们来说，这只是又一项有趣的技术概念而已。但随着WebAssembly的诞生，情况发生了变化。

WebAssembly既是asm.js的后继产品，又是一项截然不同的技术。这是一种紧凑的二进制代码格式。像asm.js一样，WebAssembly代码也被输入到JavaScript执行环境中。它具有相同的沙箱和相同的运行时环境。与asm.js一样，WebAssembly的转译机制也可以进一步提升效率。但是现在这种潜力比以前大得多，并且浏览器可以完全跳过JavaScript解析阶段。对于一段普通的逻辑（例如一段很费时的计算）来说，WebAssembly的执行速度远远快于常规的JavaScript，几乎与原生编译的代码一样快。

WebAssembly处理流水线的简化视图

想知道WASM长什么样的话，可以想象你有一个C函数，如下所示：

它编译成WASM代码后就成了下面这个样子：

开始向网络中传送时，WASM代码会进一步压缩为二进制编码。

WebAssembly设计为编译器的目标。你永远用不着亲自动手写它的代码。（但如果你想深入探索一番，自己写也是可以的。）

WebAssembly诞生于2015年。今天，桌面和移动设备上的四大浏览器（Chrome、Edge、Safari和Firefox）都完全支持它。InternetExplorer是不支持的，尽管可以将WebAssembly代码转换为asm.js来实现向后兼容。（兼容性的代价是性能损失。请让IE走进历史吧！

WebAssembly与Web开发的未来

WebAssembly是开箱即用的，为开发人员提供了一种（通常使用C++）编写优化代码逻辑的途径。这是强大的能力，但应用范围相对较窄。当你需要改善复杂计算的性能时这种方法很有用（例如，fastq.bio使用WebAssembly加快了他们的DNA测序计算。。如果你要移植高性能游戏或编写在浏览器中运行的模拟器，这种能力也很重要。但如果这就是WebAssembly的全部实力，那其实也没什么可激动的——光是这点东西可没希望取代JavaScript。但是WebAssembly还为框架开发人员提供了一条狭窄的路径，使他们可以将其平台塞入JavaScript环境中。

这下事情就变得有趣了。WebAssembly无法绕开JavaScript，因为它已锁定在JavaScript运行时环境中了。实际上，WebAssembly需要与最起码少量的普通JavaScript代码搭配运行，因为前者无法直接访问网页。这意味着如果不经过JavaScript层，WASM就无法操纵DOM或接收事件。

听起来这个限制是致命的。但是聪明的开发人员已经找到了通过WebAssembly塞进他们自己的运行时的办法。例如，微软的Blazor框架会下载一个小型.NET运行时作为已编译的WASM文件。这个运行时处理JavaScript互操作，并提供基本服务（如垃圾回收）和更高级别的功能（布局、路由和用户界面小部件等）。换句话说，Blazor使用了一个驻留在另一个虚拟机中的虚拟机，堪称《盗梦空间》级别的悖论，也是一种在浏览器中运行非JavaScript应用程序框架的巧妙方法。

Blazor并不是唯一一个由WebAssembly支持的实验。还可以看看Pyodide，其旨在将Python放入浏览器中，它带有用于数据分析的高级数学工具包。

这就是未来。WebAssembly最初是为了满足C++和Rust等需求而诞生的，却很快就被用来开发目标更加远大的实验。不久的将来，它就会支持非JavaScript框架与Angular、React和Vue等基于JavaScript的对手同台竞技。

而且WebAssembly仍在迅速发展。它目前的实现只是一款最小可行产品——只够在一些重点场景中使用，还不是万能的Web开发方法。随着WebAssembly的推广，它也会不断进化。如果像Blazor这样的平台流行起来，WebAssembly可能会增加对直接DOM访问的支持。浏览器开发商还在计划添加垃圾回收和多线程支持，这样运行时就不需要自己实现这些细节。

看起来这条发展道路漫长而充满变数，但请回想一下JavaScript的历史。首先，我们发现JavaScript能做到的事情都会写成JS代码。然后我们意识到，如果一件事情重复的次数够多，浏览器就会让它做得更好，如此循环。如果WebAssembly开始流行，它将进入一个良性循环，不断发展，很容易就能超越JavaScript的固有优势。

人们经常说，WebAssembly并不是用来代替JavaScript的。但这句话对所有革命性平台都是一样的。JavaScript当初并不是要取代嵌入浏览器的Java。Web应用程序并非旨在替代桌面应用。但一旦能做到这些，它们必然会走上那条路。

作者介绍

MatthewMacDonald是教师、程序员和许多大部头的作者。

英文原文

https://medium.com/young-coder/what-replaces-javascript-a6493b4e2d6e

封面图来自pexels