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

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 条回复
murmur
2016-08-09 09:22:19 +08:00
@mdluo 哦对了你要知道微博改版一次被骂一次,所以大家都很喜欢最老的版本
另外我不希望无限加载,我宁愿分页
FrankFang128
2016-08-09 09:23:19 +08:00
@noli 你要给安卓 iOS 提供数据接口那分离肯定是必然的,不过现在的趋势是在 app 直接展示页面,所以不分离的情况也很多。
FrankFang128
2016-08-09 09:24:25 +08:00
@mdluo jQuery 做个无限滚动好简单……
zongwan
2016-08-09 09:24:40 +08:00
记得最后次谈到这个问题的时候说的是 API 是否可以共享给第三方
搞后端有一段时间了,前端和 node 相关的那套还什么都不懂。。。
附近也没 node 工程师,除了资深 java 就是应届毕业生。。。前后端分不分也还是得看环境。。。
负责的项目反正一个人做,爱咋咋地。。。
FrankFang128
2016-08-09 09:25:35 +08:00
@mdluo 你说的这些功能,确实适合做成 web app 的,那么用 React 我没意见。
SourceMan
2016-08-09 09:25:44 +08:00
前后端分离:
JS + Java ( node.js )前端
C 后端

我们现在的情况,挺好的
kalman03
2016-08-09 09:26:06 +08:00
楼主你好,我司坚决不玩前后端分离,你若乐意,来我司搞个完美的搭配吗?
feilaoda
2016-08-09 09:26:49 +08:00
分离后,反正现在就是出活比较慢
czheo
2016-08-09 09:28:10 +08:00
1. 全端工程师贵且少。
2. 你让一个工程师从 Hadoop 一直写到 CSS ,很难精益求精,况且很多人也不愿意学的这么杂,员工难免抵触。
3. 当手机, web 甚至桌面至少两三套前端代码,前后分离是很自然的选择。
4. 你的经验谈可能来自你最近创业经验,小公司一锅端有利于用最少投入快速开发。但后期随着逻辑越来越复杂,做的优化越来越细小,投入的码农越来越多,分离也是水到渠成的。
规模不太大的项目不分离也挺好的, ror 就是这哲学。总之,这是一个 tradeoff ,分与不分各有利弊。
guyskk
2016-08-09 09:28:20 +08:00
我是后端,我很喜欢前后端分离。分工明确啊,后端可以多花心思在优化性能,完善测试,提高安全性这些问题上,前端就多花心思研究交互,还有浏览器的兼容问题等等。术业有专攻。
yimity
2016-08-09 09:29:04 +08:00
适合的地方不一样。不过也有几分道理。不是所有的都适合前后端分离。
dazui
2016-08-09 09:29:49 +08:00
@FrankFang128 比如前后端不解耦的情况下,前端搞了很多用户体验方面的功能,这部分工作后端服务完全不关心,但这些功能必须要在 jsp 里渲染才能呈现,而 jsp 跟后端 service 还不能分开开发,所以后端开发既要是个粗壮的能做饭的大厨,同时还要是个漂亮的能传菜的小妹,这种情况真不好协调。
nikymaco
2016-08-09 09:30:17 +08:00
呵呵,说得挺好的。虽说是吐槽,但是不经意间道出了前后分离的意义。
viko16
2016-08-09 09:34:04 +08:00
1. 各司其职挺好的
2. 全端工程师又不是全干工程师
tairan2006
2016-08-09 09:34:57 +08:00
后端的任务本来就是数据结构,性能这些东西。小公司后端还要兼职运维、数据统计。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

© 2021 V2EX