React，你要去哪里？
我写下这些零散的笔记，算是给 React社区（以及更广泛的开源社区）里我深信不疑的人们的一封公开信。这些人包括 Tanner Linsley、Laurie Voss、Cassidy Williams、Michael Jackson、Mark Erikson、Kyle Mathews、Sophie Alpert 等等。
过去几个月，我对 React 一直感到很矛盾。这一切始于服务器组件在框架大会上正式发布，以及 React 文档开始建议使用外部框架进行 React 开发。昨晚读了Cassidy 的文章后，我认同了她的观点，也因此感到有必要表达一下我的担忧。
2016年，Angular发布Angular 2，我们当时很担心它会带来的重大变更，那时我便爱上了React。尽管我从未积极参与过社区活动，但我立刻就爱上了React社区。
我还记得Sophie Alpert和Dan Abramov之间的推文。我还记得2016年Michele Bertoli在ReactJsDay（意大利）上的首次演讲，那演讲让我眼前一亮。我也不会忘记2018年的ReactJsDay，Michael Jackson在我们面前现场重现了React Router的大部分代码——那些日子真是美好！
React 对我们来说一直都是一个成功的选择，无论是作为一家网站开发机构，还是现在的产品公司。每当我想起那天（我记得是 2020 年 1 月 2 日），我依然会激动不已。那天我向 Guillermo Rauch 展示了 React Bricks 的第一个 MVP，他是第一个相信这个项目并给予我继续前进信心的人。
然而，如今我发现有两个问题让我对 React 的喜爱程度有所降低，也让我担心新开发者可能会被它吓倒：所有权和复杂性。
所有权
至于所有权，我不太喜欢这一点：
- React建议使用框架来启动项目，建议使用三个主要的开源框架之一，而不是仅仅使用 React。
- 在框架大会上，React Server 组件等新的 React 功能首次被介绍给社区的大部分成员，就好像这只是框架的一项成就一样。
- 最流行的框架从 React 核心团队挖走了一些成员（这并非坏事，但无疑让他们对开发有了更深入的了解），它采用金丝雀发布的方式，而React 的最后一个版本（18.2）发布于 2022 年 6 月。这样一来，金丝雀功能就进入了许多新 React 项目的代码库，成为事实上的稳定版本，但这仅限于那些可以放心使用金丝雀功能的框架用户。
此外，诸如服务器操作之类的功能（当托管在云平台上时，会触发按流量计费的无服务器函数调用）未来可能会增加前端应用程序的托管成本。虽然目前由于不存在垄断，我们可以自由选择，所以这并非问题，但我希望社区能够得到保证，未来仍然会有多种选择。请理解，我并不认为任何人在这方面是“邪恶的”。私营公司与社区之间的合作可以带来巨大的成果。这仅仅是职责和利益划分的问题。
复杂
我从1996年开始做网站，那时我17岁。那时候，你创建HTML文件，然后上传到FTP服务器，再放到Web服务器上的一个文件夹里。我自己管理着一台物理服务器（一台奔腾120），托管在本地的互联网服务提供商那里。它运行Windows NT4操作系统，使用IIS作为Web服务器，BIND作为DNS服务器，IPSwitch IMail服务器用于收发邮件。一切都简单明了。
如今，Web 开发功能日益强大，但也变得更加复杂。随着转译器、打包器和框架的引入，我们逐渐忽略了底层运行机制。然而，React 凭借其清晰的单向数据流脱颖而出。虽然 Hooks 的出现让事情变得稍微复杂了一些（它背后有一些“黑魔法”），但总体来说还是可以驾驭的，最终也证明 React 是一个不错的选择。
使用服务器组件后，一切都变得更加复杂难懂。而且，由于服务器组件是目前最广泛使用的 React 框架的默认选择，这在某种程度上迫使新手也必须学习这种新的范式。我理解服务器组件的优势，但现在即使在同一个 React 框架内，我们也有两种不同的构建方式。
我们最近完成了React Bricks库与 RSC 兼容的工作。这耗费了我们一个月的时间和数千行代码。然而，最终的开发者 API 不如以前简洁。我不确定为了提升一点点性能而牺牲简洁性是否真的能让我们的客户受益。尽管如此，由于它既是“默认”方案又是最新的功能，我们还是得用上它。
与此同时，React 世界之外也涌现出许多有趣的新框架。我可不想让一个新手程序员现在就去选择他们的第一个框架，因为这真的太难了。React 最流行，Vue 更容易上手，Svelte 的理念很棒，Astro 非常出色，还有 Ryan Carniato 开发的 Signals 和 SolidJS，他真是既聪明又谦逊。Qwik 也非常巧妙，我很喜欢它的设计理念（它是由 React Bricks 的竞争对手开发的……但我非常敬佩他们）。所以……选择一个基础框架就已经够让人头疼的了！
梦境？
在这种复杂的场景下，如果能有一个“默认的、官方的”React框架来满足构建SEO友好型网站的基本需求，例如路由、静态站点生成器（SSG）、服务器端渲染（SSR）、中断服务渲染（ISR）（以及这些字母的所有组合），将会非常有益。我知道Remix团队可能不认同SSG的必要性，但我认为它确实有其合理的应用场景。而且我希望它始终能够自托管在Linux服务器上。
我设想这个默认框架由 React 社区开发，并设立一个指导委员会，成员由 React 生态系统中公认的贡献者组成（通过投票产生？）。我知道开源通常不是这样运作的，但是……我梦想着看到这样一个“魔戒远征队”式的团队来做决策。
这个默认框架不应该试图囊括所有其他框架（例如我使用并喜爱的 Remix 或 Next.js）中那些炫酷的新功能。我认为它应该是一个由社区创建的坚实起点。而且我认为我们现在已经有一些很棒的资源可以利用（比如 Tanner？）。
至于RSC，我认为避免数据水合的概念很棒，但我们需要一种新的服务器-客户端集成方式来使其易于使用。如果它们仍然很复杂，在目前的限制下，为了性能而牺牲简洁性对大多数网站来说并不划算。而且，RSC的性能可能本来就比Qwik之类的工具差，因为它们在客户端重复执行相同的工作，处理序列化JSON的数据块。不过，这需要另行讨论。
未解决的问题
所以，说了这么多，我想向大家提出几个问题：
- 你对 React 的未来有何看法？
- 您认为在没有赞助公司的情况下，通过选举产生指导委员会，建立一个社区驱动的框架是否可行？为了保持其独立性，这个独立的指导委员会如何才能获得社区或企业用户的财政支持？
Matteo Frana
2023年1月16日