Qwik是什么？按官网介绍，Qwik 是一种新型的 Web 框架，可以提供任何大小或复杂程度的即时加载 Web 应用程序。您的网站和应用程序可以使用大约 1kb 的 JS 启动（无论应用程序复杂性如何），并在规模上实现一致的性能。
Qwik还带出了一个新概念，“水合作用（Hydration） ”，水合作用不是什么新鲜内容，其实就是浏览器的加载过程。
如下图，浏览器需要加载css，js（补水）以达到可以向用户展示使用的状态：
Qwik要做的事情就是在最初的时候尽可能最少的加载资源，让页面以最快的速度显示出来，在之后再以最小的资源进行动态加载。通俗的来说就是将懒加载（Lazy Load）进行到极致。
但是要指出的是官方给出的加载图只展示出了其快速首次展示的优点却掩藏了其缺点。它完整的流程应该是下图。需要使用功能的时候它需要再次加载功能代码。
传统的SSR前端框架例如 next nuxt 就像一个肚子大的运动员，一大桶水灌饱了，虽然起步晚了一些但后边有充足的能量一次跑到终点。Quik的感觉就是一个小肚子运动员，一开始喝上一点水就快速开跑了，但是路上要不停的多次停下来补水。
从代码上看，Qwik使用 $ 结尾的组件或功能事件标记懒加载的内容，然后将代码片段编译拆分成大量多个小文件。这些内容在用户需要使用或者触碰到的时候才会实际加载。Qwik使用类似next的约定式路由，同时又借鉴了Vue3 与 Solid 响应式的hook设计。
客观的看待是否使用Qwik，取决于其实际的用途。传统的SSR前端框架，在未来的发展中首次载入慢将越来越不是问题，通过GZIP压缩，CDN加速，互联网5G技术技术的发展，网速只会越来越快。况且一些管理端应用在开始做一个稍长的等待没有太大问题。
那么Qwik最适用的场景是能有哪些呢？
我能想到的是做报名页面或者Landing Page，这类页面往往大多数人是只看内容不用功能（不是所有人都会在上面留下Email或者报名信息）。所以Qwik满足了快速首次加载且只给需要报名的人载入报名功能的需求。正如Qwik的开发者做的 www.builder.io/ 这样一个低代码平台，如果把它看成类似金数据的应用，尽可能的使用分片懒加载再合适不过。
Qwik能否能火起来还有待观察，它有适应的应用场景，但是不可能取代传统的SSR。选择使用Qwik开发对于技术选型存在一些风险，从保守的程度上看如果一个项目要长期维护还是更建议选择传统的Vue，React等框架，除非项目有特定的需求。
