1 引言

React 服务器组件（React Server Components，RSC）标志着 React 应用程序开发在其诞生十余年后的一次重大范式转变。RSC 概念于 2020 年底首次提出，其第一个稳定版本预计将作为 React 19 的一部分于 2024 年正式发布。

传统上，React 应用程序主要在客户端运行。这意味着浏览器需要下载包含运行整个应用所需全部代码的 JavaScript 包，然后在客户端渲染应用。尽管这种方法具有一定优势，但也导致了初始加载速度慢、需要在客户端获取和处理数据等问题，对整体性能和用户体验有一定的影响。

React 服务器组件的引入从根本上改变了这一状况。通过允许组件在服务器上运行并渲染，RSC 无需将全部代码发送到客户端即可工作。这一创新不仅改变了 React 的核心运作方式，还为开发者提供了构建更高效、更具性能的应用程序的新途径。

RSC 的出现为 React 生态系统带来了显著的优化潜力，特别是在初始加载速度、服务器端数据获取效率以及整体应用性能方面。这一技术的应用将使得 React 开发者能够更好地平衡服务器端和客户端的职责，从而创造出响应更快、体验更佳的 Web 应用。

2 服务器端渲染（Server Side Rendering，SSR）

要深入理解 React 服务器组件（RSC），我们首先需要掌握服务器端渲染（SSR）的工作原理。如果您已经熟悉 SSR，可以直接跳至下一节。SSR 是一种在服务器上而非浏览器中渲染网页的 Web 开发技术。

2.1 SSR 工作流程

1. 请求：用户向服务器发送网页请求。
2. 服务器处理：服务器接收并处理请求。执行必要的数据获取和业务逻辑。使用模板引擎或框架（如 React）构建完整的 HTML 页面。将生成的 HTML 响应发送回客户端。
3. 水合（Hydration，可选项）：浏览器接收 HTML 并呈现静态内容。通过 HTML 中的 <script> 标签下载必要的 JavaScript。JavaScript 在浏览器中执行，为页面添加交互性，这个过程称为"水合"。

2.2 SSR 的优势

1. 更快的初始页面加载：用户能更快地看到有意义的内容，提升了感知性能。
2. 更好的搜索引擎优化（SEO）：搜索引擎爬虫可以直接解析完整的 HTML 内容。
3. 改善性能指标：如首次内容绘制（FCP）和最大内容绘制（LCP）等。
4. 增强可访问性：即使在 JavaScript 禁用的情况下，也能呈现基本内容。

2.3 SSR vs React 服务器组件

虽然 React 服务器组件（RSC）和 SSR 都涉及服务器端处理，但它们在概念和实现上有显著差异：

• 粒度：SSR 通常渲染整个页面，而 RSC 允许在组件级别决定渲染位置。
• 灵活性：RSC 提供了更细粒度的控制，可以混合使用服务器端和客户端组件。
• 数据获取：RSC 允许在服务器上进行更高效的数据获取，而无需将所有数据传输到客户端。
• bundle size：RSC 可以帮助减少客户端 JavaScript bundle 的大小，因为某些组件完全在服务器上运行。

总的来说，RSC 为开发者提供了 SSR 的优势，同时增加了更多的灵活性和性能优化的可能性。

3 从RSC反思JavaServer Faces的吃灰现状

JavaServer Faces（JSF），现在作为 Jakarta EE 的一部分被称为 Jakarta Faces，是一个用于构建服务器端用户界面的 Java Web 应用程序框架。JSF 1.0 规范最早于2004年发布，2005年发布了 JSF 1.2版，随着 2009 年发布 JSF 2.0 规范后得到了广泛的使用。

JSF的核心特性

1. 组件化UI：提供可重用的UI组件。
2. 服务器端渲染：在服务器上生成HTML。
3. MVC架构：遵循Model-View-Controller设计模式。
4. 生命周期管理：详细的请求处理生命周期。
5. 状态管理：内置的服务器端状态管理。

JSF在当时的局限性

标准化的Java EE/Jakarta EE技术，可完美集成到Java EE/Jakarta EE生态；强大的组件库和第三方扩展组件库（如PrimeFaces、IceFaces、MyFaces等）；适合企业级应用开发。JSF在当时凭借上述的几个优势，迅速在全球得到了广泛应用。

但在当时，像JSF这类SSR技术还有个致命的缺陷，这个缺陷不是来自于技术本身，而是来自于浏览器。当时微软的IE浏览器，Firefox、Opera、以及后来者Chrome都在发展自家的浏览器技术，即使有W3C这样的国际组织在统一Web标准，但同样的HTML、CSS、JavaScript在各家的浏览器上总是很难达到一致的效果。

在这期间，John Resig 在 BarCamp NYC 上发布了 jQuery 框架（2006年），其核心理念是“Write Less, Do More（写更少的代码，做更多的事）”。通过 jQuery，逐步实现浏览器兼容性的统一。但是 jQuery 技术本质上是客户端渲染的，而不是 SSR 技术。所以 jQuery 技术的发展并未促进 JSF 技术的发展，反而促进了它的落幕。

在这期间，浏览器自身的发展也是风起云涌。Chrome凭借高速迭代发布版本，不断改善性能和易用性等特点，逐渐开始壮大。微软的IE在这场竞争中越来越显得力不从心，IE内核的性能提升有限，与Google的V8引擎性能差距越来越大，最后不得已只能放弃IE，“打不过就加入”，改用Blink内核。

注：V8引擎是JavaScript引擎，而WebKit是开源的浏览器引擎，含V8引擎。Google在WebKit上开了一个分支Blink，Chrome浏览器使用了Blink内核，Edge浏览器也直接使用了Blink内核。

回到现在，目前浏览器渲染已经得到了统一，显示不一致的情况已经极少出现了，而且当前的网络通信速度相比于十来年前，提升无疑是巨大的。这正是 SSR 技术重回巅峰的好时机，天时地利都有了，SSR 技术该大放异彩了，是该重新认识 Jakarta Faces 技术了。

至于一些人说 Jakarta Faces（JSF）的缺点：学习曲线较陡；相比现代前端框架，客户端交互性较弱；在单页应用（SPA）场景下不如其他技术灵活。其实这些都不是事，学习曲线较陡，相比于React、Vue、Angular等框架，Jakarta Faces 技术显得更加简单；客户端交互性较弱这点不准确，取决于页面的复杂性；SPA场景下不如其他技术灵活这点说得也不准确，Jakarta Faces 技术开发单页应用也是很适合的。

是时候重新发展 Jakarta Faces 技术了。

回顾这近20年Web技术的发展，我认为在企业级应用领域，Jakarta Faces 技术比当前的所谓前端三大框架更有价值。