理解过渡 JavaScript 应用

过渡型 JavaScript 应用？什么？说实话，我自己也不太清楚。它涵盖了过去几年 JavaScript 框架的进步，表明情况正在发生变化。单页技术已经存在十多年了，如今的单页应用与十年前，甚至六年前都大不相同。我们已经拥抱了服务器端渲染，并承担了滥用该技术可能带来的副作用的责任。

像往常一样，这不是一个新想法，但有时只需要有人给它起个名字，而@richharris在 JamStack 会议上最近的演讲中给出了最佳诠释：

你们有些人可能已经知道，过去几年里，无论是在Marko还是某种程度上在Solid中，这都是我关注的重点。事实上，这几乎是每个人都在关注的问题：

我已经撰写了无数有关这些主题的技术的文章，但也许​​现在是时候回顾一下并真正体会这对普通 Web 开发人员意味着什么。

单页应用程序已消亡？

嗯，不完全是。每次你提起这个话题，总有某个 Rails 开发者从人群中跳出来，跟我们说 DHH 早在 2005 年就把这一切都搞定了。说实话，那个开发者可能希望我们把时间花在打造时光机上，而不是推动 Web 的发展。但这不是我们来这里的目的。

不。多年来，服务器渲染一直是前端 JavaScript 框架的重要组成部分。发生了什么变化？为什么这些框架突然转型了？从技术角度来看，变化很小。归根结底，单页应用在很多方面都给前端生态系统设定了较低的预期。我们最初构建它们是为了模仿移动应用程序的行为，但实际上并非所有体验都需要那样。但就像任何拥有出色开发者体验的工具一样，人们自然希望在任何地方使用它。

问题在于，这会导致人们引入大量的 JavaScript，并经常替换浏览器中可能已经原生存在的功能。这不仅仅是因为人们没有选择足够精简的库，而是因为架构问题。像 Svelte 或 Solid 这样的新热门库本身并不能改变现状。是的，我是 Solid 的作者，我毫无保留地这么说。它们带来了巨大的改进，并且能够从过去的经验中吸取教训，但它们的血统是与生俱来的。

服务器端渲染本身并没有减少 JavaScript 的臃肿。如果说有什么作用的话，它只会让 JavaScript 体积膨胀，因为需要加载的代码往往比需要渲染的代码更大。我们已经找到了静态生成页面的方法，但一旦需要 JavaScript，就需要整个打包。对于小型网站和像 Svelte、Solid 或 Preact 这样的小型框架来说，我可真不在乎，但我们说的可不是银弹。

我们现在比过去更加重视可访问性和渐进式增强的重要性，让页面无需任何 JavaScript 即可正常运行。但这些是实现方面的考虑，而非架构方面的考虑。这些是成为优秀网络公民的特质，我们的工具应该支持这一点。

迷失在翻译中

我公开批评过“过渡应用”这个术语，主要是因为虽然 SPA 框架正在努力提升性能，但实际上已经有研发投入在解决发送过多 JavaScript 代码的问题。我指的不是复活 Rails，而是为这种用例设计完整的 JavaScript 框架。这样就无需同时处理多个应用，也无需利用最新的工具。

Dan 又说对了。目前在这方面只有几个方案。如果你在更大规模的领域， React 服务器组件或许值得考虑。但是 React 及其相关的基础设施对于我的目的来说太过庞大。我们来谈谈那些可以从几乎 0KB 的 JavaScript 代码开始，并让你的应用消失的框架：

马尔科

Qwik

Astro

iles

长老

斯林奇蒂

它们有一个共同点：它们只向浏览器发送你需要的 JavaScript。虽然它们实现的方式各不相同，但如果你想体验消失应用的魅力，就必须这么做。原因何在？因为无论开发者的经验如何，它们都不会将应用程序视为一个自上而下的单一系统。

这些解决方案还有一些共同点。它们通常被用作所谓的多页应用 (MPA)。没错，你的下一代静态网站生成器（Next、Nuxt、Gatsby、SvelteKit、VuePress、VitePress、SolidStart）可以生成多个页面，但并非如此。你的 SPA 框架仍然将每个页面视为整体的一部分，仍然无法隔离各个部分。在你问之前，那 ____ 怎么办呢？如果框架不在上述列表中，并且它是在 2022 年之前创建的，那么 99% 的可能性是它没有做到这一点。

MPA 难道不好吗？令人惊讶的是，如今情况并非如此。许多技术和浏览器本身都让这些体验相当不错。当然，有些事情只有在你可以通过导航保留浏览器状态时才能实现，但对于很多事情来说，MPA 都非常棒。请参阅@swyx的“ Svelte 用于网站，React 用于应用”。这篇文章实际上更倾向于 Elder 而非 Svelte，并且它适用于上述所有框架。

问题在于，SPA 爱好者和那些被时代所束缚的经典 MPA 支持者之间仍在进行这样的争论，他们忽略了一个事实：世界已经不再是这种争论的焦点了。MPA 不再是过时的东西了。JavaScript MPA 可以说是最前沿的。但它们已经不是你祖父时代的 MPA 了。

事情是这样的。这种区别本质上非常技术性，以至于这些 MPA JavaScript 框架的作者们很难以一种能让充斥着 SPA 的生态系统理解其价值的方式来讲述它。他们最不想与 SPA 扯上关系。我曾因曲解 Rich Harris 的意图以及制造分裂而非包容而受到批评。但是，当众多定义方中的一些人不愿被纳入其中时，这还算包容吗？

这其中并无恶意。我们都在打不同的仗。里奇正在集结军队抵御那些潜在的时间旅行者。我只是在为小人物挺身而出。也许这只是一个技术上的区别，并没有什么意义。但对我们中的一些人来说，它确实意义非凡。

Rich 为整个社区做出了巨大的贡献，提高了人们的认知。他本不需要包含甚至提及这些其他工具，但他还是这么做了，因为他相信事情的发展方向。他的回应只关心如何保留身份，并让这些框架找到自己的声音。

万岁 SPA过渡应用程序

我刚才不是说SPA已死，MPA才是未来吗？不完全是。Dan Abramov说未来是混合型的，这话说得对。说得对，Rich说在理想的未来里，MPA根本不需要。

只是未来尚未到来。除了诸多好处之外，目前还存在一些尚未解决的弊端。这就是为什么我现在不喜欢“过渡性应用”这个词，因为它有点操之过急。等我们真正拥有“过渡性应用”的时候，用这个名字来营销它们会很酷。但“过渡性应用”这个词不是我发明的，所以这也不是我能决定的。

我想花点时间再次谈谈Qwik （这也与Marko的下一版本相关）。这些框架支持自动独立数据同步，无需手动创建孤岛，并且能够先为父级数据同步子级数据。它们能够提供多页应用的所有优势，并无缝扩展到单页体验。

在我看来，这就是过渡型应用。它能够根据需要从极简页面过渡到交互式客户端导航体验。这是一个独特的挑战，需要一系列新的权衡。你不能仅仅依靠现有的框架来实现这一点。或许这值得一个新的术语。到明年，我们再来讨论过渡型应用与变革型应用的优劣。那样的结果会更好吗？

现在，只要这些都不是正确解决方案，本质上就没有任何问题。你有很多选择。这真的应该从你对正在构建的内容的需求出发，而不是构建你最喜欢的工具能够实现的功能。JavaScript 框架什么时候成了高地人？

我可能总体上对框架无关的努力持悲观态度，但我完全赞成庆祝我们的差异。每个框架都是不同的，这是一件好事。