构建者.io的首席技术官Misko Hevery解释了快速的Qwik JS
在这篇文章中，Builder.io的首席技术官讨论了Qwik如何解决JavaScript的反应性问题，以及Builder的可视化网站设计者为内容创建者和开发者提供了什么。
Misko Hevery是在线可视化网站设计器Builder的首席技术官。他也是下一代JavaScript框架Qwik的创造者。在他的Builder和Qwik时代之前，Hevery创建了Angular（旗舰的JavaScript框架之一）和Karma（流行的JavaScript测试运行器）。
显然，Hevery在JavaScript世界里有很长的参与历史。我有机会和他聊了聊Qwik、Builder、反应性挑战、加速Web应用、帮助内容创建者和工程师共存等等。
马修-泰森：我很高兴能与你交谈。我发现了Qwik，这让我看到了Builder和你的简历。你有一个非常有趣的历史，包括Karma和Angular的创建，所以我很想听听你对一些最新的JavaScript趋势的看法。
让我们从反应性开始。反应性是前端代码中最重要的发展之一，但它并不是一个完美的世界。
Misko Hevery：它很复杂。反应性有很多伟大的特性，但也有很多问题。反应性的基本问题是，它需要大量的计算资源来建立，然后再拆掉。这对性能和内存利用率产生了负面影响。所有这些的含义是，一个框架必须在反应性工作之前下载所有的应用程序。
Qwik需要反应性，因为我们想偷懒，但同时我们也需要一种反应性的方法，允许框架在不加载应用程序的情况下对其进行推理。Qwik通过在DOM中存储反应性的订阅信息来做到这一点。
我很想知道更多关于你是如何发现Qwik的，以便更多的人也能这样做。
泰森：我是通过观看Rich Harris最近在Jamstack Conf的演讲才知道Qwik的。他描述了几个项目是如何试图解决反应式框架的缺点的。
Hevery：谢谢你，Rich!
泰森：Qwik是从第一原则出发对反应性的重新思考。你是如何通过内置的懒惰加载边界来实现应用构建的，这真的很有趣。你是如何被激励去做这件事的，并达成这种方法的？
Hevery：这个想法实际上来自于我几年前在ng-conf的演讲。在那里我基本上描述了今天的Qwik。我一直看到其他的框架基本上都是在重复同样的老问题，而且没有一个框架似乎解决了房间里的大问题。他们似乎都把懒惰加载当作事后的考虑，而我想改变这种情况。
我设定了一个目标，即拥有一个完全可懒惰加载的系统，并向后努力，看看我可以建立什么样的框架来满足这些限制。大多数框架关心框架的大小，但不关心应用程序的大小。应用程序的大小不是 "他们的问题"。我想要一个专门解决应用规模问题的框架。任何现实世界的应用都比框架大好几个数量级，所以这才是我们应该关注的问题。
泰森：有趣的是!
所以你是Builder的CTO，也是Qwik的创造者。Builder是一个令人印象深刻的WYSIWYG编辑器。它是否在后台使用Qwik？
Hevery：我们即将发布我们的新主页，它将展示Qwik所能提供的所有最新功能。它将只加载折叠上方的HTML，懒于加载互动性，并在网络工作者中运行所有的第三方脚本。我们的目标是在Google PageSpeed上达到100/100，并表明电子商务网站可以很快速。
我们的主页是建立在Qwik之上的，一旦我们发布，我们将能够向我们的客户提供同样的能力。因此，我们将提供Qwik，既是一个开源项目，也是一种服务，用于制作极快的电子商务网站。
泰森：Builder允许你从视觉设计器中选择各种框架进行输出（React、Vue等）。我想Qwik在未来会成为另一个输出选项？
Hevery：是的，我们已经让Qwik与Builder一起工作，很快它就会提供给我们所有的客户。
泰森：拥有多个输出目标是否像它听起来那样是一个艰难的技术挑战？
Hevery：这一点由Mitosis解决了。Mitosis是一个项目，它允许你一次性编写一个组件，然后将其导出到所有常见的网络框架。这给了你 "写一次就能在任何地方运行 "的能力。
泰森：Qwik允许你在资源、状态和事件处理程序处建立一个有边界的应用程序。这意味着应用程序可以实现对加载内容的细粒度控制。这样的描述公平吗？
Hevery：是的!Qwik需要解决其他框架根本忽视的几个技术难题。
首先，你如何将大的应用程序分解成许多小的可懒惰加载的块状？这比听起来要难，因为在编写应用程序的时候，你不知道最佳的懒人加载边界在哪里。只有在运行应用程序并观察真实世界的使用情况后，你才能确定哪些功能被使用得最多。
第二，框架不能要求下载和执行页面上所有的可见组件。这也是所有现有框架的要求。如果你看到一个组件，那么你必须下载并执行它的所有代码，然后才能使它交互。
第三，框架必须将所有的事件监听器序列化为HTML。没有这一点，应用程序的所有模板都需要急切地下载。
第四，框架必须序列化组件之间的数据关系（反应性）。没有这一点，任何状态的变化都需要下载和执行整个应用程序。
泰森：这真是一个有帮助的分类。它捕捉到了现在JavaScript世界中的大部分行动正在发生。
你能描述一下你所说的Qwik "可恢复 "是什么意思吗？
Hevery：也许这个演示可以更好地解释它？但基本的想法是，应用程序的状态被序列化为HTML，因此框架可以在服务器停止的地方继续执行。这样做的最大好处是，客户端不需要重做服务器刚刚做的所有工作。这使得客户端可以即时启动，大大增加了应用程序的用户体验。因为Qwik只在组件需要突变的时候才加载代码，所以网站的静态部分永远不会被下载代码。
泰森：Qwik处于早期版本（尽管它能够展示所有的核心思想）。你最注重推进哪些方面，以达到1.0的落地？
Hevery：我们有意让第一个版本保持最小化。关键的功能是优化器，它使Qwik能够将你的应用程序分解成许多细粒度的懒惰加载块。你可以想象，优化器的设计是相当棘手的，但它是实现Qwik所有魔法的东西。因此，在1.0版本中，我们只想有一种方法来构建一个端到端的应用程序，并展示前所未有的细粒度懒惰加载。
泰森：Qwik对应用构建的看法与构建者/捆绑者之间的关系是什么？
Hevery：我们希望能够为客户创建尽可能快的网站，而Qwik是实现这一目标的途径。因为我们的大多数客户都在电子商务领域，速度是直接影响转换率的东西，从而影响收入。
泰森。你还有什么想说的吗？
赫维利：Qwik战略的一个关键部分是Partytown。Qwik可以让你的应用程序变得很快，但事实证明，第三方脚本可以完全破坏Qwik努力创造的所有性能。
因此，Qwik不仅需要让你的应用快速启动，而且还需要将所有第三方脚本卸载到网络工作者，以保持快速性能。Partytown就是这样做的。通过在Web Worker中创建一个可以执行脚本的环境，把主线程留给用户，它可以让你吃到蛋糕，也可以吃到它。
泰森：哇，有意思，我不知道Partytown。一个在工作线程中运行昂贵脚本的框架......。听起来它可以对各种应用程序产生巨大的影响。这让我想起了Astro中的能力，一旦线程闲置，就可以给组件注入水。
你们在Builder中使用Partytown吗？
Hevery：是的，Partytown是该战略的一个关键部分。如果没有Partytown，就不可能为我们的网站展示100/100的Google PageSpeed。
泰森：Builder对营销人员很有用，可以让他们在没有技术知识的情况下建立网站，但你们也为开发者提供了很多支持。你能谈谈是什么让Builder对编码人员具有吸引力吗？
Hevery：实际上，Builder对内容创作者和软件工程师都很有用。内容创作者想不断地调整东西，而工程人员只想建立新的功能。这两个群体有不同的发布时间表。市场部希望东西在黑色星期五的午夜上线，而工程部只想发布东西（不是在星期五，这样任何意外就不会破坏他们的周末）。因此，这个工具确实可以让这两组人以更互补的方式共存。
泰森：哈!这些是关于软件开发的一些有趣而真实的观察。
除了像Builder这样改进的工具，你是如何从CTO的位置上努力平衡业务方面和工程方面的需求的？
赫维利：哈哈，我不确定我是否能平衡！但是，是的，我试着把我的一周的工作分开。但是，是的，我试图把我的一周分成三天专注于业务，两天专注于编码。你需要有明确的分工，否则你就会被吸进一个黑洞，永远出不来了。
泰森：是否有办法从Builder中导出并手工修改代码，然后将其导入Builder并再次用设计器编辑？
Hevery：是的，我们有导入器和导出器。HTML只是我们支持的众多格式中的一种。例如，人们可以在Figma中创建一个设计，然后将其导入Builder中。同样，我们也可以把一个 HTML 网站推送到 Figma，让创意人员进行改进，所以有相当多的导入/导出选择可用。
泰森：很有道理！我注意到有几个数据整合选项。
我注意到在 Builder 中有几个数据集成选项，用于消费数据存储和 API。你能告诉人们关于它们的一些情况吗？
Hevery：人们认为Builder是一个拖放式的用户界面编辑器。但实际上，它的功能远不止这些。使用Builder的关键时刻是当开发者和内容创建者意识到他们可以将自己的组件拖入页面。
这些组件有输入/道具，因此Builder也能理解数据绑定。数据从哪里来？好吧，那里列出的集成向你展示了所有你可以从那里获得数据的地方。例如，你的目录来自Shopify，但你把它输入你的自定义组件。
泰森：你是否认为Builder正朝着成为一个完整的网络IDE的方向发展？我注意到你已经引入了内联代码编辑作为测试功能。
Hevery：我认为这并不准确。集成开发环境需要很多东西，而Builder没有，也不需要，所以我不认为这是一个正确的描述。
我想说的是，Builder只做了创意人员所需要的工作，以适合工程开发生命周期的方式进行。为此，你不需要一个完整的IDE。
泰森：我期待着看到你和Builder团队对编辑器的改进。作为一个程序员，我已经迫不及待地想使用Qwik 1.0了。
再次感谢你的时间，Misko。
