推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
FrankFang128

为什么我不喜欢「前后端分离」(个人观点,欢迎来喷)

  FrankFang128 · Aug 9, 2016 · 133720 views
This topic created in 3727 days ago, the information mentioned may be changed or developed.

原文在 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 什么全加上。

好了,我编不下去了。

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

为什么?

因为

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

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

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

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

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

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

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

  1. 大部分站点,不应该分前后端。除非你的前端,非常非常非常复杂。但是大部分站点的前端,根本没有那么复杂!

  2. 分了前后端很容易出现各自为政的情况。推诿、邀功、互相鄙视,不一一列举了。

  3. 有人问一个人怎么又学后端又学前端?我的建议是把前端做薄,如果没有必要,不要搞什么 Angular 、 React 。用原生 JS 或者 jQuery 能满足大部分网站。同时后端向 Rails 学习。局部交互复杂的地方,采用动态加载来做交互。

  4. 有人说你是前端的叛徒,你这么做前端还有什么前途。

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

标题有点标题党,其实真正主题是:前后端分离是前端不得志的必然结局。(好像更标题党了 XD )


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

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

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

说下我的思路

  1. 保持前端简单,复杂了就用原生的方式封装,具体来说就是用自定义标签来封装复杂组件。这样一来,后端同事还是可以开发页面,因为只是多了一个自定义标签而已,本质还是 HTML

  2. 尽量不要在开发状态加 watcher ,目的也是让后端可以直接上手,不需要了解那么多工具。转译放到 Web 框架的开发者模式里面做,看到 less 请求加转义成 CSS 不是什么难事也不复杂。

  3. 前端只是辅助(这里说的是大多是网站,不包括重型 Web 应用),前端要做好服务化:健全的文档、友好的接口。

  4. 前端也要学后端知识,别在那自嗨。

  5. 小公司别搞前后端分离,徒增复杂度!!!

Supplement 1  ·  Aug 9, 2016

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

工作经历:

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

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

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

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

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

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

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

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

其他:

启动服务器工程慢,就要解决慢的问题。
Supplement 6  ·  Aug 9, 2016
我又不能回复了 @Livid ,我没有太频繁啊。
Supplement 7  ·  Aug 9, 2016

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

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

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

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

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

这里有几个人是做这种软件的,这种软件完全符合我说的『非常非常非常复杂』好吗,当然需要前后分离。
Supplement 10  ·  Sep 6, 2016
562 replies  •  2022-05-10 20:05:45 +08:00
1  2  3  4  5  6  
❮ ❯
8023
    1
8023  
   Aug 9, 2016 via Android
oh 找到同类了... 前些天还在跟同学吵吵这事儿...
passion336699
    2
passion336699  
   Aug 9, 2016 via Android
分离之后,感觉前端框架,工具等东西上手的周期太长了
xujif
    3
xujif  
   Aug 9, 2016 via iPhone   ❤️ 4
用楼主的腹黑逻辑,这个肯定是担心被抢饭碗的后端。 后端只提供 api ,关心数据结构,不知多开心。
genffy
    4
genffy  
   Aug 9, 2016   ❤️ 3
1. 有个重要的消耗,而且还是非常严重的你没考虑到(尤其是移动端),那就是 http 。如果你的测试仅在于 127.0.0.1 或者内网,那没啥说的;
2. 存在即合理;
3. 前端没有自 high ,也是被逼的;
4. 前后端分离的主要目的是解耦,保持简单,术业有专攻。

至于你说的前端话语权啥,前端不得志才搞前后端分离啥的,只能呵呵
loading
    5
loading  
   Aug 9, 2016 via Android   ❤️ 1
不是所有人都能做全端的,楼主放心。
FrankFang128
    6
FrankFang128  
OP
   Aug 9, 2016   ❤️ 1
@genffy 我搜了下通篇没有『测试』两个字。 合理不代表正确。 解耦?以前也没有耦合呀。看看 amazon.com ,禁用 JS 页面都能正常运行,这才是解耦。
FrankFang128
    7
FrankFang128  
OP
   Aug 9, 2016
@loading 我现在公司的每个人都是全端
FrankFang128
    8
FrankFang128  
OP
   Aug 9, 2016