我一直在阅读解释服务器端呈现（SSR）的this one等教程，这些教程会产生诸如“现在，对服务器发出的所有请求都返回完全呈现的HTML”之类的注释。
我的理解是，babel只是将反应JSX解析为vanilla JavaScript，然后可以将其传递给客户端并进行渲染。这个概念反映在教程本身中，它们都导入了某种类型的'bundle.js'文件或其他文件。但是他们继续说话，好像JSX在服务器上一直呈现为HTML，然后发送到客户端。这听起来更像是一个视图引擎的行为，如帕格或ejs ......
这种推理失误阻碍了我的进步，因为我觉得我错过了一些东西。有人能解释一下吗
我的理解是，babel只是将反应jsx解析为vanilla js，然后可以将其传递给客户端并进行渲染。
这是一种可能性，也是最常见的一种可能性。但是，JSX只是一种描述React元素树的语言，它仍然需要呈现为HTML才能在Web应用程序中可见。在某种程度上，JSX代码的转换与服务器端呈现的问题是正交的。工作流程可以由此（简化）管道表示：
----- (1) -------------------- (2) -----------
| JSX | -----> | React element tree | -----> | HTML tree |
----- -------------------- -----------
步骤（1）通常在部署时间内完成，通过在构建过程中集成Babel。但是，步骤（2）最初可以由客户端或服务器执行，具体取决于项目的设置方式。当Web应用程序被编程为调用ReactDOM.render(<MyApp />, root)之类的东西时，客户端以一个简单的HTML文档开始，需要将其扩展为DOM树。
使用SSR，我们在服务器中发生了步骤（2），从而为客户端提供了扩展的DOM树，甚至在执行JavaScript代码之前。这个过程可能类似于模板引擎的过程，但它所做的只是运行React的渲染步骤（例如，参见ReactDOM.renderToString）。视图的其余部分的逻辑和状态由客户端处理。这是通过hydrate方法实现的，该方法将必要的侦听器附加到服务器呈现的组件。
blog post提到SSR的多重好处：
现在，用户不必等待您的JS加载，并在初始请求返回响应时立即获得完全呈现的HTML。
想象一下，用户在慢速3G网络上导航的巨大进步。而不是等待超过20秒的网站加载，你几乎立即在他们的屏幕上获得内容。
[...]
现在，对服务器发出的所有请求都会返回完全呈现的HTML。你的SEO部门的好消息！
Crawlers现在将您的网站视为Web上的任何其他静态网站，并将索引您在服务器上呈现的所有内容。
总结一下，我们从SSR获得的两个主要好处是：
- 初始页面呈现的更快时间
- 完全可索引的HTML页面