作者：Ryan Dahl
原文链接：JavaScript Containers

服务端绝大部分程序都是 Linux 程序。这些程序一般由文件系统、一些可执行文件，一些共享的库文件（这些库文件与一些系统库例如 systemd 或者 nsswitch 做交互）。

Docker 让使用 Linux 容器变得更容易，也更流行。系统级别的虚拟化让发布服务端程序有一套不错的机制。每一个容器镜像都是一个无依赖且可以立即执行的软件包。

因为服务端软件经常依赖很多系统资源和配置，在过去部署这些软件是一件有挑战的工作。Linux 容器很好的解决了这个问题。

我们可以在浏览器的 JavaScript 发现一个类似这样的环境，只不过是一个更高层面（译者注：相比 linux 容器）的抽象。2018 年时，Cloudflare 公司的 Zack Bloom 的文章激发了我们对于 JavaScript 自身可以提供一种新类型的、独立的系统层级的容器。

我们去除不必要的抽象越多，我们就越接近 “互联网本身就是一台计算机” 这个概念。Cloudflare Workers（译者注：CLoudflare 的一种 serverless 服务）就是这种概念在 Cloudflare 公司在 Cloudflare 网络里的一种实现。Deno Deploy（译者注：Deno 公司提供一种基于 deno 的 serverless 服务）是一种这个概念的新实现（在 Google 的 GCP 网络中）。

在这个博文里，我会描述我关于 JavaScript 容器的理解，以及我认为这种技术在今后的日子里的可能的发展情况。

统一脚本语言[The Universal Scripting Language]

科技是非常难去预测的，但是可以肯定的是，10年以后，万维网（World Wide Web）仍然还存在。在过去的日子里，我们看到越来越多的人类基础设施通过 web 应用连接到了一起 - web 在吞噬整个世界。如果你认为 web 10 年后还存在，那么，组成 web 的标准 - HTTP、html、css、JavaScript 也同样会存活。所以，我非常自信的认为，JavaScript 仍然会被开发和改进。

web 是人类信息的基础载体。JavaScript 和其他编程语言不一样，这门语言植根在 web 基础设施中。

脚本语言对于很多服务端的问题意义重大。绝大部分脚本语言编写的代码，都不是计算负载重的代码，而是为了追求更高的效率：追求程序开发的速度以及更低的开发者工资的消耗。脚本语言可以让业务逻辑更快和更便宜的写出。脚本语言（包括不限于 Pthon、Ruby、Lua、Shell、Perl、Smalltalk、JavaScript）都差不多。它们之间的差异更多是语法和 api 上，但是其他方面的差别并不大。任何人只要在 Rust 或者 C 上花一些时间（译者注：当然也要写一些脚本语言）都能明白脚本语言的特点。

我总结一下：脚本语言是很有用的，但是它们都差不多，但是显然，JavaScript 是目前被应用最广泛的脚本语言，也是未来前景最好的脚本语言。所以我认为，JavaScript 可以作为统一脚本语言。

Shell : Executables :: JavaScript : WebAssembly

(译者注：这个标题模拟了 rust 调用名字空间里函数的语法。)

现在对于服务端软件诞生了一种更高层级抽象的容器：JavaScript 沙盒本身。

这个容器的目标不是为了接近 Linux 容器目标解决的问题。这种容器的出现本身就是这种容器简单架构的结果。这种容器最小化了 web 服务业务逻辑的样板代码。这种容器发展了浏览器的概念，减少了开发这种容器承载的代码的开发者需要知道的概念。（例如：写一个 web 服务，和任何一个 systemd 配置差不多，只不过不需要写那么多样板代码）（译者注：这里潜在的是说，有很多事云服务商通过接口和自身的服务帮开发者做了，开发者只需要关注业务逻辑就好了。）

每一个 web 工程师都已经非常熟悉浏览器的 JavaScript API。因为 JS 容器抽象是在同样的浏览器 API 之上构建的， 所以工程师使用这种容器需要的知识并没有增加很多。让 JavaScript 成为统一的脚本语言，可以有效减少复杂度。

Shell 是一种解释型脚本语言，用来调用 Unix 程序。它可以做条件判断，循环，也有变量。但是 Shell 编程的体验是比较差的。它更多的功能还是编写相对简单的可执行文件。

在这个正在发展的抽象容器层，JavaScript 可以取代 Shell 的地位。JavaScript 的各方面能力都远超 Bash 或者 Zsh。JavaScript 不但可以调用 Linux 可执行文件，就像 Shell 一样，JavaScript 容器也可以调用 WASM。如果你的业务由计算密集型的负载，例如图片调整，那可能直接使用 wasm 的能力，比编写 JS 程序要效率更高。就好像，你不会在 Bash 里编写图片调整的程序一样，你调用 imagemagick 命令。

北极星[The North Star]

脚本语言的未来是浏览器的 JavaScript。(我创始)Node.js 的一个基础错误是把 Node.js 的 API 没有与浏览器做统一，反而诞生了很多自己的 API。在 2010 年，我们没有 ES 模块，但是 JavaScript 有了 ES 模块，应该把这个模块标准直接带到 Node。同样的事情，还发生在 promises，async/await，fetch，stream 以及更多的 JavaScript 新增的功能里。更不要提过时的 Node 自有的功能例如 CommonJS require，package.json，node_modules， npm，全局 process 对象。这些功能应该要么被标准化，并且让浏览器提供，要么被浏览器的功能取代。（译者注，除了 CommonJS 这一点赞同，其他的几个功能，即便在目前看，并不是糟粕。RD 写这篇文章多少有贬低 node 抬高 deno 的嫌疑，所以读者们要辩证看待他的说法。）

这种更高级别的容器的标准化还不成熟。我们不知道多会可以完善这种标准。比如，Cloudflare Workers 和 Deno Deply 使用下面的 FetchEvent API：

addEventListener("fetch", (event) => {
  event.respondWith(new Response("Hello world"));
});

也许我们也能找到更好的写法（来做标准）。

结论

JavaScript 是统一脚本语言。因为 JavaSCript 能提供的统一性，一种新的容器类似的抽象正在萌芽，并且可以简化服务端软件。

我并不是说，Linux 容器会被淘汰。那个层面的抽象总是有意义的。只是对于大部分人们编写的“业务逻辑”来说，Linux 容器过于低层级。如果你是开发一些网站的服务，你如果用 Linux 容器，你仍然需要写很多类似 systemd 配置的模版代码。

也许绝大多数“web 服务”可以通过 JavaScript 容器极大的简化，而不是使用传统的 Linux 容器。

在 Deno 我们正在探索这种理念。我们的目标是极大简化服务端的抽象。如果你感兴趣，我们也在招人。HackerNews 评论。

链接: https://fly63.com/article/detial/11797