Marko 用于网站，Solid 用于应用程序

我已经写了两年了。在我读到@swyx的精髓之作《Svelte for Sites, React for Apps》之前，我心里就想写这篇文章了。2020年3月，当我签约加入Marko团队时（我知道，这是工作调动的最佳时机），我心中已经有了一个清晰的认识：我将有机会参与到JavaScript框架未来发展的两个最具代表性的方案中。

有人好奇我为什么要开发第二个框架，但我从未发现这两者之间存在冲突。从很多方面来看，它们截然不同。每个设计决策都经过了不同的权衡，每个决策的“正确”答案也可能有所不同。但这让我如此兴奋，是因为Solid和Marko代表了在关键维度上最强大的方法。这对 JavaScript 框架界来说，堪称一场钳形攻势。

Vue 的创建者尤雨溪在关于框架权衡的演讲中非常精彩，他将 Vue 定位为介于 React 和 Angular 之间的中间地带。最简单的解释是将其解释为一系列独立的范围，但事实上，我们生活在一个多维的世界，一个解决方案并不总是适用于所有决策。但作为开发者，我们不断变换视角，进行这些二维的比较。

所以任务很简单：不要改变世界，要改变视角。与其专注于中间地带，也不要包办一切，不如专注于更容易实现的目标，在存在分歧的地方成为最好的自己。支持多方也没什么错。

那么网站与应用程序？

嗯，这一直是 Web 领域长期以来的二分法。它甚至早于单页应用 (Single Page Apps) 的出现，尽管这也是它在过去十年中如此受关注的原因。我们似乎有两种截然不同的用例试图利用同一种技术。因此，即使目前还不可行，或许有一种方法可以统一这两种用例，这本身就很有道理。而我今天要讨论的框架/库恰好代表了这两种情况。

Marko 网站

Marko诞生于 2010 年代初的 eBay，并于 2014 年开源。它专为电商平台打造，旨在满足全球客户日益增长的需求，因为全球客户在不同的设备和网络环境下，其设备配置和网络性能往往不尽相同。Marko 非常重视页面加载，是首个从一开始就引入无序流处理 (Out of Order Streaming) 和部分数据同步 (Partial Hydration) 的JavaScript 框架。

Marko 也是最早基于编译器的框架之一，因为它起源于服务器端模板语言。从一开始，它就很明显地是一种语言，而不是一个框架；这种思路直到五年后 Svelte 采取了类似的策略才真正流行起来。

Marko 是 HTML 的一个超集，其核心组件是单文件组件，新用户只需将设计人员提供的 HTML 文件扩展名更改为 Marko，.marko或使用从 StackOverflow 复制粘贴的 HTML 文件即可轻松访问 Marko。组件可自动发现，添加 JavaScript 的影响微乎其微。它具备服务器模板语言用户所熟悉的所有特性，但完全同构，可自动在浏览器中实现交互。

它无需思考即可发送最少的 JavaScript。它的“Islands”是自动生成的，其流式传输就像<await>使用 Promise 添加标签一样简单。它的多页面转发方法无需担心持久客户端状态或客户端路由，只需像您期望的网站一样运行即可。它拥有最简洁的语法，让您可以编写所有 JavaScript 框架中最少的代码。它可以轻松获得无与伦比的页面加载性能，而无需放弃其简单性，最终我们只是在网站上创建页面。

适用于应用程序的 Solid

Solid 的出身截然不同。它最初是在 2016 年，当时我在一家创建私人社交媒体的初创公司工作，作为一个业余项目创建的。这是一个长期项目，需要不断改进和调整才能找到客户。虽然我们永远无法重写已有的东西，但我们会快速地拆除和替换部分组件。Solid 从一开始就是模块化的，旨在与 Web 组件配合使用，形成一个与组件无关的解决方案。随着它逐渐发展壮大，它逐渐减轻了负担。

Solid 的强大之处在于，一切都是原生的，甚至包括 JSX。组件只是函数，<div>只是 HTML 元素，状态只是响应式的。它可以向下扩展为 jQuery 的替代品，向上扩展为并发时间片，并且能够使用相同的技术在非 Web 平台上运行。它没有 VDOM 或必需的抽象。它就像一条变色龙，可以在需要的时候变成它需要的样子。

虽然它利用了编译机制，但只有 JSX 会被编译。它本质上是一个“纯 JavaScript”库。一切都建立在简单的原语组合之上，并且每个角落都提供了一个出口，可以完全控制应用程序的运行方式。更令人欣喜的是，这种建模方式也带来了极高的性能，使 Solid 在所有 运行环境 中都成为基准测试的王者。

这种适应性使得库的移植变得非常简单，人们也可以选择从他们喜欢的 DSL 向下编译到 Solid。而且，早在 Hooks 等现代趋势出现之前，Solidity 就已经倡导这种可组合的原始方法。它赋予了“Just JavaScript”新的生命，使其在一个似乎正在深入自定义 DSL 和编译语言的世界中焕发生机，并将他们在最苛刻的应用程序上执行所需的所有控制权交还给开发者。

错误的二分法？

我承认我是用一种虚假的借口把你引到这里来的。实际上，我们看到以 JavaScript 为中心的 Web 技术正在走向崩溃。起初，静态 (SSG) 和动态 (SSR) 体验之间存在明显差异，但这种差异已经消失，很快网站 (MPA) 和应用 (SPA) 之间的差异也将消失。

当我们看到Solid 与 Astro 一起使用时，在极其昂贵的页面中取得了出色的页面加载指标时，历史上只有 Marko 才能做到这一点：

或者 Marko 通过其新的编译反应性带来令人难以置信的客户端渲染性能和可组合性，甚至可以与 Solid 相媲美，你开始意识到我们只是看到了一条最终统一光谱两侧的道路。

这让我充满希望，因为这些框架在理念上截然不同。语言与库、HTML 优先与 JavaScript 优先、可变性与不可变性、隐式与显式状态更新、双向数据绑定与单向数据流。尽管存在这些差异，我们仍然坚持在这里。

甚至说 Marko 比 Svelte 更精简，或者 Solid 比 React 更具响应性，都毫不为过。这些框架处于截然相反的境地，拥有不同的价值观和理念，但它们都拥有无与伦比的性能、最小的包大小，并且可以服务于涵盖整个应用场景的用例。如果这些框架都能做到这一点，那么介于两者之间的任何框架也一定可以做到。

结论

我们很快就能生活在一个网站 vs. 应用，不再因为技术优劣而影响你对工具的选择的世界，这难道不是一件好事吗？JSX vs. 自定义 DSL，或者 HTML 优先 vs. JS 优先的思维模式，也不再会影响你对工具的选择。当然，总会有迎合开发者体验的偏好和解决方案。但你可以选择适合自己的框架，我无法说服你，这其中是否存在“赢家”。无论你内心秉持什么样的理念，总有一条路可以走。

我花了时间让Marko看到这一点，挑战我的偏好和世界观。就像Solid一样，我研究了一种似乎领先时代多年、所有事情都正确无误的方法，并利用这种经验探索最佳版本。现在，我在其他框架中不同程度地看到了这种潜力。这里确实有适合每个人的答案。这令人兴奋。网络真是一个奇妙的地方。

笔记：

得分王指的是在这个残酷的页面上获得 90 多分的灯塔评分。这还不包括空闲时间。对于加载图片，我决定最好显示完整时间，即使它是非阻塞的，否则看起来就像Astro + Solid 立即水合了一样。

Svelte + Astro 也能达到同样的效果。SvelteKit 的表现并不比 SolidStart、Remix、Next、Nuxt 等差。这只是展示了 Partial Hydration 在其他框架中的应用。Marko 和 Qwik 在这方面仍然表现更佳。

JS 框架基准测试结果基于当前尚未发布的 Marko 版本在本地运行。虽然这并非最终版本，但已经足够接近最终版本，因此我很乐意分享这些数据。我见过一些比最终版本更高或更低的版本，但这个版本应该接近最终结果。