Svelte 用于网站，React 用于应用程序

翻译：中文版

2020 年，我个人对 Web 开发者的建议是使用Svelte 开发网站，使用 React 开发应用。值得注意的是，这个观点过于微妙，以至于激怒了两者的粉丝。

我在《Shoptalk Show》的采访中提到过这一点，Chris Coyier 鼓励我写一篇博文来探讨。我来解释一下。

网站与应用程序

首先，我必须区分网站（Web）和应用（Web）。有些严肃、聪明的人坚持认为两者并无区别。他们想用同一种技术构建网络上的一切。恕我直言，他们错了。

网站主要用来展示内容，交互有限。首次加载时间至关重要，因为用户可能会跳出，或者他们有限的数据/电量/CPU 可能会让他们错过重要信息（参考Alex Russell 的数学计算，了解合理的基准，但假设你肯定希望关键路径小于 200kb）。这是 Web 最初的用例——展示信息——也是 HTML/CSS/浏览器的强项。

Web 应用主要是为了交互而存在的。CRUD 应用、直播应用、游戏等等。这些应用往往比较重，这很不幸，因为这会影响它们的性能。但是，即使是 2MB 的 JS 应用，在与 200MB 的移动应用竞争时，听起来也不算太糟糕，而且（假设）您正在开发一个 B2B 应用，而每个人都在使用高功耗和高带宽的设备。您通常还会让应用保持更长时间的打开状态，因此首次加载问题并不那么重要（可以使用 Service Worker 来缓解）。一旦考虑到 Web 应用必须附带所有 UI 组件和行为才能正常工作，而典型的原生应用通常严重依赖平台提供的组件，挑战就更大了。Web 平台仍然缺乏许多标准组件/API 和开发人员经验，而这些对于编写优秀的 Web 应用至关重要——因此，框架填补了这一空白。

我将网站与应用视为一个范围。当然，如果你的网站根本不需要任何交互，就不要使用任何 JS。但大多数网站都具有类似应用的功能（登录、回复、评论），而许多应用需要在类似网站的约束下运行。

附言：请查看 Jason Miller 的应用程序全息类型，以获得更多关于如何将 Web 项目的架构与其预期用途相匹配的思考。

你会注意到，大多数企业已经意识到了这一点——www.mysaas.com营销网站app.mysaas.com和应用程序。它们最初可能使用相同的代码库，但由于需求差异巨大，最终会拆分成不同的代码库，并由不同的团队负责。通常，那些理想主义的狂热爱好者会尝试将同一项技术应用于这些截然不同的目的。

React 应用

React 开源至今已有 7 年。它已被全球众多大型公司和网站投入生产，从苹果到 Twitter、亚马逊、Airbnb 到 Uber。它已连续至少 36 个月成为 Hacker News 招聘信息中被提及次数最多的技术。React开发者数量在 300 万至 900 万之间，且每年增长率至少超过 50%。其庞大的第三方生态系统吸引了众多讲师、开发者、公司以及数亿美元的企业和风险投资。

仅凭这一点，React 已经是一个不错的应用技术选择。但这些都是偶然因素，与 React 的优点并无根本关联。这冒犯了那些秉持第一性原理思考的人。所以，让我来列举一些核心原因，说明为什么 React 是应用的绝佳选择：

• React Native 在 2018 年似乎陷入困境，但目前团队的表现似乎不错（就我这样的局外人而言）。Flutter或许有一天会与其一较高下，但它仍需要克服 Dart 和 Google 的障碍。React Native 是当今科技领域最好的跨平台（移动+Web+桌面）“几乎一次编写，几乎随处运行”的解决方案。如果你有资源聘请平台专家，你不会觉得这有什么用处。但是，如果你像绝大多数公司一样，无力为每个平台配备一个专门的专家团队，那么 React Native 是你的最佳选择。
• React 在抽象设计方面拥有迄今为止最丰富的经验。React引领潮流，其他框架紧随其后（Vue 的Composition API和Svelte 3 的 $: API都直接将灵感归功于 React，Swift UI 和 Jetpack Compose 也是如此）。这并不是说他们总是正确的（突击测验：React 中有多少个 Context API？），但当Concurrent Mode和React Flight发布时，我预计它会深受全球最大网站生产环境使用情况的影响。用于数据获取的 Suspense 虽然尚未发布，但在 Facebook 的生产环境中已经使用了一年多。我想强调一下这种情况有多么不寻常——通常在开源项目中，你发布一些东西，然后希望它能被大型公司采用并进行大规模测试。而 React，Facebook在向广大开发者社区发布之前会进行大规模的 dogfood测试，许多 想法在公开认可之前就 被扼杀了，因为发现了缺陷。评判 React 时，应该同样看重它没有提供的功能，就像你看重它提供了什么一样。
• 这让我想到了治理。它并不完美（例如，很多人对 Facebook 有意见），但我认为React 是世界上运行最好的开源项目之一。通常，诸如版本控制策略、错误消息、发布渠道以及逐步升级等日常事务，在React的规模下都至关重要。该团队还与 Gatsby、Apollo 和 Next.js 等关键生态系统合作伙伴进行了大量非正式合作，包括在浏览器层面与 Chrome 的合作以及在语言层面与 TC39 的合作。该团队不仅非常重视技术治理，还致力于打造一个包容多元的社区。

• 我犹豫着是否要提及最后一点，因为从技术上讲，这关乎采用率，但我无法将其与 React 的优点区分开来：它似乎拥有目前在可访问性和交互设计方面最优秀的思想家。没有其他生态系统拥有像 Adob​​e 和 Devon Govett 的React Aria这样的项目，它们已经针对 WAI-ARIA 进行了广泛的思考和测试，所以你无需再为此费心。Segun Adebayo 的 Chakra UI也是如此。或者听听Rick Hanlon 在 Touchable Web 上的演讲，你会意识到，开放网络需要改进多少才能扭转其与移动围墙花园相比令人担忧的颓势。

  • 让我明确一点——React 社区现在真的擅长这些吗？当然不行。他们中的大多数人还在争论应该学习 Hooks 还是 Class 组件。但 React 最有希望，因为它拥有最优秀的抽象，能够让最优秀的思考者创建我们都想要的 Web 应用标准库。

• 选择性水合和渐进式水合是 Fiber 重写带来的特别有趣的结果。再加上 React 的“全栈”未来，开发者可以轻松地在客户端和服务器之间移动代码和执行，我们非常有希望在不损害开发者或用户体验的情况下，打造出运行速度快的应用。

当然，你可以使用 React 来创建网站。Gatsby 和 Next.js（以及即将推出的Remix）是出色的静态和无服务器渲染选项（Gatsby 的“伟大”尚有争议）。Docusaurus非常适合文档网站。如果你正在创建网站并且担心 JS 负载，通常只需几行代码就可以将 Preact 替换为 React，因为如果你只是创建一个网站，通常不会遇到Preact 带来的任何妥协。

那么为什么我主张对网站使用不同的框架呢？

适用于网站的 Svelte

具体来说，Svelte 适用于交互式网站

Svelte 已应用于 《纽约时报》（当然）、Square Enix、苹果、Spotify、Google Arts、阿拉斯加航空等数百家公司的产品制作 ，亚马逊和微软等其他大型开发平台也越来越多地在其内容中采用 Svelte。Svelte 拥有一个活跃的社区，第一批播客、YouTube 频道、学校、会议和新闻通讯正在涌现。Svelte 3 取得了巨大的成功，但仍处于早期阶段。

我要告诉你一个小秘密：Svelte 和 React 并没有太大区别。看一下Svelte 编译输出的内部细节：

function create_fragment(ctx) {
  // redacted
}

export default class App extends SvelteComponent {
  constructor(options) {
    super();
    init(this, options, null, create_fragment, safe_not_equal, {});
  }
}

什么鬼class App extends SvelteComponent？？？看起来像是 React？？

是的。等你意识到它=基本上可以编译成setState，或者它确实附带了一个运行时，或者它确实也有一个调度程序时，你就会明白了。就像我说的，React 领先的地方，其他框架就会跟进。React 证明了组件是正确的选择。

这也意味着大多数 React 开发人员可以在几小时内学会 Svelte，因此切换成本很低。

然而，在其他所有方面，差异都很大：

• JS 重量。您的网站可能会获得 Lighthouse 的绿色评分，但希望您同意，为了用户的利益，您最好只发布自己使用的 JS。Svelte 网站通常只有几千字节。React + React DOM 未压缩后约为 120kb。当然，如果您可以切换到 Preact，可以大幅减少这个数字。但 Svelte 提供了最小的运行时占用空间。我们过去常常担心编译器输出开销会超过 React 组件的大小（运行时越短 = 样板代码越多），但最近的研究彻底打消了这种担忧。

  • 但我对 JS 重量的考量远不止框架本身。据传，那些被 Svelte 吸引的人似乎比 React 的用户更注重性能（看看lukeed做的所有东西）。这源于高层——React 开发者经常会导入大量的依赖项，只要它们符合用例即可；而 Rich Harris 则是一个固执的开发者，他会为所有东西创建自己的版本，因为他只需要用它完成一些较小的工作。而且，Svelte 是大多数人的第二个框架，所以他们更多地以性能为导向来使用它。总的来说，框架文化所鼓励的依赖项选择也会影响 JS 重量的最终结果。
  • 我甚至对 Svelte 中新兴的 JAMstack 文化感到鼓舞，Nick Reese在其中使用Elder.js对Jason Miller 的 Islands Architecture进行了出色的实现。（简而言之 - 典型的Gen-2 SSG 会发送 JS 来补充整个页面，甚至包括那些不会改变的内容，而 Islands Architecture 网站只发送 JS 来补充页面的动态部分，其余部分则保持不变。）

• 作用域样式。还需要我多说吗？Rich Harris 的说法大致如下（措辞不当是我的错）：“在我看来，前端框架应该提供样式解决方案”（说点有意思的：看看 React 核心团队如何讨论样式解决方案吧！他们感同身受）。不仅仅是样式，还有过渡和动画。问问任何一位 React 开发者该使用什么样式/动画解决方案，你会看到他们不知所措，或者给你一篇博士论文般长度的 5 种略有不同的替代方案。我这么说有点讽刺，因为我自己用的是Tailwind 和 Svelte。

• 完整的网站制作工具包。它不仅包含样式和动画。状态管理？头部管理？类切换？补间/弹簧效果？（即将推出）路由？所有这些都只需一次导入即可。由于 Svelte 的设计，您可以根据需要随意使用，但至少所有功能都有第一方选项。

  • React 以其极小的接口面积而自豪，并依靠其生态系统来弥补其不足。选择是 React 受欢迎和长盛不衰的重要因素。
  • 但多年来，我一直生活在一种焦虑之中，不得不时刻了解情况，选择并设置前端技术栈的每一个部分，这真的毫无效率。你看，也许我只是在这方面很差劲。又或许我只是需要一个更高效、更符合我偏好的技术栈。

• Svelte 是 HTML 的超集。Svelte 实际上不仅仅是一个工具包，它还是一门旨在提高 Web 开发者生产力的语言。这意味着 SVG“可以正常工作”。这意味着你可以使用classes。你可以很好地使用 Web 组件（包括导出和导入）。许多使用 React 和 JSX 时会遇到的小问题，你都无法解决。

• Svelte 的缺点在网站建设中并不那么重要。Svelte 的生态系统和社区规模要小得多，但这在网站建设中并不那么重要，因为你主要还是要自己设计和交互。这正是 Rich 在《纽约时报》使用它的方式——不依赖生态系统。规模较小的招聘池也不太令人担忧，因为你通常不会雇佣维护应用程序所需规模的团队。

  顺便说一句，我们正在致力于通过帮助发展 Svelte 社区来构建 Svelte 生态系统 - Svelte Society于一年前在微软的一间小房间里成立-如果您在 2020 年 10 月 18 日阅读本文，请查看Svelte Summit ！

• 如果您仍然需要在 React 中交付功能，您可以根据需要将其挂载到 Svelte 应用之上。相反的做法就没那么合理了（因为您已经为此付出了库占用空间的代价），所以以 Svelte 作为基准是合理的。

除了渲染性能和虚拟 DOM 之外：“虚拟 DOM”的重要性是 React 和 Svelte 之间的一个主要争论点（科技 Twitter 人会记得去年的 3d“基准”），但老实说，你我编写的那种普通网站和应用程序甚至不会遇到那种性能要求，所以我不算它。

我已经写了更多关于为什么我喜欢 Svelte 的想法，但这两个突出的点让我选择 Svelte 而不是 React 作为我自己的交互式网站。

为什么要使用框架？

当然，Web 开发毕竟是 Web 开发，我们还没讨论完这类技术栈选择的全部复杂性。人们的另一个担忧则来自相反的方向——如果你只是在做一个网站（无论是否是交互式的），那为什么要用框架呢？

这个问题问得有道理——毕竟，Hugo、Jekyll、Eleventy等等都提供了完美、快速、久经考验的解决方案。它们默认不生成 JS，然后允许你根据需要“添加一些 JS”。

我目前的答案更多地是关于心智模型。我想使用组件进行编码，并且希望有一个简单的升级路径，以便为之前不具备交互性的内容添加交互性。那些更传统的网站生成器都无法让我做到这一点。我不确定这种论点是否能让“不使用框架”的人们信服，但对我来说确实如此。

哲学大局

我想与你们分享我的一个深刻的认识，乍一听可能有点令人沮丧：

设计用于制造小东西的工具与设计用于制造大东西的工具的工作方式应该非常不同。

嗯，对吧？表面上看，这只是在重复“用合适的工具做合适的工作”这个老掉牙的借口，我对此很不满意。

但这两者之间有微妙的不同。我坚持认为，看似同一项工作，在两个不同的尺度上，实际上是不同的工作。差异大到足以证明使用不同工具的合理性。

此外，当我们忽略这一点并试图让工具完成所有事情时，我们会让这个工具对每个人来说都变得更糟——学习起来更混乱，需要记住更多的 API，而且由于做出太多权衡，最终用户体验往往会下降。

我们急于让所有人满意，但却无法让任何人满意。

补充一下：我们这样做的原因很复杂。有时开发工具公司这样做是因为他们觉得需要它来发展。有时黑客这样做只是为了证明自己有能力。我在这里不做任何评判，尝试突破极限总是值得的。

这是我在 React 与 Svelte 之争中得到的高阶结论。React 团队的公开声明最清楚地展现了这一点（请不要对此进行质疑，这些只是他们在个人社交媒体上的即兴言论）：

• Dan Abramov：“‘消失的框架’当然很酷，值得为之奋斗。但当框架只占代码的5%时，它就没什么用了。‘消失的应用’，我听着呢。”
• Seb Markbage：“这是我内部进行的性能调查得出的结论。我们在所有实际重要的应用中也看到了类似的数字。这是所有 JS 时间的百分比，其中大约 5% 是用于创建实际 DOM 节点的时间，所以这是固有的。框架代码大约占 8%。我们可以优化这 8%，并采取各种其他权衡措施。也许可以节省 7% 的 JS 执行时间……然而，这隐藏了实际应用中 87% 的 JS 执行时间。这才是我们需要关注的。”
• Dan 再次表示：“我认为总体而言，我们确实更注重优化应用程序的大小，而不是库的大小。因为库的大小相对恒定，而应用程序的大小却在不断增长。lazy() 就是一个例子，但我们还有很多工作要做。”

问题是……React 的库大小是 120kb（未压缩）。你希望 React 占应用总 JS 大小的 5-13% 吗？1mb-2.5mb。你的网站/应用接近这个大小吗？

基本事实如下：

• 毫无疑问，React 是开发应用程序和改进应用程序的最佳框架
• React 团队更专注于应用程序而不是网站
• 虽然他们确实关心社区，但 React 的设计首先是为了满足 Facebook 的需求
• 你不是 Facebook
• 您的网站绝对不是 Facebook
• 你可能不会使用 React 提供的所有功能
• 即使你使用 Preact，P/React 生态系统也无法提供足够的开箱即用功能来提高生产力
• 应该存在一个更好的、不同的工具包来制作交互式网站。
• 如今，最适合实现这一目标的语言是 Svelte。

Svelte 适用于网站，React 适用于应用。QED

致 Svelte 的狂热粉丝：是的，你当然也可以用 Svelte 编写应用程序。让大家自己意识到这一点。要证明你能够无可争议地获胜，并且易于采用且成本更低，而不是事无巨细地打仗，即使实际情况会削弱你的理由。