为什么要叫“前后端分离”、“服务端渲染”

因为 中文不是编程的基础语言

主要还是类似 react 这样，把 vdom 变成 dom 的过程叫做 render 吧（所以没有 dom ，直接到一个 stream 里，也可以算 render ）

render 翻译成渲染其实是一些翻译上的问题，本身和“图形渲染”并没有那么强的关联，字典里查的话，更偏向于“把某样东西转换成另一个东西或者状态”的义项，和图形渲染稍微有些联系的另一个义项则是给予 /提供 /表达 /表演这个含义
所以 render 放在这里我认为没啥问题，当然翻译上确实可以用更好的词汇）
https://react.dev/reference/react-dom/server

SSR 不就是 Server Side Rendering 么

再往上追溯， 服务端的大量模板库生成 response 内容一般都定义成 render 方法

因为人类语言不是设计出来的，而是生长出来的。

你认为一种表达方法更好，你可以自己使用，也可以倡议大家去用，但最终多数人如何表达，你很难控制。就连国家语言规范都要根据多数人的错误表达方式去修改规范，让规范符合多数人的习惯。

也就是说，人类语言并非绝对理性的，也不是精雕细琢优化出来的，而是很混乱的，充满不合理性的。

实际上叫什么都可以， 没有一个强制要遵守的规范。

和食品安全、建筑安全、医疗安全 之类实打实的有刚性要求的不一样， 软件这些东西，能跑起来就行。

因为最早就是 服务端生成 HTML ，浏览器每个请求都是找后端重新刷一个完整的 html 。
后来 ajax 兴起后，浏览器除第一次下载页面外，后面可以直接找服务端要数据，生成一部分新页面，而不用取完整的 html 。这就出现了“前后端分离”，前端主要管理界面，后端管理数据。
后来浏览器第一次下载的程序太大，然后前端还得自己生成界面，速度不如直接让服务器生成快，所以又让服务器端预先渲染一下，降低浏览器压力，但之后的交互还是浏览器自己更新页面，后端主要传数据，跟最开始的“服务器生成完整 html”还是有本质的不同的。

别咬字眼你的生活会愉快许多。

更合适的说法应该是展示层和业务逻辑层的分离.
以前有很多 UI 展示技术, JSP 、JSF 、Struts 、Freemarker 、velocity 之类的服务端模板框架.
实现起 ui 实在是太笨重了.
后台干脆就服务端应用只吐 json, UI 层渲染交给纯前端开发团队处理.
至于服务端渲染, 也只是为了解决前几年 SPA 应用 seo 的问题.

别咬字眼你的生活会愉快许多。+1

@achira
@taotaodaddy

不用从一个贴文臆测别人生活与不愉快吧。

没写完就发出来了...很同意 4#回答,很精炼但是很单位: 语言是生长出来的.
嗦两句:
从现状看,同一个词是存在多种用途不同含义的.渲染不是只有计算机图形学这么一个定义,在 web 领域,渲染这个词也是存在的,和计算机图形学的渲染,不是一个意思;在中文这里延伸一下: 渲染气氛,它也用"渲染".
从生长看,很多时候,用“服务端生成 HTML”这种冗长的定义,不符合人类的习惯,人们会借用一个已经存在的很短并周知的单词来指代它,这种情况太多太多了,且不限于计算机领域.
UP 的问题其实是属于语言进化和传播领域的问题.

@x77 抱歉...

@taotaodaddy 没事

计算机学的这些还好，大部分是翻译问题， 我们无法要求所有从事翻译工作的人都能做到 信达雅。
大部分人都能接受的翻译也就继续沿用下来了。

不要咬文嚼字。。

这翻译没啥问题，别忘了还有鲁棒性这种从字面上完全看不懂的翻译。。

这两个是不同的 你可以前后端分离 但前端是前端服务端渲染 没人说前端分离后不可以用服务端渲染 只是渲染的东西就不会是数据

数据相关的服务端渲染就会降低 还是有好处

“分离”指的是开发分离。
这有特殊的历史背景，既 jsp 、asp 的大量使用。

“渲染”其实指的是排版。既 html 上的内容由服务器端填写，并不依赖客户端的 js 脚本逻辑填充。这里面也有个历史原因。“渲染”这个词在 vue 、react 时代，被培训班大量滥用导致混淆。培训班把填充 html 普遍叫成“渲染”

所以综上所述，名词的定义，一定是随着时间逐渐腐败、泛化的。区别就是你接受与不接受。

随机存储器：\_(ツ)_/

这也怪培训班？还特么的从 vue 、react 时代？

英语原文里早在不知多少年前就用 render 表示根据 HTML 模板和实际数据来生成最终页面的过程了。

我以前也和别人辩论过这个问题，服务器端渲染，本质上就是拼接字符串，没有浏览器图形渲染的过程。如果是 react 和 vue 这些服务器端渲染，本质上也是拼接字符串，没有传统意义上的渲染过程，但是现在大家都这么叫。描述确实容易造成歧义。

我认为还是翻译的问题，例如 Oriented-Object 翻译为面向对象，如果翻译为以对象为导向就容易理解的多。还有 attribute 和 property ，英文翻译把这两个词都翻译为属性，导致 attribute 和 property 在中文语境没有更精确的区分。

可以预见以后会出现越来越多的拿着 GPT 解释的内容来跟人辩论的帖子
从前：“可是百度上说...”
现在本质好像也没变。

@adoal
英文不同语境下的相同词汇，不等于中文就一定是相同翻译结果。反过来也一样。

分里指开发分离。

渲染的话，有很多步骤，服务端输出 HTML ，等于做了比较初步的渲染。

因为 render 这个词在英文里除了「渲染」还有「交付」以及「使……成为……」的意思，甚至可以说「渲染」本来就是一个引申义。而汉语的「渲染」本来也是毫无关系的一个词，指的是传统绘画的一种绘画技巧，只是恰好成为了 render 一词的翻译（我记得台湾用的就是另一个词）。

如果你接触计算机的领域广一些，就能在各种英文资料里看到 render 一词，它们并不仅仅狭隘地指「生成具体的图像」这个过程（虽然这个意思用得最多），只要是生成内容的技术，都可以称作广义上的 render.

回应主题好了 渲染可以看维基百科
渲染（英语：render ，或称为绘制或彩现）在电脑绘图中，是指以软件由模型生成图像的过程。
所以应该叫生出模型 而本来功能面就分前后端 以整个产品来看才觉得是一体 这也可以查 wiki
但不觉得这些字眼影响理解

前后端分离对应的就是服务端渲染。
在很久以前，是 asp 、php 、jsp 在服务器端生成 html 文件输出给用户的浏览器的，这就叫服务端渲染。不必纠结于“渲染”这个词的意义，咬文嚼字没意义，况且一时半会儿似乎也想不到一个更好的词。这个时候数据和页面结构都是后端在弄，把数据通过模版引擎嵌入到模版里面完事儿。也不存在什么前端工程师，只有切图仔。

后来工程越来越大，复杂性越来越高，才产生了细分。后端只输出数据，到浏览器了再组装成完整 html ，再有什么虚拟 dom 之类的玩意儿。这时候就是所谓的前后端分离。

再发展，前端工程师借助 v8 引擎搞出个 node ，发现性能不错，前端工程师也能干一些后端的活儿了，就又有了“全栈”工程师。

历史总是转来转去。究竟是分离，还是一把梭，还是得看具体工程的复杂度。

看了半天没看懂，所以服务端渲染，是不是在服务器执行的，相当于 jsp

@HerbertNguyen 这才是真实答案。

因为以前没有前后端一说， 开发都是每个人 从设计（也不存在设计，都是 table 布局），html css js ,到写 asp php java ，都是一个人干，现在分开了 所以叫前后分离。

在以前 div+css 都是高大上技术，新东西。 因为老网站都是 table 去掉框线做的。

翻译问题吧，render 这个单词，本身就有提供的意思，服务器提供，但是这样翻译不够信达雅。很多场景中文都不会直译，比如 js 的 promise ，翻译过来就是承诺，但不够好听，太直白了啊，于是就有了“期约”这一名词。

对于 HTML 来说，填充 DOM/CSS 就叫渲染

@sentinelK 不要泛泛而谈空对空。就 web 开发里的从模板+数据生成页面这件事来说，中文里说的渲染就是直接来自英语里的 render ，而且是老早就有的事，不是 react 和 vue 时代的培训班生造出来的。有一定年岁而且习惯看英文材料的老 web 开发者应该都有印象。

@sentinelK 另外从 OP 的表述来看，他的疑问显然不是翻译问题。如果是翻译问题，那应该是在这个语境里 render 使用合理但翻译成渲染不合理，而他显然是在确认这个语境里英文的 render 和中文的渲染对应的情况下，质疑英文 render/中文渲染这个名字是否能准确表达语义。

@adoal 如果是讨论用 render 是否合理的话，我同意你的观点，因为 render 本来就是多个意思，其中有“使之变得 /变成”，所以 render 在信息技术领域不光对应“图像信号的转换”，也对应“HTML 富文本的填充”。

至于说中文语境下的“渲染”，我还是保留我自己的意见。我认为这用在 HTML 上，并不是一个合理的翻译。

@sentinelK 有道理

对词语咬文嚼字有助于重新正确认识其对应的概念。

所有解决方案都不是一刀切，有得时候前后端分离很好，然后前端打包成类桌面应用，可以降低浏览器特性变化带来的风险；也有的时候，完全没有必要，还增加维护成本。

写过 jsp 和 php 并且尝试过用 jquery+ajax 获取页面内容替换就不会有这个问题了 XD

前后端分离的意思是前后端代码不在一个项目和服务里部署，相对的是早年主流的 PHP 、JSP 、ASP 等技术栈前后端代码是混合在一起的，并且被一起解析运行。简单来说，通常前后端分离的项目就是前端用 React 、Vue 等框架写的纯前端应用，再用 Go 、Node.js 、Java Springboot 等写的纯服务端应用，然后两者使用 HTTP API （ REST 、GraphQL 等设计风格）进行通信。

服务端渲染指的是在服务器渲染成最终页面，相对的是前端（客户端）渲染。比如使用 React 、Vue 等框架开发的前端应用，页面是在浏览器端根据用户访问的前端路径（如 hash 路由）和用户交互来渲染页面，仅与服务器 API 进行数据交换，这种就是前端渲染，特点是不跑 JS 操作 DOM 无法将用户想看的数据呈现出来。在服务器端根据用户请求的路径和 query 参数使用 EJS 、PUG 等模板引擎来渲染页面并返回不需要额外处理就可以直接显示的页面，这种就是服务端渲染，特点是即便用户禁用了 JS 也不影响数据的展示。

当今大多项目都是前后端分离的了，特别是 App 和网站共用后端的项目，但面向 SEO 会额外做一个服务端渲染，因为搜索引擎通常没法直接抓到一个需要前端跑 JS 渲染才能完整呈现信息的页面。

@x77
新旧对比下来哪里分离了你就是装没看到，非要从自己的理解上去剖析这部分字眼，如果你的生活很愉快的话，那我要开始怀疑你是否患有精神疾病了哦