React 与 Remix 选择不同的未来
Remix 团队宣布了截然不同的方向：他们将与 React 分道扬镳。use client 引入的思维模式转变，以及服务器组件的实现复杂性，迫使他们做出抉择。最终 Remix 3 选择了简单性。Remix 2 用户为此付出代价——他们将失去升级路径。
布莱恩·坎特里尔的演讲《平台作为价值观的映射》为我打开了一扇未曾察觉的认知之窗。他指出，当平台走向分化时，技术优劣往往并非关键因素。本质上是价值观的错位。对某个社群至关重要的要素，在另一个社群的优先级排序中可能截然不同。
两周前我参加了Remix Jam，上周又观看了React Conf 2025的视频。过去十年我用React交付生产代码，近两年则投身Remix生态。
如今两大生态都在转型，曾经看似不同的技术路线已演变为不可调和的愿景。
React大会的技术公告渐进式推进：React 19.2 API、视图过渡实验、编译器功能增强。其核心信息清晰明确：React 在倾听社区声音的同时，主动承担了复杂性。稳定性、可组合性、能力——这些才是其核心价值。
而 Remix 团队宣布了截然不同的方向：他们将与 React 分道扬镳。use client 引入的思维模式转变，以及服务器组件的实现复杂性，迫使他们做出抉择。最终 Remix 3 选择了简单性。Remix 2 用户为此付出代价——他们将失去升级路径。
这种为简约牺牲稳定性的抉择，昭示了早已存在的真相：这些价值无法并存。
React的价值：复杂性即能力
React的宣言目标是“提升响应式用户体验的标准”。在2025年React大会上，团队展示了这一理念的实践意义——只要能为终端用户创造更佳体验，他们便愿意为开发者承担巨大的复杂性。
React编译器便是最鲜明的例证。它能分析代码、将组件拆解为更小的逻辑单元，并自动优化渲染过程。在Meta的Quest商店应用中，即便该应用已通过人工优化，加载速度仍提升12%，交互响应速度更是提升一倍。编译器并非取代开发者技能，而是处理手动维护难以企及的复杂性。Joe Savona阐释了核心挑战：在基于上下文的应用中，当“每个组件都需更新”时，编译器如今能自动跳过大部分更新工作。
这正是 React 的价值主张：** 稳定性 (编译器兼容现有代码)、 可组合性 **(集成并发渲染、Suspense、过渡效果)以及 ** 性能潜力 **(释放手动优化无法企及的效能)。当团队谈及多年探索增量计算的历程时，他们并非在为复杂性辩解。他们是在阐释提升标准的代价。
React团队深知这会增加复杂性。但其赌注清晰明确：React甘愿承受复杂性的重担，让开发者得以从繁琐中解脱。这种精神值得敬佩，却也要求开发者比以往更信任React的隐形引擎。
Remix的反向价值：以简约为解放
Remix团队仍记得React初为可组合渲染库时仅含少量基础组件的岁月。在Remix Jam大会上，Ryan Florence演示了当“简单性”成为核心组织原则时的形态：显式胜于隐式，可追溯胜于自动。
最鲜明的例证是this.update()。当Ryan在台上构建实时鼓机时，每次状态变更都需手动触发：“这段代码中，所有更新都源于我的主动指令。” 没有自动响应图，没有隐藏订阅，更无需调试意外重渲染的原因。若想知道组件为何更新，答案永远是“因为你在某个地方主动触发了它”。
这种显式性贯穿Remix 3的设计。事件处理通过on属性与原生DOM事件交互，事件通过常规DOM机制冒泡传播。AbortController(this.signal)显式连接清理逻辑。上下文不会触发重渲染。你设置上下文，组件读取上下文，当需要改变时才调用this.update()。
在演示鼓机功能后，Ryan阐述了设计理念：”我们一直追求这样的理念：你构建事物，改变值，一切都会按预期运行。但我的经验是：配置过程困难重重，一旦配置完成，遇到意外情况时又必须拆解重构。”
当迈克尔·杰克逊演示<Frame>组件的服务器端渲染时，他展示了该组件如何采用纯HTML作为传输格式。React服务器端组件能解决实际问题，但Remix认为依托Web平台能以更简洁的方式实现相同目标。
这是 Remix 的价值主张：** 简洁性 (明确控制更新时机)、 Web 平台兼容性 **(标准事件、标准流、跨运行时兼容)以及 ** 可调试性 **(追溯每次更新至特定的 this.update() 调用)。团队并非否定 React 提升用户体验标准的目标，而是拒绝 React 为实现该目标而付出的复杂性代价。
Web 平台：必然选择还是主动抉择？
用坎特里尔的框架分析Remix脱离React的现象颇具讽刺意味：Remix团队根本不认为对Web平台的承诺是价值观选择，他们坚信自己只是顺势而为——所有框架终将拥抱Web平台API，只是时间早晚问题。
但坎特里尔的演讲表明，这实为明确的价值观选择而非必然归宿。他痛惜Node.js选择“易用性”而非“严谨性”，采用Web平台API以便利浏览器开发者使用服务器端JavaScript。而将这些API引入Node的实践者，恰恰是他眼中践踏其核心价值观——健壮性、可调试性、运行正确性——的群体。对坎特里尔而言，迎合Web平台意味着为开发者便利牺牲工程严谨性。
Remix 3却正完全基于这些Web平台API构建自身。流、fetch、文件 API，所有平台依赖项在浏览器、Bun、Deno和Node中表现完全一致。Ryan和Michael在Remix Jam全程演示了这一点：标准HTML响应、原生DOM事件、跨运行时兼容性。React同样尊重Web平台API，但将其视为构建基础；而Remix 3则将其视为终极目标。这始终是Remix的核心价值——从1.0到2.0版本皆可见证，而3.0版本将其升华为绝对准则。
正因如此，我深爱Remix。
作为开放网络的拥趸，我并不认为所有服务器框架都应完全遵循Web平台规范。浏览器与服务器受制于不同约束，必然产生不同权衡。目标并非抹平二者间的界限，而是让界限清晰可辨且具有明确意图。Remix 2 优雅地处理了这种张力，但这源于对平台暴露点的审美选择，而非与平台对齐的必然结果。
Remix 2 已逝，react-router 万岁！
尽管 Remix 凭借未来标志机制拥有业内顶尖的升级策略，但 Remix 2 至 Remix 3 之间不会存在迁移路径。变革过于根本性。在 Remix Jam 大会上，Michael Jackson 明确表示： “我们已为 React Router 耕耘十年… 众多项目基于它构建，Shopify 亦然… 我们绝不会抛弃这个项目。” Remix 2 用户可通过 react-router v7 获得持续维护的演进路径。但Remix 3在分道扬镳后继承了名称，并开启全新方向。
当简洁性成为核心原则，稳定性便不再是不可动摇的准则。新引入的on属性无法与React传统事件系统共存，显式的this.update API彻底取代了React的钩子机制。打破向后兼容性并非附带损害，而是设计初衷。这为诸如重载this(赋予组件可选的第二个参数而不依赖参数顺序)等设计技巧开辟了空间——这种设计之所以简洁，正是因为它充分利用了JavaScript的现有能力。
预计年底前将发布Alpha版，2026年推出完整版本。但警告很明确：Remix 3短期内尚不具备生产环境部署条件。所有内容均为全新设计且可能变更。在此期间，react-router仍是我们的选择。
待解难题
以事件作为通信骨干的设计颇具巧思，但令人联想到依赖共享事件总线进行组件间通信的复杂Backbone.js应用。这种方案曾行之有效，但当复杂度达到一定程度后，新开发者就难以快速上手现有项目。Remix的显式设计和TypeScript支持应该有所帮助。但这能否解决我们在2010年未能攻克的难题？
this.update() 的概念模型比 React 的钩子系统更易于理解。但显式渲染意味着代码更冗长。AbortControllers 需要手动处理清理逻辑。取舍很明确：代码量增加，但理解更深入。这究竟是解放还是复杂性的转移，取决于你的团队和代码库。
Remix 2 与 react-router 的发展历程表明，Ryan 和 Michael 善于转向行之有效的方法。这无疑是他们的优势所在，但大型组织很难在不断变化的平台上进行构建。在 Remix 3 稳定之前，它还会经历多少次变革？
活在分歧中
坎特里尔以警示结束演讲：“选举无法化解价值观分歧。投票次数再多也无济于事——若未能真正改变人们的认知与价值观，任何问题都无法解决。”
react-router分支的存在，正源于Remix团队深知价值观不会一夜改变。这条分支为需要 Remix 2 稳定性的开发者提供了过渡通道，同时 Remix 3 正在证明自身价值。这种分化承认了现实：生产环境中的软件不会仅凭愿景就采用新框架。团队会根据不同价值观做出选择：有人坚持 React 并拥抱编译器的复杂性，有人则会提前跳上 Remix 3 的列车，押注“简约性”值得迁移成本与不确定性。
两条道路皆具合理性，但它们适用于 不同的价值取向。当框架明确重新排序核心价值时，团队必须做出抉择——不是基于功能或性能基准，而是基于他们愿意承受何种复杂性、需要保持何种控制权。这并非技术决策，而是价值观抉择。
React生态系统如今面临两种相互排斥的未来愿景。坎特里尔的框架帮助我们理解：即便过程令人不安，这种分歧也是合理的。先确立你的价值观，再选择你的工具。
本文文字及图片出自 React and Remix Choose Different Futures
你也许感兴趣的：