Think Qwik

从高层次来看，Qwik 与其他 Web 框架非常相似。Qwik 是一个框架，它渲染组件树，从而生成交互式应用程序。

Qwik 的独特之处不在于它做了什么，而在于它如何实现目标。Qwik 的目标是拥有即时启动的应用程序，即使在移动设备上也是如此。Qwik 通过两种主要策略来实现这一点

1. 尽可能延迟 JavaScript 的执行和下载。
2. 在服务器上序列化应用程序和框架的执行状态，并在客户端恢复它。

Qwik 的目标是只需下载和执行应用程序的绝对必要部分。

延迟执行

尽可能延迟 JavaScript 的执行。

Qwik 应用程序启动速度很快，因为只有很少的 JavaScript 代码需要执行。（最简单的情况下，Qwik 应用程序只需要大约 1KB 的 JavaScript 就可以变得交互式。）

通过积极地延迟应用程序的下载和执行，Qwik 可以提供近乎即时的启动性能。目前还没有任何一代 Web 框架能够与这种实现相媲美。

Qwik 速度快，不是因为它使用了巧妙的算法，而是因为它在设计上，大部分 JavaScript 永远不需要下载或执行。它的速度来自于不做其他框架必须做的事情（比如水合）。

可恢复性和序列化

可恢复性在 这里 有详细讨论。可恢复性允许 Qwik 应用程序在服务器停止的地方继续执行。所有框架都需要跟踪有关应用程序状态的内部数据结构。当前一代框架在从服务器过渡到浏览器时不会保留这些信息。因此，框架的数据结构需要在浏览器中重建，这会重复服务器上完成的工作。数据结构的重建和监听器的附加被称为水合。

Qwik 在服务器-浏览器切换期间将监听器、内部数据结构和应用程序状态序列化到 HTML 中。由于所有信息都序列化在 HTML 中，因此客户端可以从服务器停止的地方继续执行。

问题是什么？

现代网站需要大量的 JavaScript 才能变得交互式。过多的 JavaScript 会导致两个问题

1. 网络带宽：大量的代码被发送到客户端，这在网络速度慢的情况下可能需要很长时间。
2. 启动时间：一旦到达客户端，代码需要被执行（作为水合的一部分）才能使网站变得交互式。

随着 Qwik 应用程序变得越来越复杂，交互性也越来越高，代码量近年来一直在稳步增长，而且没有停止的迹象。简而言之，Qwik 网站正在变得越来越复杂。网站复杂性的增加反过来需要更多代码。所有这些代码都会对网站的启动性能产生负面影响。

更糟糕的是，JavaScript 是单线程的；因此，Qwik 的复杂网站无法利用现代多核 CPU。

我们是怎么走到这一步的？

上述问题的解决方案既明显又困难：发送更少的 JavaScript。

显而易见的是，JavaScript 代码越少的网站性能越好。

困难的是，我们的工具无法帮助我们实现这一点。大多数 Qwik 的工具以一种使发送更少的 JavaScript 变得困难的方式解决问题。这些工具旨在解决特定问题，而没有考虑它们生成的 JavaScript 代码量。

您是否需要解决渲染、样式、动画、A/B 测试、分析等问题？有工具可以解决这些问题。只需导入或添加一个 <script> 标签，这些工具就会解决您的问题，但代价是使初始捆绑包更大。

作为一个行业，捆绑包大小的影响往往被忽视。每个工具都单独解决一个特定问题，但大小并不在考虑范围内。当所有工具组合在一起时，大小就会成为问题，到那时，开发人员几乎无能为力。

解决方案是什么？

Qwik 从一开始就旨在解决大小问题。小捆绑包大小是它的首要目标，所有其他设计决策都服从于这个目标。

Qwik 不是关于创建更少的 JavaScript。Qwik 是关于不必在应用程序启动时一次性将所有 JavaScript 发送到客户端。Qwik 是当你将“延迟加载 JavaScript”的想法发挥到极致时所得到的结果。

是的，Qwik 需要一种不同的思维方式和应用程序设计方式，但结果是近乎为零的初始 JavaScript，以及基于用户交互的渐进式 JavaScript 下载。

大小不应该成为开发人员的问题

如今，包体大小已成为开发者的难题。即使你严格遵循每个框架、工具等的最佳实践，最终也会得到一个庞大的包体。这时，开发者就会开始使用各种延迟加载边界等方法来缓解问题（但正如任何做过这件事的人都会告诉你：这些选择非常有限）。

行业最佳实践会导致大型包体，网络上到处都是这样的例子。

Qwik 的信条是，包体大小不应该成为开发者需要考虑的事情。它应该自然而然地作为框架设计的一部分出现。

Qwik 从一开始就被设计为生成大量的延迟加载边界。工具可以将你的应用程序分解成许多延迟加载的块，运行时只在需要时下载它们。

为什么不修复现有的框架/工具？

简而言之，延迟加载的理念必须在底层实现，不能通过简单地添加到现有的框架/工具中来实现，而不会从根本上改变它们。这种根本性的改变将与框架/工具及其各自的生态系统不兼容，使其变得毫无用处。

当一个框架做出某些假设，例如所有渲染都是同步的，添加异步延迟加载就变得几乎不可能。或者，如果一个框架从模板中恢复监听器位置，那么在网站可以交互之前，必须下载并执行这些模板。这些只是比较明显的例子，实际上，还有无数的原因导致当前的思维模式不符合可恢复性的要求。

以上也意味着，现有的框架无法将可恢复性作为一项功能添加。现有的框架永远无法做到 Qwik 可以做到的事情（除非破坏向后兼容性）。

为什么我们要构建 Qwik？

因为我们相信有一种更好的构建网站的方式。一种不需要在启动时急切地下载大量 JavaScript 才能让你的网站变得交互的方式。一种允许开发者专注于添加功能，而不是如何将庞大的代码库分解成更小的块的方式。一种让网站即时加载，以获得更好的用户体验的方式。所有这些，都以一种独立于应用程序代码库大小的方式实现。

页面速度真的重要吗？

简单地说：缓慢的网站会吓跑访客，让企业损失数百万美元。快速的网站有更好的 SEO、更好的 UX，并且更赚钱。

来自 web.dev 的一些例子