JavaScript 悖论

我不确定是否有一种语言像 JavaScript 一样，被人们如此厌恶，却又被如此广泛地使用。

我不属于那一派。我挺喜欢 JavaScript。它的怪癖，它的缺陷。它如何以 Scheme 为基础构建，却注定成为最普及的编程语言。

JavaScript 的设计初衷是成为一种伴侣。它是一种脚本语言，用于执行一些琐碎的任务，辅助页面上的小部分交互。它是 Web 语言。

但网络的发展远超其最初的规模。它涵盖了各种体验和设备。从电脑、手机、电视、手表到各种物联网设备。从简单的内容网站到沉浸式虚拟现实视频游戏。

JavaScript 也随之而来。

非凡的宇宙力量，极小的生存空间

Web 基金会反复向我们展示的一件事是，网络作为一种资源有多么重要。大多数编程都关注内存或磁盘速度，但 Web 始终关注网络。这一点，加上 JavaScript 是一个跨平台的编程语言，并且是唯一可用的选择，导致了 JavaScript 的发展变得极其特殊。

虽然 JavaScript 无论从哪个角度来看都是一门解释型动态类型脚本语言，但它现在是一个转译器、一个 DSL 的熔炉，以及一整套工具链。JavaScript 的机器早已取代了灵魂。它需要满足所有人的需求，同时又要精简到难以察觉，并且资源占用极少。

当我审视我们用 JavaScript 开发应用程序时，最明显的感受是，无论 JavaScript 的潜力有多大，最终还是要迎合设备性能和网络速度的最低标准。这是一个无法回避的真理。我们必须遵守物理定律。

JavaScript 框架的作用

语言或框架帮助开发人员实现他们期望的性能并不罕见。但是，如果我们删除自己的代码呢？最注重性能的 JavaScript 框架执着于让我们运行更少的 JavaScript。

JavaScript 可能比其他任何语言都更关心如何减少 JavaScript 代码量。当像Svelte或Solid 这样的框架比Stimulus甚至Alpine 的体积小得多时，你就会看到这一点。当Marko、Astro和Qwik都专注于 Partial Hydration 时，你也看到了这一点。甚至像React 服务器组件这样的框架也反映了这种担忧。

您的未来会是 0kb JavaScript 吗？

Ryan Carniato 为《这就是学习》撰稿 ・ 2021 年 5 月 3 日

#javascript #webdev #react #svelte

我们大量使用打包器和编译器来去除所有不必要的代码。我们的目标是优化模板中的每一点执行。创建特定的语言来更好地捕捉意图，从而实现这一切。我们分析应用程序，将只能在服务器上运行的代码与在两个地方运行的代码区分开来。我们利用这些信息来降低数据序列化的成本。

我们甚至利用服务器端渲染，通过可恢复性等新概念，来了解如何降低在浏览器中启动应用程序的成本。在服务器上运行应用程序可以填补编译无法提前处理的空白。

俗话说，每周都会有一个新的 JavaScript 框架出现。不断创新，不断突破界限。永不满足于现状的理念萦绕在这个领域。甚至有一个专门的术语来形容它：JavaScript 疲劳。它被埋没在学习和选择的复杂性中。然而，它们却像永不枯竭的亡灵之流般不断涌现。每一种都建立在过去的遗迹之上。

这未必是坏事，而是表明还有更多工作要做。如果你换个角度来看，现状是 10 分中的 4 分，而不是 10 分中的 8 分，那么这一切都不足为奇。JavaScript 疲劳是由现实与预期不符造成的。让我们更深入地讨论一下这些预期。

JavaScript 悖论

我们创造了我们正在解决的问题。我们渴望更多的互动性和更好的用户体验。不再过度依赖网络。我们希望使用一套工具来构建各种类型的 Web 网站或应用程序。

但这远不止于此。我们可以采用一种后端语言，并在其上添加 JavaScript，这在一段时间内或许还不错。从机制上来说，这正是我们一直以来想要的。但要扭转过去十年我们所见证的开发者体验几乎是不可能的。我们能够将所有内容作为单个应用程序进行编写，而不是将 JavaScript 作为一个不断增长但又不受欢迎的孤立代码，编织在服务器应用程序之上。

减少前端和后端之间的界限确实让我们受益良多。甚至有人认为，使用 JavaScript 全栈开发是减少 JavaScript 交付量的最佳方式，这一点也并不会引起太大的争议。

其他语言的运行时可能会节省几十毫秒的时间，但通过在服务器上使用 JavaScript，我们可以为目标设备上的最终用户带来数百毫秒的影响。这对最终用户的影响要大得多。

但不可否认的是，这可能会影响你的底线。JavaScript 存在的唯一目的就是浏览器，而现在我们把它带到了任何地方。

我们陷入困境了吗？

嗯，至少目前是这样。这是 JavaScript 作为浏览器唯一语言的直接扩展。WASM 在某些领域展现出潜力，但在用户界面方面尚未取得进展。它需要克服一些固有的成本。

如果最终用户的设备和网络位于关键路径上，那么针对其进行优化可能是我们能做的最有效的事情。如果对抗 JavaScript 的最佳方法是使用更多 JavaScript，那么我们目前的做法就是如此。

我确信有人会指出像 LiveView 或 HTMX 这样的服务器驱动架构，它们确实包含降低成本的好方法。它们从开发人员那里抽象出一些 JavaScript，以维护以服务器为中心的视图。但是，当你确实需要在客户端进行交互时（无论出于何种原因，例如离线等），如果 JavaScript 是唯一的选择，那么 JavaScript 就是唯一的选择。

话虽如此，JavaScript 工具已经转向 Rust 和 Go（以及 Zig）。人们渴望更高的性能，并希望以更具创意的方式利用这些工具，从而实现完全 JavaScript 的创作体验。

寻找灵丹妙药

别误会我的意思。你完全可以只构建一个 HTML 网站，然后根据需要添加一些 JavaScript。这种动机完全是出于想要扩展单个应用开发规模的心态。并非每个项目都关心这一点。

但有趣的是，我在搜索过程中发现，针对低端设备和网络，解决这个问题的方法不止一种。我认为，对于那些习惯了快速网络（只有地铁之类的间歇性干扰）的人来说，很容易想到如何在不改变方程式的情况下针对某些基本情况进行优化。

看看亚马逊或 eBay 等大型国际电商的运营方式，或者谷歌搜索等服务的处理方式，就能证实这一点。构建小型化、轻量级的服务器，并巧妙地利用服务器来获得最快的初始加载和交互速度。有足够多的研究表明，这会对收入产生怎样的影响。

然而，在中国和其他一些互联网不太统一的地区，他们采用了一种完全不同的模式。小程序有点像渐进式网页应用 (PWA)，可以作为可插拔的子应用加载到现有的移动应用中。这是一种本地化的应用商店。

他们没有针对初始页面加载进行优化，而是针对后台数据加载进行优化，以确保应用无论网络或设备资源如何都能尽可能良好地运行。通常，引入更多 JavaScript 来减少未来的网络请求被认为是极其有益的。我们面临的是一个在受限环境中运行的 Web 应用生态系统，它们对利用服务器资源完全不感兴趣。

如果要说有什么启示的话，那就是事情并不总是那么简单。如果说有办法弥补这一差距，那可能就是如今仍然更多地使用 JavaScript。

结论

这个话题引发了我们很多思考。JavaScript 是否应该继续蚕食后端？有没有更好的方法可以将 JavaScript 与其他语言和平台结合使用？我们是否应该追求 Web 的统一愿景？

或者我们都应该问的问题是，我们怎么会让这种垄断发生？

虽然构建网站和应用程序的方式有很多，但 JavaScript 却拥有巨大的优势。它的优势如此之大，以至于它可能是减少向客户交付 JavaScript 代码的最佳方式。对我来说，这有点疯狂。