从React服务器组件（RSC）反思Jakarta Faces技术
- 2024.8.20
- 版权声明：本文为博主chszs的原创文章，未经博主允许不得转载。
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 工作流程
- 哀求：用户向服务器发送网页哀求。
- 服务器处理：
- 服务器接收并处理哀求。
- 执行必要的数据获取和业务逻辑。
- 使用模板引擎或框架（如 React）构建完整的 HTML 页面。
- 将天生的 HTML 响应发送回客户端。
- 水合（Hydration，可选项）：
- 浏览器接收 HTML 并呈现静态内容。
- 通过 HTML 中的 <script> 标签下载必要的 JavaScript。
- JavaScript 在浏览器中执行，为页面添加交互性，这个过程称为"水合"。
2.2 SSR 的上风
- 更快的初始页面加载：用户能更快地看到有意义的内容，提升了感知性能。
- 更好的搜索引擎优化（SEO）：搜索引擎爬虫可以直接解析完整的 HTML 内容。
- 改善性能指标：如初次内容绘制（FCP）和最大内容绘制（LCP）等。
- 加强可访问性：即使在 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的核心特性
- 组件化UI：提供可重用的UI组件。
- 服务器端渲染：在服务器上天生HTML。
- MVC架构：遵照Model-View-Controller设计模式。
- 生命周期管理：详细的哀求处理生命周期。
- 状态管理：内置的服务器端状态管理。
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 技术比当前的所谓前端三大框架更有价值。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
