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

2016-08-09 07:17:39 +08:00
 FrankFang128

原文在 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. 小公司别搞前后端分离,徒增复杂度!!!

128214 次点击
所在节点    JavaScript
562 条回复
ibudao
2016-08-09 09:52:05 +08:00
@mengzhuo 前后端分离跟服务端渲染(即你说的 Nodejs 渲染)好像是两码事吧,前后端分离是指业务数据跟展现的分离, UI 渲染是展现层的部件,这块按需求即可以放在用户前端做,也可以放在服务端来做。这种服务端渲染虽然也是在服务端,但是跟以前的概念不一样吧
xmuxsp
2016-08-09 09:52:30 +08:00
天下大势 分久必合 合久必分
Fleey
2016-08-09 09:53:14 +08:00
......你可能没尝试过后端与前端结合于一个页面(好比一个 php 页面混搭了 html),这感觉超级恶心,一旦你要进行前端 ui 修改的时候你会感受到恶心无比。前后端分离可以减少后端的工作量, ui 仅仅是前端负责即可。之所以我这样说,因为前后端都是我 ORZ 。
yanyandenuonuo
2016-08-09 09:55:50 +08:00
最开始我也是把全栈当成奋斗的目标,也认为一个人可以去做前端、后端和移动端,但随着时间的推移,我现在几乎否定了之前的想法。===术业有专攻这句话还是对的===。前段时间开始做架构也想过是否可以前后端分离,因为未来极大可能是要做移动端的,但因为项目耦合太严重加上时间比较紧还是放弃了,但后面如果有新项目开始做,我肯定采用前后端分离,一是人员安排上,不可能所有人都是全栈,毕竟有人就是喜欢前端,有人喜欢后端,分离之后可以让每个人都发挥出 100 的能力去做自己喜欢做、擅长的事情,这样不仅节约项目时间,对开发者也友好,毕竟不用花时间去做不喜欢或不擅长的事,省下来的时间是去玩去干嘛都是个人的事了;二是可以复用一部分后端的接口,毕竟在很大一部分比如一些展示,一些操作,在浏览器中点击和在移动端点击对于后端是一样的。
julio867
2016-08-09 09:56:08 +08:00
记得 N 年前做 C#的时候,有个活儿叫“套页面”,那个时候还没有前后端分的这么明显,做 C#前后台都需要懂,说实话,我个人还是蛮支持这种方式的,否则你只会做后台,不利于人的成长~~但是,前后分离也有其好处,目前被很多人滥用了,也把前端神话了,新建一个项目,动辄就要用 react,angular,nodejs·····貌似不用这些就很丢人一样,却从未考虑过项目自身的情况是否适合采用某某技术
coolzjy
2016-08-09 09:56:44 +08:00
当一个产品可以使用的时候,人们就不再仅仅局限于可以使用

按照 LZ 的逻辑, WEB 只需要 HTML 就够了,这才是真正承载信息的部分, CSS 和 JS 又有什么用呢?
noli
2016-08-09 09:58:55 +08:00
@FrankFang128 facebook 以前也跟你一样的想法,现在老实地用 native app 而不是用 html5 页面了,虽然 react native 也是类似 html5 的思路
newguest
2016-08-09 10:00:40 +08:00
我做过不到两个月全站开发,项目不大,真的一个人就搞定了。
交互显示都是 pm 设计的吧,我只要写出前端再赶后端就行了。
domty
2016-08-09 10:00:57 +08:00
把后端分离出来好处还是挺多的吧。
首先就是只开发一套接口就能对应多个客户端了。(所以各个 app 和网页在我心里差不多都算前端)
其次就是分布式机器上跑的时候像 node 那样去做请求中转然后渲染网页回复还是挺好的一个办法。

只是觉得前端的框架,概念啊推进的实在太快了,现在看起来有就是有些过于混乱。
sunmonster
2016-08-09 10:03:15 +08:00
用 vue.js 比用 Jquery 有优越感的前端怎么破?
dtysky
2016-08-09 10:04:53 +08:00
看规模啊
小规模就后端渲染静态网页啊
中小规模可以后端为主前端为辅搞点效果啊
中规模 SPA 就可以上上框架了啊
大规模就必须上框架了啊,工程化起来对你以后和接手你活的人都有好处

至于前后端分离,分工细化虽然有好有坏,但从历史整体来看总是能提高效率的
后端追求稳定,前端追求新奇快速酷炫,二者的目的本就不同啊, BUG 的频次和严重性也不是一个等级
你不能为了改前端的 BUG 把后端给。。。对吧
gimp
2016-08-09 10:06:26 +08:00
说了这么多,总感觉分离的好处你还是没理解透彻。
Arrowing
2016-08-09 10:08:54 +08:00
时代在改变,对于楼主来说,只能说是 too young 。
前后端分离,专业分离,对开发效率还是有极大提升的,各司其职。
如果硬是要嵌套页面开发,如同 PHP 那般,我倒发现很多后端人员都不会写 js 、 css ,如何是好?
geew
2016-08-09 10:09:01 +08:00
支持一下 同意楼主的观点
现在公司的网站基本都是我一个人做的 前后端 当然页面有专门的人来写 我负责后端渲染和 js 个人觉得要是有人来替代我写 js 固然是好 但是彼此之间的约定实在太多 而且目前来看 我们的网站用到复杂的交互的地方不多 所以感觉这样也挺好
然后我自己的网站什么都是自己做...泪奔.
wtser
2016-08-09 10:09:47 +08:00
按照楼主的逻辑,那是不是前后端最好也不要分了,大家都搞全栈。
领域细分是一种发展的规律。
解耦,专业化,提高开发效率,有好处才会有搞的动力。
repus911
2016-08-09 10:09:49 +08:00
你有没有从运维的角度考虑过 前后端分离后 扁平化水平好扩展 在这个 docker 的时代...
subpo
2016-08-09 10:11:03 +08:00
说的乱七八糟的,能总结一下吗
CtrlSpace
2016-08-09 10:14:17 +08:00
看看帖子,涨涨姿势
think2011
2016-08-09 10:16:59 +08:00
能总结一下吗
taoche
2016-08-09 10:18:10 +08:00
因为 jQuery 写的好比 能写 Vue React 要求高...
很多人只是会用 jQuery 在松散的结构下很难保证代码的逻辑清晰 拓展性 稳定性等...
框架的出现 其实是降低开发者的一定程度上的「开发能力」
也不需要什么使用设计模式了... 反正大家都在 Vue React 的模式下写代码.. 写的好的 和写的差的 差距也不是天壤之别了。这是工业化的胜利

就比如说 性能优化... jQuery 有很多优化方案,可以细化到 选择器缓存,读写操作的划分,事件的绑定 等...
在 Vue React 很多细节的优化都帮你做好了. 当然它们自身也有需要优化的地方 只是更显式更好理解

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/298014

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX