术语服务器端渲染(SSR)经常被误解,许多人用它来描述早于其创建或技术上不合格的实践。从 PHP 模板到 React 的同构应用程序,SSR 的定义不断发展,围绕它的混乱也随之而来。
本文深入探讨了 SSR 的起源、它的真正含义,以及为什么理解其区别在现代 Web 开发中很重要。
在 PHP 时代我们还没有 SSR。这个词不存在。它创建于 2010 年代。在此之前没有人称这个东西为SSR。
他们叫它什么?如果您相信维基百科,它被称为服务器端脚本(与客户端脚本相对)。
有趣的事实:如果你查看维基百科,他们甚至没有在 2021 年之前将“SSR”添加到 服务器端脚本 文章中。以下是差异。老实说?我认为这是错误的。
在 React 引入“渲染”这个术语之前,我们没有使用过这个词。我们拥有的最接近的东西是服务器端模板。这是一张旧快照。
这个想法很简单:您可以使用静态站点生成器或服务器脚本来构建动态网页。
有些人争论道:“好吧,如果我使用服务器模板,我就会在服务器上渲染它们。”
React 中的渲染并不总是意味着生成 HTML 或 DOM。它生成 VDOM (虚拟 DOM)。当您调用 renderToString 时,线条会变得模糊,因为组件实际上会呈现为 HTML。
这就是为什么人们开始声称他们的 PHP 应用程序正在执行 SSR。但问题是:这失去了实际 SSR 和常规动态脚本之间的区别。
您只能对也可以在客户端渲染的部分进行 SSR。
例如:
const App = () => <div onClick={handleClick}>Hello</div>;
您可以运行此应用程序两次:一次在服务器上,一次在客户端上。
但是:
<div><?php echo "Hello"; ?></div>
这不能在客户端运行。这里没有渲染——没有“客户端”或“服务器端”的区别。这只是老式的动态脚本。
由于没有人再使用这些旧术语(也许在 ASP 中除外),我想我要放弃并称之为 服务器渲染 (SR) 与 服务器端渲染 ( SSR)。
一个巨大的区别是保湿。
在 PHP 世界里,没有水合,但他们仍然确信自己有 SSR。这没有道理。只有补充水分才能获得SSR。
React 有两个关键方法:
Angular Universal 直到 2023 年才拥有 SSR。他们拥有的是 SR:在服务器上生成 HTML,然后在脚本加载后将其丢弃,并将应用程序作为 SPA 渲染到空的
中。标签。这和 PHP 不一样,但也和真正的 SSR 不一样。
早期,React 应用程序使用无头 Chrome 进行“预渲染”,将其保存为 HTML 字符串。该快照进入 CDN。从技术上讲,甚至不需要服务器来完成这项工作。 ?
这是一项毫无意义的努力,但谷歌曾经推荐它用于搜索引擎优化。我曾经找到过那篇文章,但我不确定是否可以再次找到它。
React 服务器组件 (RSC) 迫使我们重新审视这个主题。
从技术上来说,RSC 不做 SSR。这让很多人感到惊讶。
React 团队尝试解释它但放弃了。要点是服务器组件只是模板——它们生成静态 HTML。客户端组件通过 SSR 生成 HTML 和 DOM。
Inertia.js 也做了类似的区分。 PHP 在服务器上运行,但您的 JavaScript 应用程序通过在服务器上运行以生成 HTML,然后在客户端上进行水化来获得 SSR。
不。与 RSC 一样,PHP 正在使用执行 SSR 的步骤来执行动态脚本 (SR)。
如果你使用 Hono 这样的中间件运行 React 应用程序,将一些动态代码注入 HTML,然后调用 renderToString,感觉很相似。在这两种情况下,都是带有 SSR 步骤的 SR。
这就是为什么当人们声称“我们在 90 年代用 PHP 进行了 SSR”时,会感到很疯狂。
每次我提起这个问题,都会有人问起SSG。我不在乎。
术语静态站点生成(SSG)实际上早于React。 SSG 意味着生成 HTML — 无需渲染或水合作用。你制作了 HTML 吗?恭喜,您正在执行 SSG。
React 框架引入了同构应用程序,使用水合作用在客户端采用 HTML,而无需重新创建它。
HTML 必须由 SSR 生成。
Qwik 可以补水吗?这是个大问题。
Qwik 开发人员说“不”,但我倾向于“是”。如果您喜欢 Qwik,则需要砍掉另一块 SSR 并将其命名为 Resumability。
如果你更喜欢听讨论而不是阅读,你可以从这个关于 Go 中的 React 服务器组件的播客节目中以音频形式听到更多这些论点
以上是大多数人对 SSR 一词的误解是什么的详细内容。更多信息请关注PHP中文网其他相关文章!