admin 案例分享 2023-06-01 21:02:16

为什么我不喜欢「前后端分离」（个人观点，欢迎来喷）

原文在 http://iwritejs.com/dont-seperate-backend-and-frontend/

我不知道国外有没有「前后端分离」的运动，我只知道国内的大公司喜欢搞这个。

前后端分离大概的意思就是后端只给前端提供数据，前端负责 HTML 渲染（可以在服务器渲染，也可以在浏览器渲染）和用户交互。

说这个说得最多的就是阿里的前端了。同时阿里的前端也是在中国最活跃的。

为什么做前后端分离？

本篇文章我来腹黑地揣测一下原因。以下言论不针对某个个人，而是对前端群体的群嘲。我坦然接受你的反嘲讽。

最开始的前后端：

图一

某些团队做前后端分离，主要的原因是

如果不分离，前端对网站的控制力太弱，没有话语权。
前端想要扩大势力范围。扩大了势力范围才有晋升的机会。

在前后端分离之前，前端就是页面仔。技术大牛都是后端，鲜有前端能晋升到架构师层级。这不是对前端的歧视，而是前端真的只是做做页面、加个动效而已，凭什么晋升到架构师。

当时前端能控制的，就是 CSS 和 JS 文件。连 HTML 都是放在后端的仓库的。因为 HTML 是由服务器输出的，用到的模板语言就是后端的。

Node.js 火了之后，前端看到一个机会， HTML 是可以用 Node.js 来输出的呀，于是鼓吹前后端分离，把 HTML 层面交给前端来控制。这样前端就能管控更多的东西了（好可怜，终于能掌握 HTML 的控制权了）

HTML 如果放在浏览器渲染，就是下图

图二

HTML 如果用 Node.js 渲染，就是这样

图三

看起来只是掌握了 HTML 的控制权，但是这里面可以做的文章可多了。

以前 HTML 是 Java 、 PHP 输出的，或多或少存在效率不高的地方，现在用 Node.js 重写，效率是不是就提升了（很少有程序重写了，效率还下降的）。效率提升了是不是该奖励下前端，给几个晋升名额呢？

前端得到好处了，就更要巩固自己的地位了。以前的 jQuery 代码，后端看看就懂。「那不行，我要搞点后端看不懂的」，这样才能显示我前端的技术含量，这样才能升值加薪啊。于是 React 、 Gulp 什么全加上。

好了，我编不下去了。

总之我不认同这种前后端分离。

为什么？

因为

又增加了一个中间层（当然程序员通过增加中间层来解决问题），好处是有，职责明确；但是也有坏处：人为地拉长了战线。对比图一和图三你就会发现，结构变复杂了，一个人能做的事情变成需要两个人做了
并没有实质变化。以前的后端结构也是存在调用 Service 逻辑的，现在只不过换成让前端用 Node.js 做。除了把本来就吃紧的前端人力耗费在他不擅长的领域，我没看到什么提升。这里唯一的好处就是前端是势力范围扩大了。

我认同的是「全栈工程师」。

一个业务的前后为什么要分给两个人写？以表单提交为例，后端要对数据做校验，前端也要做。为什么要让两个人都写一次？前端说可以让后端也写 Node.js ，这样就可以服用代码了呀。

搞笑吗？后端写了三年的 Java 你现在告诉他要全部重来？后端肯定不愿意啊。

矛盾就出在，分『后端』和『前端』两个职位上。

大公司细分后端和前端，也是可以理解的。这里不表。

我只是说前端端分离的缺点：

大部分站点，不应该分前后端。除非你的前端，非常非常非常复杂。但是大部分站点的前端，根本没有那么复杂！
分了前后端很容易出现各自为政的情况。推诿、邀功、互相鄙视，不一一列举了。
有人问一个人怎么又学后端又学前端？我的建议是把前端做薄，如果没有必要，不要搞什么 Angular 、 React 。用原生 JS 或者 jQuery 能满足大部分网站。同时后端向 Rails 学习。局部交互复杂的地方，采用动态加载来做交互。
有人说你是前端的叛徒，你这么做前端还有什么前途。

搞笑，你做了前端就要一辈子为前端说话吗？太屁股决定脑袋了吧。

标题有点标题党，其实真正主题是：前后端分离是前端不得志的必然结局。（好像更标题党了 XD ）

难道前后端分离没有好处吗？

我觉得只有一个好处：好招聘。毕竟你要招一个优秀的全栈工程师是极其困难的。

有人说，你真有意思，说这么多缺点，你还不是给不出解决方案，说了跟没说一样。

说下我的思路

保持前端简单，复杂了就用原生的方式封装，具体来说就是用自定义标签来封装复杂组件。这样一来，后端同事还是可以开发页面，因为只是多了一个自定义标签而已，本质还是 HTML
尽量不要在开发状态加 watcher ，目的也是让后端可以直接上手，不需要了解那么多工具。转译放到 Web 框架的开发者模式里面做，看到 less 请求加转义成 CSS 不是什么难事也不复杂。
前端只是辅助（这里说的是大多是网站，不包括重型 Web 应用），前端要做好服务化：健全的文档、友好的接口。
前端也要学后端知识，别在那自嗨。
小公司别搞前后端分离，徒增复杂度！！！

有些人老是喜欢揣测我的能力是不是不行才这么说。

工作经历：

毕业前在腾讯某前端部分实习近一年
在腾讯、阿里纯前端部门工作三年（jQuery、Vue.js 和 React.js）。
在某创业公司做单页面应用一年（Angular和Backbone）
目前在学后端（用过 PHP、C#，现在在用 Rails）。

其他的情况看我以前的帖子

严格来说，我做了四年『纯前端』，所以不要以为我是后端开发。我回复太快，被限制回复了…… @ibudao 如果这些好处没有带来弊端，那当然是好。但是你 client render 之后，逻辑分散、状态不一致的问题要怎么解决呢？
另外，渲染重，你有两个选择：让一个前端把渲染放到浏览器做，或者再买一台服务器。显然，服务器更便宜。 @zlgodpig 关于首屏与第二屏的问题。这个确实是前后端分离的最大契机。
以前所有页面都是一次输出的，但是大公司首页实在太大了，功能太多，等全部渲染完， 10 秒钟都过去了。
于是乎，第二页让 JS 来动态渲染。

这里有两种场景：
1. 第二页的内容与第一页没有关系（这个有点奇怪，为什么不新开页面）
2. 第二页的内容与第一页的结构基本一样（如微博、推特）

场景 2 最著名的解决方案就是 big pipe ，后端前端混合方案。你说的分离是一种方案，但不是唯一的方案。
场景 1 我觉得就是产品经理的问题，需求没想好。

前端工程独立管理看从哪个角度了，维护权给前端没问题，但是可以集成到后端的，比如后端路由发现是 less 请求，直接就变成 CSS 内容。然后发布之前， build 一下前端资源就好了。

我反对的是把简单的事情做复杂，把一个人能做的事情给两个人做。

比如 V2EX 上好几个人发帖『用 vue.js 做了一个 XXX 页面』，说实话，用 PHP 加 jQuery 几下就弄出来了。性能还比他好。

其他：

启动服务器工程慢，就要解决慢的问题。我又不能回复了 @Livid ，我没有太频繁啊。

你们就不要拿空洞的『细分总是好的』『发展规律』这种话来讨论了。

你司咋不专门雇一个人写 HTML、一个人写 CSS、一个人写 JS 呢？

而且现在前端把所有东西都跟后端隔开，到底有什么好处？

解耦？如果你认为后端输出就不能解耦，只能说你的后端框架有问题。
处理bug方便？那是因为你们的后端不会写前端，前端不会写后端造成的。就跟一个人学了 CSS 但是不会 JS 一样。
对开发者要求太高？是的，所以我说要把前端做薄，不要搞单页面框架。用 jQuery 你遇到过什么很复杂的 bug 吗？反观 React，一旦出了 bug，呵呵。

再说不分离的好处：

1. 一个人知道整个业务。任何业务问题，马上解决。
2. 代码量少。同样的逻辑不需要写两遍（相比浏览器渲染而言）。
3. 也能支持多端。/data 分 /data.json 和 /data.html 两种表现（ RESTful ）
4. 简单。所有概念都来自 W3C 标准，没有那些私有的概念（我说的就是 Virtual DOM ）
5. 省人力。多了 100% 的人力啊（分离需要两个人） OA 跟 ERP ……

这里有几个人是做这种软件的，这种软件完全符合我说的『非常非常非常复杂』好吗，当然需要前后分离。机器到期，换地址了 http://frankfang.github.io/dont-seperate-backend-and-frontend.html ----------------------- 以下是精选回复-----------------------

答:oh 找到同类了... 前些天还在跟同学吵吵这事儿...
答:分离之后，感觉前端框架，工具等东西上手的周期太长了
答:用楼主的腹黑逻辑，这个肯定是担心被抢饭碗的后端。后端只提供 api ，关心数据结构，不知多开心。
答:1. 有个重要的消耗，而且还是非常严重的你没考虑到（尤其是移动端），那就是 http 。如果你的测试仅在于 127.0.0.1 或者内网，那没啥说的；
2. 存在即合理；
3. 前端没有自 high ，也是被逼的；
4. 前后端分离的主要目的是解耦，保持简单，术业有专攻。

至于你说的前端话语权啥，前端不得志才搞前后端分离啥的，只能呵呵
答:不是所有人都能做全端的，楼主放心。
答:html 页面的本质是应用， dom 的本质是控件，偏要当成文档来处理，这就是最大的问题。

我不知道你接触没接触过安卓。安卓的布局 xml 里面可以包含别的 xml ， java 代码中可以直接 inflate xml 生成控件，也可以把 xml 封装成自定义控件。鉴于浏览器的这个德性，这些想做的话，要么手写，要么用框架。
答:只想说没人逼着你前后端分离，不喜勿用! 如果连用不用的话语权都没有，那来这里抱怨也无济于事，该跳槽就跳槽，该转行就转行！
答:前后端分离有个好处，就是这些接口基本不用改就可以拿给 APP 用，你的数据如果全用后端渲染，到移动端甚至 web 端，你还单独出一套代码？
答:经验不多，我个人感受，后端只提供 api ，前端负责渲染，不考虑 seo ，代码明显更好写了，逻辑更清晰。在后端的模板渲染 html 甚至是字符串拼接，还需要后端来考虑应该有哪些 html 结构的页面，结构应该是什么样的。
答:我发现声称不喜欢前后端分离的人，大多数是做 web 开发的。只能说，浏览器和 nodejs 给了你们迷之自信。
答:鸡蛋不要放在一个篮子里，分而治之是 web 开发一直以来的趋势，分层的目的是降低耦合，提高抽象。
答:楼主的言论就是停留在猜测，一点点优化打开 qzone 的速度，你认为真有那么多后端愿意搞？推 cdn 你以为是后端发起？首屏域名收归你以为后端愿意搞？
答:前后端分离造成的问题
答:我的观点:即使不前后端分离，也要数据和渲染分离。我是支持前后端分离的。支持 js 的浏览器就把渲染放前端，不支持的就请求服务器渲染好了再发 html css 过来。这样哪天要把网站做成 app 也就是改客户端，没服务器啥事。
答:楼主字写得很有个性……
答:楼主的后端其实是我们口中的前端，真正的后端根本不处理 HTML 这类小事
答:我同意楼主的观点！
答:前后端分离不是阿里炒出来的嘛，不是因为阿里前端写 PHP 性能差才转 Nodejs
答:it depends
答:我只说全栈太难了，很少有人能够前端后端都搞好。

另外个人是觉得 nodejs 火起来很奇怪，之前为了使用 socket.io 用了一下，觉得完全是回调地狱。
异步回调其他语言很早就有了，现在其他语言都已经开始推进到了多线程阻塞语言自动转换成为异步协程方式了(python+gevent 、 go)。但异步回调却是 nodejs 宣传的重点。
另外听说 js 也新增了原生异步语法能够解决回调地狱，不过没在接触。
答:大概是因为 webapp 的流行吧。。
答:个人觉得应该分离，术业专攻，真正的全栈工程师毕竟不是那么多……
答:总之工作好做就行
答:前端就是事儿多，都是闲的慌
答:我们公司前后端分离没有 node 做中间层
答:Rails 的 turbolink 不就是残废版的 virtual DOM 吗

Rails 确实很优秀，但是也确实很老了，至少在处理前端方面

还以为在前端技术里就 Vue 和 React 能互喷，没想到 Rails 居然也能
答:为什么我不喜欢 mvc 架构，明明只用 jsp 就能搞定一切的
答:HTML 是什么？我只关心数据。
后端的逻辑为什么不分离？和前端一起画画？
并且呀，前端学了那么久了，早就该开始写后端了嘛， nodejs 不是很火嘛~
答:我所见过的全栈前端代码根本不行都是拿后端思维在搞术业有专攻前端还要考虑渲染交互浏览器优化等等很多事情前后不分离的时代又不是没有过 Dreamweaver 各种 IDE 级的绑定我就在写 .net 还是 2.0 的时代我就在写最后感觉都不靠谱直到前端这个专业分工出现我才觉得 WEB 开发有希望了
答:非常喜欢楼主的几篇有个人见解性质的文章，从批判的角度看前端，给人更多的思考。
答:做 web app 就前后端分离，不是就后端渲染。看产品需求咯。
答:前后分离多了中间层去处理后端的数据，其实真的很不优雅。不过在现在讲求分布式业务下，这点性能损失也是可以容忍的。
只要业务大了，后端肯定需要和前端分离的。否则多端开发的时候，后端都要写一次，很辛苦的。
答:你觉得都愿意这样么?你在大公司呆久了没啥,人家业务多,分离可能会比较和你,但是你去过小公司么,你知道有一部分的小公司的后端有多水么?前端的东西是完全不会写,人家 HR 也是没有办法才要求招的前端,这些后端当然喜欢分离了啊,毕竟自己工作就少了啊.
答:支持楼主 , 一切为了开发效率
大公司前后端分离是为了开发效率以及分工明细，
小团队前提倡敏捷开发,没必要太过的提倡前端的复杂度
答:记得最后次谈到这个问题的时候说的是 API 是否可以共享给第三方
搞后端有一段时间了，前端和 node 相关的那套还什么都不懂。。。
附近也没 node 工程师，除了资深 java 就是应届毕业生。。。前后端分不分也还是得看环境。。。
负责的项目反正一个人做，爱咋咋地。。。
答:前后端分离：
JS + Java （ node.js ）前端
C 后端

我们现在的情况，挺好的
答:楼主你好，我司坚决不玩前后端分离，你若乐意，来我司搞个完美的搭配吗？
答:分离后，反正现在就是出活比较慢
答:1. 全端工程师贵且少。
2. 你让一个工程师从 Hadoop 一直写到 CSS ，很难精益求精，况且很多人也不愿意学的这么杂，员工难免抵触。
3. 当手机， web 甚至桌面至少两三套前端代码，前后分离是很自然的选择。
4. 你的经验谈可能来自你最近创业经验，小公司一锅端有利于用最少投入快速开发。但后期随着逻辑越来越复杂，做的优化越来越细小，投入的码农越来越多，分离也是水到渠成的。
规模不太大的项目不分离也挺好的， ror 就是这哲学。总之，这是一个 tradeoff ，分与不分各有利弊。
答:我是后端，我很喜欢前后端分离。分工明确啊，后端可以多花心思在优化性能，完善测试，提高安全性这些问题上，前端就多花心思研究交互，还有浏览器的兼容问题等等。术业有专攻。
答:适合的地方不一样。不过也有几分道理。不是所有的都适合前后端分离。
答:呵呵，说得挺好的。虽说是吐槽，但是不经意间道出了前后分离的意义。
答:1. 各司其职挺好的
2. 全端工程师又不是全干工程师
答:后端的任务本来就是数据结构，性能这些东西。小公司后端还要兼职运维、数据统计。

前端不仅仅指 web ，其实安卓、 iOS 客户端这些都是前端。况且还有 React Native 这种跨平台的思路。

前后端解决的问题核心完全不一样，我赞同前后端分离。当然有些内部用的小项目，一个人完成的话，没必要。
答:渲染是有 CPU 和内存开销的，在大量渲染场景中，你觉得这个开销是放在服务端自己维护，还是利用现在越来越高性能的终端设备呢？
答:楼上的喷点不对啊。
人家 LZ 说的是反对前后端分离中的 Nodejs 把前端渲染又做了一遍。
答:这个话题这么火
答:牛逼，帮你顶一下。
我的一个同事和楼主的思路差不多。
而我的思路和楼主的正好相反，我想尝试前后端分离（我所在项目一共两个人）。

看了楼主的文章，看来我要好好反省以下了。
答:按照前端出静态页面的开发模式，后端其实分偏后后端和偏前后端，偏前的需要去套页面，所以从工种上，偏前的后端的一部分工作被 node 替换，其实变化不大。

前端和后端的工程性质不一样，后端要稳，前端要酷炫点并且快速迭代。所以两端放在一起管理，发布的频次，稳定性的要求都不一样。

另外前端出来 bug 怎么办？后端来修前端 bug ，对后端要求也太高，前端来修，后端要之前待命，等前端修好，然后去发布吗？

除了首屏 html ，前端 ajax 的请求越来越多，开发时，前端需要的数据哪里来。后端可能还没开发好；开发好了，前端起后端服务，起个 java 工程，起得你想哭。

前端工程独立管理是必须的。（如果这点，你不同意，其实就什么好说的了

所以如果是后端只提供 api ，前端 ajax 后，第二屏在渲染页面，后端开发就舒服多了，两端各自管理自己的东西，这个工程上好管理，个人觉得开发效率也高。

但是这种方式有它的适应场景： seo 不好处理；一下精细化的控制不好做，比如针对不同的用户，输出不同的静态文件。所以有些地方加 node 也是 ok 的。

加了 node ，可以做 api 的合并，这个 app 端也可以用，一些简单的验证和分流，还有页面静态化等。

所以还是按工程规范，人员水平，这种分离都算是对现在情况的一种回应，最后 KPI 也是现在情况的一个部分