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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

推荐关注

› Meteor

› JSLint - a JavaScript code quality tool

› jsFiddle

› D3.js

› WebStorm

推荐书目

› JavaScript 权威指南第 5 版

› Closure: The Definitive Guide

这是一个创建于 3039 天前的主题，其中的信息可能已经有所发展或是发生改变。

原文在 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 应用），前端要做好服务化：健全的文档、友好的接口。
前端也要学后端知识，别在那自嗨。
小公司别搞前后端分离，徒增复杂度！！！

第 1 条附言 · 2016-08-09 07:53:45 +08:00

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

工作经历：

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

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

第 2 条附言 · 2016-08-09 08:25:46 +08:00

严格来说，我做了四年『纯前端』，所以不要以为我是后端开发。

第 3 条附言 · 2016-08-09 09:31:54 +08:00

我回复太快，被限制回复了……

第 4 条附言 · 2016-08-09 09:41:35 +08:00

@ibudao 如果这些好处没有带来弊端，那当然是好。但是你 client render 之后，逻辑分散、状态不一致的问题要怎么解决呢？
另外，渲染重，你有两个选择：让一个前端把渲染放到浏览器做，或者再买一台服务器。显然，服务器更便宜。

第 5 条附言 · 2016-08-09 10:01:00 +08:00

@zlgodpig 关于首屏与第二屏的问题。这个确实是前后端分离的最大契机。
以前所有页面都是一次输出的，但是大公司首页实在太大了，功能太多，等全部渲染完， 10 秒钟都过去了。
于是乎，第二页让 JS 来动态渲染。

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

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

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

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

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

其他：

启动服务器工程慢，就要解决慢的问题。

第 6 条附言 · 2016-08-09 10:06:14 +08:00

我又不能回复了 @Livid ，我没有太频繁啊。

第 7 条附言 · 2016-08-09 10:15:04 +08:00

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

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

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

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

第 8 条附言 · 2016-08-09 10:19:04 +08:00

再说不分离的好处：

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

第 9 条附言 · 2016-08-09 10:50:42 +08:00

OA 跟 ERP ……

这里有几个人是做这种软件的，这种软件完全符合我说的『非常非常非常复杂』好吗，当然需要前后分离。

第 10 条附言 · 2016-09-06 14:27:08 +08:00

机器到期，换地址了 http://frankfang.github.io/dont-seperate-backend-and-frontend.html

前端

HTML

分离

Node

562 条回复 • 2022-05-10 20:05:45 +08:00

1 2 3 4 5 6

❮

❯

101

ibudao

2016-08-09 09:52:05 +08:00

@mengzhuo 前后端分离跟服务端渲染（即你说的 Nodejs 渲染）好像是两码事吧，前后端分离是指业务数据跟展现的分离， UI 渲染是展现层的部件，这块按需求即可以放在用户前端做，也可以放在服务端来做。这种服务端渲染虽然也是在服务端，但是跟以前的概念不一样吧

102

xmuxsp

2016-08-09 09:52:30 +08:00

天下大势分久必合合久必分

103

Fleey

2016-08-09 09:53:14 +08:00

......你可能没尝试过后端与前端结合于一个页面(好比一个 php 页面混搭了 html)，这感觉超级恶心，一旦你要进行前端 ui 修改的时候你会感受到恶心无比。前后端分离可以减少后端的工作量， ui 仅仅是前端负责即可。之所以我这样说，因为前后端都是我 ORZ 。

104

yanyandenuonuo

2016-08-09 09:55:50 +08:00

最开始我也是把全栈当成奋斗的目标，也认为一个人可以去做前端、后端和移动端，但随着时间的推移，我现在几乎否定了之前的想法。===术业有专攻这句话还是对的===。前段时间开始做架构也想过是否可以前后端分离，因为未来极大可能是要做移动端的，但因为项目耦合太严重加上时间比较紧还是放弃了，但后面如果有新项目开始做，我肯定采用前后端分离，一是人员安排上，不可能所有人都是全栈，毕竟有人就是喜欢前端，有人喜欢后端，分离之后可以让每个人都发挥出 100 的能力去做自己喜欢做、擅长的事情，这样不仅节约项目时间，对开发者也友好，毕竟不用花时间去做不喜欢或不擅长的事，省下来的时间是去玩去干嘛都是个人的事了；二是可以复用一部分后端的接口，毕竟在很大一部分比如一些展示，一些操作，在浏览器中点击和在移动端点击对于后端是一样的。

105

julio867

2016-08-09 09:56:08 +08:00

记得 N 年前做 C#的时候，有个活儿叫“套页面”，那个时候还没有前后端分的这么明显，做 C#前后台都需要懂，说实话，我个人还是蛮支持这种方式的，否则你只会做后台，不利于人的成长~~但是，前后分离也有其好处，目前被很多人滥用了，也把前端神话了，新建一个项目，动辄就要用 react,angular,nodejs·····貌似不用这些就很丢人一样，却从未考虑过项目自身的情况是否适合采用某某技术

106

coolzjy

2016-08-09 09:56:44 +08:00

当一个产品可以使用的时候，人们就不再仅仅局限于可以使用

按照 LZ 的逻辑， WEB 只需要 HTML 就够了，这才是真正承载信息的部分， CSS 和 JS 又有什么用呢？

107

noli

2016-08-09 09:58:55 +08:00 via iPhone

@FrankFang128 facebook 以前也跟你一样的想法，现在老实地用 native app 而不是用 html5 页面了，虽然 react native 也是类似 html5 的思路

108

newguest

2016-08-09 10:00:40 +08:00

我做过不到两个月全站开发，项目不大，真的一个人就搞定了。
交互显示都是 pm 设计的吧，我只要写出前端再赶后端就行了。

109

domty

2016-08-09 10:00:57 +08:00

把后端分离出来好处还是挺多的吧。
首先就是只开发一套接口就能对应多个客户端了。(所以各个 app 和网页在我心里差不多都算前端)
其次就是分布式机器上跑的时候像 node 那样去做请求中转然后渲染网页回复还是挺好的一个办法。

只是觉得前端的框架，概念啊推进的实在太快了，现在看起来有就是有些过于混乱。

110

sunmonster

2016-08-09 10:03:15 +08:00

用 vue.js 比用 Jquery 有优越感的前端怎么破？

111

dtysky

2016-08-09 10:04:53 +08:00

看规模啊
小规模就后端渲染静态网页啊
中小规模可以后端为主前端为辅搞点效果啊
中规模 SPA 就可以上上框架了啊
大规模就必须上框架了啊，工程化起来对你以后和接手你活的人都有好处

至于前后端分离，分工细化虽然有好有坏，但从历史整体来看总是能提高效率的
后端追求稳定，前端追求新奇快速酷炫，二者的目的本就不同啊， BUG 的频次和严重性也不是一个等级
你不能为了改前端的 BUG 把后端给。。。对吧

112

gimp

2016-08-09 10:06:26 +08:00

说了这么多，总感觉分离的好处你还是没理解透彻。

113

Arrowing

2016-08-09 10:08:54 +08:00

时代在改变，对于楼主来说，只能说是 too young 。
前后端分离，专业分离，对开发效率还是有极大提升的，各司其职。
如果硬是要嵌套页面开发，如同 PHP 那般，我倒发现很多后端人员都不会写 js 、 css ，如何是好？

114

geew

2016-08-09 10:09:01 +08:00

支持一下同意楼主的观点
现在公司的网站基本都是我一个人做的前后端当然页面有专门的人来写我负责后端渲染和 js 个人觉得要是有人来替代我写 js 固然是好但是彼此之间的约定实在太多而且目前来看我们的网站用到复杂的交互的地方不多所以感觉这样也挺好
然后我自己的网站什么都是自己做...泪奔.

115

wtser

2016-08-09 10:09:47 +08:00

按照楼主的逻辑，那是不是前后端最好也不要分了，大家都搞全栈。
领域细分是一种发展的规律。
解耦，专业化，提高开发效率，有好处才会有搞的动力。

116

repus911

2016-08-09 10:09:49 +08:00

你有没有从运维的角度考虑过前后端分离后扁平化水平好扩展在这个 docker 的时代...

117

subpo

2016-08-09 10:11:03 +08:00

说的乱七八糟的，能总结一下吗

118

CtrlSpace

2016-08-09 10:14:17 +08:00

看看帖子，涨涨姿势

119

think2011

2016-08-09 10:16:59 +08:00

能总结一下吗

120

taoche

2016-08-09 10:18:10 +08:00

因为 jQuery 写的好比能写 Vue React 要求高...
很多人只是会用 jQuery 在松散的结构下很难保证代码的逻辑清晰拓展性稳定性等...
框架的出现其实是降低开发者的一定程度上的「开发能力」
也不需要什么使用设计模式了... 反正大家都在 Vue React 的模式下写代码.. 写的好的和写的差的差距也不是天壤之别了。这是工业化的胜利

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

121

jsjgjbzhang

2016-08-09 10:18:12 +08:00

做网页的都是太闲了么

122

bdbai

2016-08-09 10:19:05 +08:00 via Android

@geew 公司网站没必要分离吧，姿势水平高的甚至可以玩纯静态了。

后端用 Java 、 C#甚至 C 写的干干净净的 API ，你让它来个聚合+渲染？老板给我两份工资！

123

newguest

2016-08-09 10:19:28 +08:00

无意义的争吵， php 是世界上最好的语言。
laravel ， symfony 本身架构很好，模版引擎也不错，自己写个 sass ， less ， coffejs 也不难呀。
用个 bower ， exir ， npm 。用点其它 js 开源库，加载进模版一点都不乱。普通网站妥妥的！

124

hanyouchun66

2016-08-09 10:19:30 +08:00

那等你做过两年后端在谈这个话题吧.

125

jarlyyn

2016-08-09 10:21:42 +08:00

前后端分离好处很多。

测试，多客户端，易缓存，降低员工需求。

至于框架，难道现在的这些框架出来前前后端就不分离了么？

只用 jquery 就做不了前后段分离了么？

126

taoche

2016-08-09 10:21:52 +08:00

现在的问题是大部分前端开发者能力太低，编程素质不够...
不知道如果去做取舍达到一种合适的平衡。
所以就形成了跟风和盲从拿到 Vue React 就觉得找到了「银弹」
就像很多创业公司不论项目是什么类型都上 React Redux... 导致一系列问题

不过这也不需要过度关心，让时间去证明好了

127

xwartz

2016-08-09 10:24:10 +08:00

前后端不分离，发布很麻烦。。。总不能改下模板就要前后端一起发布吧？

128

adv007

2016-08-09 10:26:06 +08:00 via iPhone

呵呵，在中国当前的技术背景下，自称自己是全栈工程师的技术人员往往在每个领域都没做到最好，说白了，就是浮躁

129

inherited

2016-08-09 10:27:08 +08:00

前后端分离和组件化是客户端开发(Windows, iOS, Android)中早已实现的东西。客户端程序员负责界面搭建和数据展示，后端程序员只给数据就行了，目前 Web 应用的复杂度已经赶上客户端的应用了，使用客户端的开发方式是很正常的。我不认为做网站,App 和桌面应用的 GUI 开发除了语言之外有很本质的区别，主要功能都是数据展示，界面搭建和人机交互。它里面也有一些通用的思想和模式来解决问题，比如进来比较流行的 FRP(比如著名的 Reactive X 系列，在 Js 上就是 RxJs Angular2 也是受这套框架的启发)。

130

123s

2016-08-09 10:27:34 +08:00

跟 node.js 有毛关系

131

bdbai

2016-08-09 10:28:32 +08:00 via Android

个人认为楼主看轻后端了。
业务复杂度上去以后，即便前后端分离，“同样的代码”也绝对不会出现两遍。
一个页面渲染所需的数据，很多时候不仅仅来源于一个 API 。把 data.json 改成 data.html 并不解决问题，因为单纯渲染它也许并没有意义。
简单和省人力？后端也许从不熟悉 W3C ，简直要炸毛了喂。

132

shyling

2016-08-09 10:31:57 +08:00

@FrankFang128 例如 gmail/inbox...

133

mars0prince

2016-08-09 10:34:55 +08:00

看来楼主在 BAT 这三四年，技术方面不敢断言，至少工程方面没学到啥。
咱们的项目里，工作量都是一定的，同等水平的人，假设前端 2 小时，后端 6 小时，你一个人 8 小时能干完，但是假如项目需要 4 小时上线，怎么办？你是招一个和你同等水平的全栈工程师便宜，还是招一个前端便宜？
软件工程软件工程，说白了还是工程，不是每个公司都能像什么 google ， facebook ，开得出人人全栈的钱，你们公司全是全栈，也不代表业界就应该全是全栈，工程和技术，两码事

134

aivier

2016-08-09 10:35:27 +08:00

后端套完 HTML 那结构...经常会元素满屏飞，更不用说修修 Bug 让后端更新下还要看后端脸色了，也许这是分离最大的好处

至于 React 呢...总比要独立一个模块的时候去 HTML 里扒一点代码，再去 JS 里扒一点代码，还要调一下看看 jQuery 为什么静默失败了要好得多吧？
见过很多次喜欢用 jQuery 的人写出来 $(this).parent().parent().parent().parent().parent().children('xx').find('xx') 这样的代码了，如果他能学得会 React ，至少是能理解一些的话，应该也不会写出来这样的代码了

135

yeqiu

2016-08-09 10:38:11 +08:00

服务器做服务器的事情（主要优化数据的处理）
web 做 web 的事情（通用便捷的 web 应用，炫酷的宣传页面）
app 做 app 的事情

这也可以反对？

136

firefox12

2016-08-09 10:40:32 +08:00

因为后端比你想象的复杂，前端也比我们想象的复杂。让后端人员再去学习 css js 的东西，虽然能写点小的 css 和 js,如果水平不够，也做不好我的水平还停留在 jquery 操作操作 dom 的水平，前端讲的 js 框架对我有如天书。前端想了解后端的的业务其实也很难。你在阿里做过，你知道阿里搜索的流程吗？知道阿里云存储的架构吗？知道支付宝的数据库和业务架构分区规则吗？

所以分开只是无奈。

137

Ixizi

2016-08-09 10:45:55 +08:00

前后端分离可能是受到了安卓， iOS 的客户端冲击吧。

后端更注重于各个端的数据处理，前端则安心做界面。

138

yishenggudou

2016-08-09 10:46:23 +08:00

再加沟通
1 个前端 + 一个后端 <<<<<<<< 一个前后端一起玩的

139

yuankui

2016-08-09 10:46:47 +08:00

本故事纯属虚构，如有雷同，纯属巧合！😄

140

yuyang041060120

2016-08-09 10:48:21 +08:00

抛开业务场景谈技术都是耍流氓

141

murusu

2016-08-09 10:49:12 +08:00

同觉得楼主没吃透
估计楼主没碰到过前后端都很复杂的应用，比如说 oa 跟 erp 之类的
这类型的应用对功能可扩展性以及系统的可维护性都有很高的要求
如果按你所说一个人同时负责的前后端，那真是画美不看

142

cxyfreedom

2016-08-09 10:53:06 +08:00

前后端分离还是能够更加术业专攻吧。

另外，如果真的都是不分离搞成全栈，两个人变成一个人。从就业来看，一半的人就要失业了...

143

SpicyCat

2016-08-09 10:54:12 +08:00

前后端分离也不是绝对的，当然可以不分，因为这就不是个技术问题，而是个工程问题。有些团队认为前后分离，模块化容易开发容易维护，就分离喽。

144

icybee

2016-08-09 10:54:12 +08:00

React 和 Gulp 是用来装逼的。。。楼主最后得出了这个结论。。。大公司的后端很多都复杂到死。。。叫后端分担前端工作真不好。。。而且前端也越来越复杂，早不是后端能把控住的了。。。分工的细化是社会发展的必然结果，何必逆水行舟。。。

145

bdbai

2016-08-09 10:58:23 +08:00 via Android

等把应用做成 oa 和 erp 的规模时再分已经晚了。
后端不是白干的，数据也不是戏法变出来的。楼主总是站在前端的角度上，自以为做了后端的活导致后端没事干，才会有这样的想法吧。希望楼主继续深入学习后端知识，并用于实践，然后再来看“让后端变成全栈”这样的问题。

146

learnshare

2016-08-09 10:58:28 +08:00

分业务的， blog/news 这类以展示为主的页面，左前后端分离略浪费。

但各种后台管理系统，不分离不行。

147

FrankFang128

2016-08-09 11:04:20 +08:00

@icybee 你们后端复杂到死是因为服务封装得有问题。

148

RaymondYip

2016-08-09 11:04:34 +08:00

这个得看你的项目是做啥啊, 公司主页啥的静态页怎么弄没所谓.
那些多交互的页面, 编辑器之类的, 不分离你试试.
以前写 asp, php, jsp 前后端不分离那是各种恶心好嘛
现在分离了挺好的

149

FrankFang128

2016-08-09 11:05:56 +08:00

@SpicyCat 如果一个团队只有 2 个后端，有 10 个前端，那么搞前后分离我没意见，把工作量分到前端嘛。
但是如果 10 个后端， 2 个前端，还搞前后分离，就呵呵了。要把两个前端累死。

150

FrankFang128

2016-08-09 11:06:59 +08:00

@RaymondYip 没有那么多在线编辑器要做。分离对开发者好（工作变少了嘛，谁不爱），但是对团队不好（分成两部分）

151

FrankFang128

2016-08-09 11:08:06 +08:00

@murusu 你拿 OA 和 ERP 举例就抬杠了。这是典型的富交互单页面应用啊。不分离怎么弄。

152

wph95

2016-08-09 11:09:45 +08:00

全栈工程师固然好，
你能找到几个？ -。-

153

FrankFang128

2016-08-09 11:11:01 +08:00

@icybee
前端是不复杂，被搞复杂。
后端是复杂，但可以封装成服务。

腾讯和阿里的所有数据接口都是封装后再给后端用的，只要封装得没坑，调用方不会感觉很复杂。

154

pi1ot

2016-08-09 11:11:49 +08:00

你的观点太长了我没仔细看，不过你推测的前后端分工演化过程是错误的，基本上这个流程也是分为三步

1 、 2000 年之前到差不多 03 、 04 年前后，没有前端这个岗位，页面上的简单校验脚本都是可有可无的，代码基本上是这样
printf( "<html>%s</html>", content );

2 、 04 、 05 年左右开始后端开始普遍模版化，这时候仍然没有专职的前端，不过程序员拿到手里的都是切好的 html 页面和 css 文件，可以理解成页面工程师兼职了部分前端职责，代码是：
templet.set( "{%content%}", conent )
templet.output()

3 、从 05 年 AJAX 开始流程到再过几年 JSON 成为事实格式标准后，大约 07 、 08 年或者更早，才演变成了现在这样后端只输出 json ，前端负责所有展现端职责的分工

总体来是一个细化分工的趋势，业务逻辑相对稳定，展现逻辑和展现平台更加多变，两者解耦更有利
即使在第一阶段的大型项目中，也是有类似的模块分层的

155

nigelvon

2016-08-09 11:13:04 +08:00

前后端分离大势所趋，没人是傻子。

156

CTO

2016-08-09 11:13:09 +08:00

术业有专攻广而不深吃枣药丸

157

FrankFang128

2016-08-09 11:14:14 +08:00

@bdbai 同楼上，如果你们的后台重，说明没有封装好服务。后端不会 W3C 好意思吗？
一个页面渲染所需的数据，很多时候不仅仅来源于一个 API 。这种问题，跟分离不分离没关系。

158

FrankFang128

2016-08-09 11:14:40 +08:00

@CTO 话太空洞，不好讨论。

159

FrankFang128

2016-08-09 11:14:57 +08:00

@nigelvon 话太空洞，不讨论。

160

zenliver

2016-08-09 11:15:03 +08:00

除了平台架构，其他都是前端，什么分离不分离

161

FrankFang128

2016-08-09 11:16:26 +08:00

@pi1ot 你说的过程，跟我说的基本一样。
最开始后端只输出 JSON 是非常少见的情况。现在居然成了默认选项。感觉『人人都做单页面』

162

FrankFang128

2016-08-09 11:16:48 +08:00

@zenliver 所以你主张不分前后端咯……

163

icybee

2016-08-09 11:18:34 +08:00

@FrankFang128 怎么说呢，楼主说的部分是正确的，何服务封装多多少少都是有问题的，就是因为要不停解决这些问题所以才需要更专业的后端，楼主公司的情况可能真的比较简单，所以才会有 2 个后端， 10 个前端的说法，我之前的一个公司后端就相当复杂，有 c 的部分，有 php 的部分，有 python 的部分，有 nginx lua 的各种模块，还有用机器学习的一部分根本不知道用什么写的。。。甚至连上线系统都是自己开发的一套（ java ），集群有几千台机器分布在北京和南京，内蒙，在如此巨大的业务需求下后端的封装就要求到 service 层，然后前端的事情也是非常多，写页面，优化首屏加载速度啦，图片加载这里也大有可可为，前端同学甚至当是前端的同学设计了一种机器学习的算法来根据流量动态合并 css 和 js 资源（这都是前端同学做的），优化那一点点的首屏展现时间，所以说现在大公司前端后端都有非常多的事情要做，在这样的背景下分工就是极其合理的

164

CTO

2016-08-09 11:19:35 +08:00

@FrankFang128 我司 10+个后端 1 个前端 1 个设计也没见前端设计累死。。(后端均薪 13K 前端 18K)

165

pi1ot

2016-08-09 11:19:43 +08:00

@FrankFang128 我怎么觉得基本不一样呢

166

FrankFang128

2016-08-09 11:20:09 +08:00

@icybee 除了前端做的事情，其他同学做的事情都有价值，你们的前端真闲，花时间搞这。

167

pi1ot

2016-08-09 11:20:55 +08:00

@FrankFang128 json 才流行几年，在 json 之前一样有其他的东西来做这个事情，往前是 xmlhttp ，再往前还有直接输出 js 和自定义 text 数据的

168

FrankFang128

2016-08-09 11:21:06 +08:00

@pi1ot 你说的 2 对应我的图 1 ，你说的 3 对应我的图 2

169

pi1ot

2016-08-09 11:22:41 +08:00

@FrankFang128 这个顺序我没注意，主要是看你描述的起点不符合最早的情况，看来是你没经历过第一阶段，哈哈

170

chmlai

2016-08-09 11:23:47 +08:00

如果都是做博客页面当然不用分离了.

171

FrankFang128

2016-08-09 11:24:04 +08:00

@pi1ot 我经历最老的项目是在 C 代码里改 JS 。还不能在本地预览，部署一次在服务器上才能看！

172

est

2016-08-09 11:24:09 +08:00

我支持 LZ 的看法。很多页面就是搞活动，生命周期就几天。做那么复杂干毛。

173

holyghost

2016-08-09 11:24:36 +08:00

@chmlai 。。。。。。

174

sodatea

2016-08-09 11:24:50 +08:00

期待楼主下篇讲一下对 microservices 的看法

175

broadliyn

2016-08-09 11:26:34 +08:00

我也是做后端开发的，今年也打算把后台管理弄成 react SPA 了。

为什么？

因为原有项目 jsp 写的实在是懒得吐槽了，原来的那个界面里，写 JS 一点回调思想也没有，满屏的全局变量，把 JS 完全就当 Java 来写，好多 js 代码、控件都是百度到处找的百度 copy-paste ，整个界面就一个脏字了得，完全没有动力去加新功能，那代码简直懒得去动。

这次乘机会把界面部分彻底从原来的 java web 里拉出来，不会写 js 的还是好好写后端吧。

176

coconne

2016-08-09 11:26:44 +08:00

回帖都看了遍，感觉每个人前端后端理解不一定一样啊
比如， LZ 所认为的后端，我觉得那依旧是前端啊~~~

177

pi1ot

2016-08-09 11:28:01 +08:00

@coconne 这个定义在不同公司确实有差异，或者可以细分为系统后端和应用后端。

178

loryyang

2016-08-09 11:28:18 +08:00

我对前端的了解停留在 jQuery 上面。我是觉得软件工程发展到现在，好多东西处于过度设计的状态。很多时候根本没有到那个必要去做复杂的设计。系统一般是慢慢演化的，而不是出门就高大上的。有些东西一开始没有必要去使用

179

FrankFang128

2016-08-09 11:29:13 +08:00

@sodatea 没搞过 microservices 啊，貌似很火。

180

TaMud

2016-08-09 11:29:23 +08:00

前后端分离，主要便于前端可以自由的修改界面
前后端分离更重要的是安全，前端不需涉及后端安全考虑，这个才是最大的一个原因

181

chmlai

2016-08-09 11:29:53 +08:00

@holyghost .......

182

FrankFang128

2016-08-09 11:30:41 +08:00

@TaMud 如果前后端是同一个人，也可以自由修改界面啊……
分离后 XSS 可能少点吧，但是搞了前后端分离的大公司依然每年都有 XSS 漏洞，所以……没啥用。

183

sodatea

2016-08-09 11:33:26 +08:00

@FrankFang128 感觉跟前后端分离的目的 /手段差不多，都是无休止的分层……

184

bdbai

2016-08-09 11:40:14 +08:00 via Android

r#157 @FrankFang128 “没有封装好服务”这样的评价依旧是站在前端的立场上。首先业务逻辑复杂度不是仅靠封装就能降低的，即便封装良好的系统也可以很复杂。复杂是后端内部的描述，封装是其对外展现情况的描述，两者没有必然联系。比方说，后端有一个巨大的分布式搜索系统，对外只需保留一个 search 接口。
后端为什么要懂 W3C 呢😂
“不仅仅来源于一个 API ”是针对“/data 分 /data.json 和 /data.html 两种表现”这个例子。

我还是劝楼主多深入后端，这样对待问题才能有个大局观。之后再回味这个问题时，相信你会有不同的观点。

185

icybee

2016-08-09 11:43:02 +08:00

@FrankFang128 也不能这么说吧。。。完全把前端打死了。。。前端任务量老大了。。。所有交互逻辑都在前端啊和部分非核心业务逻辑都在前端啊。。。

186

ianva

2016-08-09 11:43:31 +08:00

在 nobackend 趋势的年代谈薄前端，就算是全栈那重心也要偏移

187

vai

2016-08-09 11:46:26 +08:00

前后端分离跟本不需要 Nodejs 的参与。

188

ianva

2016-08-09 11:51:16 +08:00

说白了，现在这个时代的后台非 node 模板的模式，无法适应现代的复杂的交互场景，和 app 类似，但 app 能自己控制渲染罢了， node 这个作用无法替代

189

FrankFang128

2016-08-09 11:54:42 +08:00 via Android

@ianva 我没发现现在的网页有比几年前复杂很多

190

wizardforcel

2016-08-09 11:56:12 +08:00

@FrankFang128 所以浏览器实际上在走 PC 和移动端的老路，前后端分离早就在这两个地方玩烂了。

而浏览器之前太缺组件化和模块化了。除了浏览器内的 JS ，任何现代的编程语言（包括 C ，也包括 Node ）都是天生模块化的。而组件化，考虑移动端比如安卓，虽然用起来很别扭，但是相当完备了。所以这种长期积压的弊端就得靠猛药來治，这也是呼声很高的原因。

我觉得 GUI 应用就该做成应用的样子，除非你的本意就是打算把它做成文档。

191

FrankFang128

2016-08-09 11:56:51 +08:00 via Android

@bdbai 你举得这么复杂的东西，在大公司一般是由一个部门负责封装的。而且肯定是做成服务的。
我不是站在前端角度说得，而是根据我看到的和用过的。

192

ianva

2016-08-09 11:56:58 +08:00

@FrankFang128 现在的后台面对的可不只是 web ，还有 ios 和 android ，如果是 nobackend 模式一套 api 能解决的问题，比原有的开发模式更合理

193

ianva

2016-08-09 11:58:42 +08:00

@FrankFang128 从另一个问题上讲 ios 和 android 的 app 为啥不能后台渲染刷新页面多简单呢？其实只是因为能利用的客户端功能强大，交互强大，所有 app 才不会说就刷个后台模板，前端道理也一致

194

int64ago

2016-08-09 11:59:04 +08:00

我感觉周围前端、后端、产品、测试基本谁都不服谁的，各自都在各自领域装逼，与其争论这些，海不如逼自己发展为全栈，所以这点我还是比较赞同楼主的

不过，话说不管前端还是后端，如果一个人**只会**写 Java 我觉得这个人是很难沟通的，不服可随便喷

195

SpicyCat

2016-08-09 12:03:22 +08:00

@FrankFang128 为什么 10 个前端，两个后端，就是把工作量分到前端；而 10 个后端， 2 个前端，就是把前端累死？

196

bdbai

2016-08-09 12:03:23 +08:00 via Android

@FrankFang128 服务封装好，还让他们包前端，实在不现实呀。
从你的工作经历来看，前端应该是你最熟悉的，因此你自然会从外往里看后端。

197

TaMud

2016-08-09 12:04:09 +08:00

@FrankFang128 你的反应太慢，看清条件，如果同一个人，不需要以后修改界面，还有必要前后端分离吗？？做为一个 it 人员，没有很强的逻辑能力和举一反三能力，那跟咸鱼有啥区别呢？？

198

dcoder

2016-08-09 12:10:26 +08:00

@FrankFang128
很多喷得挺有理
而且前端圈子里，框架之间的斗争也是搞死开发者了.
今天 AngularJS1, 明天 React,js, 后天又 AngularJS2,
再加上一堆没有后台的 backbone.js, vue.js ... 各种天天换着玩儿的 tool chains ...
这里面简直是智力绞肉机，耗费了无数前端 developers 的精力和时间.

199

z5864703

2016-08-09 12:11:07 +08:00

全栈和前后端分离不冲突啊，一个人也可以做前后端分离啊，我现在就是往这方面做。
全栈是代表人的能力，前后端分离是理念，不要搞混了。这都能扯到阶级斗争上去了，真醉了。
前后端分离我觉得是对部分业务有帮助的，至少在我开发的多个 WEB 项目中都是很大帮助，解耦简直不要太好。

200

djyde

2016-08-09 12:41:51 +08:00

我一个人写的东西也前后端分离。。

1 2 3 4 5 6

❮

❯