在线跑 JavaScript 越来越流行

过去一二十年，将 Javascript 跑在服务端的方式一直都存在，比如 Node.js、ASP 等。但近年来，这种将标准 Web API 规范跑在服务器上，进而实现 JavaScript Workload 的云边端同构的技术方案，被提炼成了一个新概念——JavaScript Container 或者说 W3C Web-interoperable Runtime 的在线运行时。目前，很多厂商都参与在其中，比如国内的阿里、字节，海外的 Cloudflare、Shopify、Vercel。

究其原因，主要有两个方面。一是 Serverless/FaaS/边缘计算等架构激发了对 Workload 被调度性能的追求，JavaScript 是配合网页出现的脚本语言，整个生态都是面向这一目标进行设计和优化的，包括启动速度、部署密度、相对合理的执行效率等等。二是最近两年 B/S 架构开始回归。在移动化进程中，传统 B/S 架构的 Web 逐步被冷落，甚至 B/S 中的 B（浏览器/WebView）也要先 HTML 白屏再加载一个 JS Bundle 再执行调用 API 展示页面，导致用户体验劣化，工程效率也被分散。这对在线服务架构的易用度提出了新要求。

在被调度性能方面，JavaScript 也有较大优势。在 Serverless 架构下，一门编程语言的被调度性能主要取决于三个因素：分发代码包的大小、用代码加载速度、内存占用。 首先，在分发代码包的大小方面，浏览器里面的 JavaScript 工具链很大一部分就是在解决这个问题，很容易移植到在线领域；其次，在代码加载速度方面， JavaScript 引擎一般都在用户代码加载速度方面定向优化，比如各种热启动的机制； 最后，在内存占用方面，JavaScript 虽然谈不上很低，但与 JVM 一类相比，还是小很多。 归其原因，Serverless 动态实例扩容的技术挑战，和 Chrome 里面新打开一个网页 Tab 的技术挑战，很多方面是重合的。

还有一个值得关注的方面是 JS 安全运行的问题。Node.js 是过去几年最流行的 JavaScript 在线运行时。和 Python、Java 以及其他一切 Runtime 一样，Node.js 提供了大部分的系统编程的能力，这正是不安全的来源。目前大部分编程语言 Runtime 本质上不仅仅是一个栈机，更多是在想办法把系统调用、libc 等等能力封装成一个又一个易用的编程语言 API，以解决在特定操作系统上单机编程的问题。 我们是否可以通过只提供 Web 合规的 API，来尽可能将 JS 安全地运行在在线环境，从起点上屏蔽这些问题？

在标准与具体实现方面，JavaScript Container 已经取得了不小的进展。目前有 W3C WinterCG 来进行一些标准的协同，基本上还是以 Service Worker API 为基础的一些扩展。而符合该标准的实现也比较多了，比如 Cloudflare Workers、EdgeRoutine、Deno、Noslate Workers 等等，Node.js 也对该标准在持续跟踪。另一方面，Next.js 13、Midway 这些上层研发框架，也已经开始兼容这一标准的运行环境。

同时，这种模式在 WebAssembly 方向上也有这种发展路径，比如最近新出来的 WasmEdge 项目，再比如前几年的 Nanoprocess 概念。大家无非是想拥有一个具备真正 Serverless 体验的编程环境和运维体系，靠技术的进步屏蔽运维成本。脱离系统 API 的安全性，高效的被调度性能，出了问题能被定位，这些做到后，我们将迎来真正的 Serverless。