resumable-javascript-with-qwik-2i29

原始地址：https://dev.to/this-is-learning/resumable-javascript-with-qwik-2i29

‘’’
当Misko Hevery（AngularJS的创建者）让你看看他的新框架时，你会停下来听。我已经意识到了Qwik，并且看到了它的潜力，但是这是停下来仔细看一看的好机会。Qwik是一个独特的JavaScript框架，因为它是唯一一个可以在组件级别上进行无序水化的框架。但Qwik不仅仅是这样，它还为JavaScript引入了一个新的概念：可恢复的框架。

可恢复的框架？
如今，我们的JavaScript框架通常是同构的，可以在服务器和浏览器中进行渲染。但是对于大多数框架来说，这种能力后来都是额外添加的，是对客户端范例的自然延伸。但是，如果框架在第一次构建时就基于SSR，会怎么样呢？

在Qwik之前，我们看到的数量相当少。Meteor、Marko等可能还有其他几个。然而，现代同构技术是建立在React、Vue和Svelte等库的基础上的，这些库最初并没有用于服务器渲染。

因此，可以预料它们的核心机制在设计时并没有考虑如何利用这些信息。如果您知道您的应用程序永远都会先在服务器上进行渲染，您可以做出什么样的让步呢？

其中最有力的一点可能是在浏览器中不重复执行在服务器上已经完成的任何工作。一个旨在在浏览器中减少工作量的JavaScript框架。这不是第一个这样做的框架。但或许是第一个意识到理想化水化执行的框架。

水化是将服务器渲染的HTML添加交互性的过程。它涉及添加事件处理程序和初始化应用程序状态。对于大多数JavaScript库来说，这是一个自顶向下的过程，与在浏览器中重新渲染整个应用程序非常相似，即使它实际上并不创建任何新的DOM节点。有关水化的更完整指南，请参见“为什么JavaScript框架中的高效水化如此具有挑战性”。

迈向可恢复性的旅程
创建一种在浏览器中不重复执行工作的水化方法并不容易。您不能只是选择您现有的单页面应用程序框架，然后就到达这里。我们在Marko上已经在解决同样的问题上工作了几年，尽管方法不同，但问题的关键仍然是几个方面。

能够将所需的用于水化的代码（事件、效果）与用于渲染视图和管理有状态更新的代码分开。
了解什么数据是有状态的（可以更新的）以及什么依赖于它。为了恢复工作，必须在比组件更精细的级别上完成工作，因为在水化期间重新运行组件将是不必要的工作。
序列化足够的数据，以便不相关的更改不需要重新计算，以及部分应用程序可以独立而无序地进行水化。
一些框架可能只包含其中的一个，但几乎没有框架同时包含这三个功能。通过遵循组件创作、响应式基元（类似于React Hooks）和编译器使用JSX中的标记来指示如何拆分代码的规则，Qwik实现了这一点。

关于延迟加载呢？
除了可以恢复执行之外，Qwik最引人注目的特性之一就是逐步水化。它按需逐步加载JavaScript。它可以从0kb的捆绑的JavaScript组件代码开始，并根据交互程度进行逐步扩展，无论交互程度如何。

Qwik的做法与众不同。其他解决这个问题的方法是根据服务器和客户端的区别来进行选择。这些解决方案依赖于岛屿、特殊的文件扩展甚至高级编译器分析。从我的角度来看，这是要解决的80%的问题。大多数页面在移除异步数据加载和路由考虑之后基本上是静态的。但是，如果页面非常互动呢？如果大部分页面能且会在浏览器中加载？

在这种情况下，渐进式水化可能是在初始加载期间获得响应页面的唯一方法。这并不仅仅是简单地推迟不可避免的问题。它只会将全部成本推迟到用户首次与页面交互时。Qwik的有趣之处就在于，使其可恢复执行的相同特性也可以使页面的任何部分独立进行水化。

是的。页面中间的按钮可以在加载层次结构中较高的JavaScript加载之前加载必要的代码以添加商品到购物车。这不是典型框架的工作方式。如果您的组件包含其他组件并传递属性，那么所有的东西都需要自顶向下运行。

问题解决了吗？
嗯，也许。但可能不是您所想象的那种方式。理解了上面我解释的内容后，我认为展示Qwik的这些独特功能将是有趣的。想象一下：
写一个典型的单页面应用程序（SPA），其中使用了JSX和反应式数据，就像您已经习惯的那样。但是当页面加载时，几乎没有加载任何JavaScript。当您滚动一下，找到您感兴趣的内容，那个部分的JavaScript加载并运行。满足于此，您单击了一个链接，突然之间客户端路由器加载，客户端导航接管。完美的按需水化的无缝SPA体验。

直到你意识到，当你导航到新页面时，你正在加载整个应用程序的路由信息，并且你突然加载了数十个新的迷你JS文件以在浏览器中渲染整个页面。一开始，你可能会认为这不是一个好办法。但是然后你想，好吧，我们可以在这里使用一些更加智能的捆绑策略。而且Qwik正在考虑采用一些智能捆绑的方法。但这是超越了这一点。

对于一个将所有事物都优化为减少浏览器中的JavaScript的框架来说，为什么您甚至还想要在浏览器中渲染整个下一页呢？

好吧，你不会。这时一切开始真正变得合理起来。根据现有框架的优点来评估Qwik是毫无意义的。Qwik似乎是解决React捆绑大小的万灵药，但实际上它完全是另一回事。

这是一个全新的世界
那么Qwik是什么？它是我在本文中提到过的一切。它是一个根据应用程序组成优化在浏览器中执行最少初始工作的框架。更重要的是，它提出了一个潜在的全新前端应用程序构建范例。不只是从SPA过渡过来，而是完全根据从服务器获取最多的内容来构建。

它仍然相对较新。很多功能都未记录。仍然存在一些需要解决的问题。

它明显受益于经典的多页服务器应用程序路由，以保持其体验，即使在我们转到新页面时也是如此。在转到新位置时，服务器渲染允许Qwik继续默认发送没有JavaScript的内容。我预计我们将在这个领域看到更多的发展，以实现在无需完全页面重新加载的情况下呈现服务器渲染的页面和部分内容。

渐进式水化仍然是一个棘手的问题，因为它确实有成本。关键交互不应懒加载，并且应以逻辑方式一起加载，以防止代码分割过程产生。Qwik具有一个优化器，可以让您控制他们如何捆绑。将来，您将能够使用您的网站分析数据来通知捆绑过程，了解用户如何与页面进行交互。我知道它很激动人心。但这是这种方法的一部分考虑。您可以在他们的在线游乐场上体验优化器。

数据加载和序列化仍然需要考虑。其他一些部分水化解决方案使用它们知道什么是仅在服务器上的事实，仅序列化所需的数据。利用它们需要作为顶级浏览器组件的属性传递的事实，可以极大地减少双重数据问题（将其表示为JSON和渲染的HTML）。Qwik本能上不具备此知识，但它对水化的方法在这里没有任何限制。因此，看看他们采取什么方法将是有趣的。

结论
现在已经有了几个演示项目（Hackernews，JS Framework Benchmark），在Qwik中，我看到了一个非常有前途的框架的雏形。但是在当前环境中评估它仍然有些困难，因为我觉得我们还没有看到全貌。不仅仅是因为Qwik仍在开发中，而是因为更广泛的生态系统和工具还没有真正迎合这一变革。但这只是时间问题。

同时，Qwik提供了处理过多JavaScript问题的最独特方法之一。轻松处理100%的Lighthouse评分。如果您希望尽量减少时间以实现互动性，并且想尝试一些新东西，那么几乎没有比这更好的选择。

对Qwik的工作方式更感兴趣吗？Misko Hevery在这个主题上写了一系列很棒的文章：
‘’’