推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
这是一个创建于 3063 天前的主题，其中的信息可能已经有所发展或是发生改变。
原文在 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 几下就弄出来了。性能还比他好。
其他：
启动服务器工程慢，就要解决慢的问题。
以前所有页面都是一次输出的，但是大公司首页实在太大了，功能太多，等全部渲染完， 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% 的人力啊（分离需要两个人）
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
 |
201
ll0jj0xx0 2016-08-09 12:42:49 +08:00
前后不分离的话 UI 元素有的是后端直接渲染出来的有的是前端 ajax 得到的
久了之后会很混乱，会让人不想去改 UI 项目小的话不分离没啥问题人脑理得清，项目大了久了就有问题了 |
 |
202
superkey 2016-08-09 12:50:23 +08:00 via Android
前后分离应该是考虑到今后用 app 的，保证数据统一性。
|
 |
203
xiangtianxiao 2016-08-09 12:50:42 +08:00 via Android
|
|
204
xiangtianxiao 2016-08-09 12:51:11 +08:00 via Android
@xiangtianxiao 不好意思手抖了...
|
 |
205
ChefIsAwesome 2016-08-09 12:51:22 +08:00
你所说的简单网站里有 ajax 吗？ ajax 取到的数据，塞到模板里头，这是后端的事还是前端的事？前端负责 ajax 的话，这是不是就前后端分离了？把调接口，塞模板这一块放 node 那层，跟页面里头 ajax 取数据区别大吗，你觉得这就能算后端了吗？
|
 |
206
zsx 2016-08-09 12:59:08 +08:00 via Android
现在的前端又不是只是做几个展现页面的。我现在在做一个 WebApp ，并且没什么心情一个一个$$$$，开发效率太低都在做无用功。另外我没懂楼主强行扯上 Nodejs 中端有什么意义。
你说前端的东西要让后端可插手，然而后端的东西仍然要配置一堆环境才能跑得动（ PHP 都要起 cgi 呢）。而且双方互相插手有什么意义？前端出现了一大堆构建工具，恰恰说明现在的前端正在工程化、正规化，也大大提高了双方的开发效率。 而且你说不提倡前后端分离，那这么多年的客户端开发全部都要变成后端直接给 XAML 之类的渲染吗？大部分的软件也是如你所说可以直接后端模板渲染出来的呀。 分离需要两个人就完全是强词夺理了。 我赞同的是，例如活动页等一次性展示页、博客等基本没什么交互的页面，直接模板+jQuery 方便。剩下的，就前后端分离吧。 |
 |
207
jerray 2016-08-09 13:00:49 +08:00
楼主说的前端的概念很局限，只局限在了浏览器是吧？
如果项目只给网站提供服务，团队又足够小，那爱咋写咋写。一旦你的产品既要为浏览器端提供数据模板渲染，又要给移动 App 提供数据，那么前后端分离的做法是不是会降低一些后端压力呢？ 后端只提供数据接口，处理业务逻辑。前端管你是什么浏览器还是桌面应用还是移动应用，来后端拿数据就是了。 这样，浏览器前端因为浏览器的特性，就要自己去实现登录态管理，去实现部分缓存以降低后端压力。 跟语言没关系，跟框架也没关系。你的后端只是一个单纯的数据业务中心，把它当成一个数据库就好。 另外，一个人就能知道整个业务，说明还是业务太少，项目不够大（小项目瞎折腾个啥）。没见过哪个医生啥病都会治的。 |
 |
208
Rand01ph 2016-08-09 13:01:03 +08:00  1
正在前后端分离的团队工作，可是业务逻辑前端尽然不闻不问？！鉴于这种现状，我更倾向选择全栈式开发。
|
 |
209
urtrcc 2016-08-09 13:03:27 +08:00
只能呵呵
|
 |
210
williamx 2016-08-09 13:09:12 +08:00
1. 一个人知道整个业务。任何业务问题，马上解决。
这个不是好处，有些时候还是必须要避免的弊端。 4. 简单。所有概念都来自 W3C 标准，没有那些私有的概念（我说的就是 Virtual DOM ） 看似简单，其实很混乱。你也说了，不利于招聘。 只有前后端分开，才能各自快速的发展，而不需要拖个大油瓶，互相掣肘。这一点参考物理学的发展史就可以了。 |
 |
212
zoues 2016-08-09 13:30:58 +08:00 via iPhone
@FrankFang128 我很荣幸
|
 |
214
phxsuns 2016-08-09 13:49:34 +08:00
感觉楼主看问题不够透彻啊。哪有这么简单的。。。
|
 |
215
YuJianrong 2016-08-09 13:52:56 +08:00 1
看起来像是废柴前端和废柴后端写的东西。
为什么这么说？以为一个工程师要能 精通前端的时候还能把后端也掌握到精通（或者反过来）？ 呵呵。 |
 |
216
ajan 2016-08-09 13:52:56 +08:00
很多前端都会后端，这个话题还有什么好争论的...，一个人写完了
|
 |
217
FrankFang128 OP @phxsuns 哪有那么复杂的？
|
 |
218
coetzee 2016-08-09 13:57:22 +08:00
同意楼主观念，很多时候，前后分离是多此一举的举动，反而徒增复杂度，如无必要，勿增实体。当然我们也要考虑到具体的场景来分析，如果所构建的应用比较复杂，前端开发人员水平比较高的情况下，前后分离对于工程化，结构化等系统性架构问题还是很好的。
但是，大多数情况下，真的没有必要，只会增加成本，当然对于行业来说是一个利好，但事实上，该有的问题依然存在，甚至增多。开发效率，项目管理，代码可维护性等，未必会好，开发成本可能更高。当然这一切都是取决于团队人员和项目的具体分析而来。 总之：不要为了前后分离而分离，项目的人员水平和项目具体业务等情况，都是参考因素。 |
 |
219
foomorrow 2016-08-09 13:58:31 +08:00
人员上是否要分离主要看团队内人员的能力，代码上是否要分离就要看 leader 是否重视质量了。
鉴于目前人才市场上充斥大量培训班水平的，能分还是分吧，一端腐烂总比总体烂好 |
|
220
FrankFang128 OP @Rand01ph 前端如外包，对业务不关心（不愿关心），也关心不了（无法关心）。
|
 |
221
nino 2016-08-09 14:00:17 +08:00
工程师当然是要往全栈发展，但是技术架构上肯定是前后端分离的，即使后端模版渲染，也要做到前后端分离啊。这里的前端指的是直接面向用户的部分，并不是按语言分，不管你写 PHP 也好， Java 也好。
|
|
222
FrankFang128 OP @YuJianrong 一个三五年的后端，花点时间学下前端，不是什么问题。反过来就不一定了。
|
 |
224
DevineRapier 2016-08-09 14:03:51 +08:00
以前后台开发新功能不用做管理，现在前后分离还要写文档，唉，文档真的好恶心。。。。。。
|
 |
225
imn1 2016-08-09 14:05:00 +08:00
想知道 LZ 的“分离”定义是什么
从文章及回复看，存在人手分离和业务分离两种概念混杂，而且一会儿说这个，一会儿又是那个，很不清晰 前后端分离理应指的是业务分离，即使同一个人做，也是应该分离的 为什么业务分离？ 很重要一点是前端和后端并不是一对一关系，是多（前端）对一甚至多对多关系 从后端摆脱前端直接输出，是可能要使用很多套输出方案并行的 再说人手分离 一个人同时做网页（ N 大浏览器兼容）、 Android/iOS/WindowsMobile 、非面向公众的业务客户端……呵呵 |
|
226
FrankFang128 OP @imn1 分离指后端输出 JSON 就不做了，前端负责渲染界面。一般分给两个人做一个业务。
|
 |
227
wobuhuicode 2016-08-09 14:11:04 +08:00
抛开业务说技术都是耍流氓的
|
|
228
FrankFang128 OP @wobuhuicode 大部分业务都不需要前后分离。 只有上面说的几个特例需要。
|
 |
229
gxm44 2016-08-09 14:20:04 +08:00
@YuJianrong 赞同
|
 |
230
zenliver 2016-08-09 14:20:30 +08:00
@FrankFang128 解耦， 必要时后端和后端也要分， 前端和前端也要分，，，
|
 |
231
xiaonengshou 2016-08-09 14:22:35 +08:00
@FrankFang128 纯粹引战啊。。。每个项目都有自己的架构思路的。。。
|
 |
232
xylitolLin 2016-08-09 14:25:38 +08:00
我是前端，刚开始看到这个题目，我也觉得楼主是来引战的，看着看着，确实有点道理
|
|
233
FrankFang128 OP @xylitolLin 你再看看我以前的帖子
|
|
234
FrankFang128 OP @xiaonengshou 不是的， 90%的网站都是增删改查而已，而且不需要做成单页面
|
|
235
FrankFang128 OP |
 |
236
magicdawn 2016-08-09 14:32:54 +08:00
分离挺好的, 职责清晰, 就像当年 MVC 要分开一样, 现在是 MC 了, 直接不管 VIEW 了, VIEW 独立出来, 更爽...
|
 |
237
liyj144 2016-08-09 14:33:59 +08:00
我只说一句话：一大帮比自己牛 X 的人都在努力的方向，基本不会是偏离的方向，尤其是技术上。 全栈工程师在此飘过。
|
|
238
imn1 2016-08-09 14:40:48 +08:00
@FrankFang128
你这是偷换概念啊，前后端分离是大概念，怎能大幅缩小范围呢？纯粹是引战 json 只是一种数据格式而已，例如以前，包括现在还很普遍的使用 xml ，网页端就用 xslt->html+css ，其他客户端就用各种 xml paser 解析器+渲染器 诸如此类，但总的来说就是后端输出一个不限客户端的通用可解析数据，这就是目前前后端分离的概念 如果不分离，后端至少要输出两个方案：一个 BS ，一个 CS ，而且根据需求，极可能要两套或以上设备运行，之间还要做数据同步 |
|
239
FrankFang128 OP @liyj144 那可不一定啊……比如 XHTML 、 Flash ……
|
|
240
FrankFang128 OP @imn1 输出两个 format 是很简单的事情， RESTful API 就行了
不然 HTTP 请求头里面的 accept 是干啥用的。 |
|
241
nino 2016-08-09 14:51:25 +08:00
@FrankFang128 后端 model 映射到一个结构化数据是很简单，映射成一个 HTML 文档简单吗？ UI 说白了就是一直在变，就是复杂，所以把他单独管起来。
|
 |
242
wind4 2016-08-09 14:52:24 +08:00
你这里所说的前端是指 web 前端，但在我们划分前后端职责的时候说的是：前端负责交互和展示。而这个范围包括 PC 、 App 、网页等等。
|
|
243
zenliver 2016-08-09 14:55:46 +08:00
@FrankFang128 你只需要知道服务的接口怎么用就行， 干吗知道那么多呢， 比如你要用到 twitter api, 难道你不知道他怎么内部实现的， 就不能工作了，，， 说白了就是抽象
|
 |
244
besteric 2016-08-09 14:57:41 +08:00
楼主很早就离开阿里了么？
目前我们已经开始主推「全栈工程师」了，内部项目和控制台类应用，甚至部分线上项目，开发同学都是从前端写到后端（基于 React 封装的 DPL ，包含基本的样式和交互），前后端分离的概念已经越来越淡了：） 这套技术方案，我们即将开源，可以关注下 PS ：阿里巴巴-国际 UED-前端团队（ Base 杭州 /深圳）欢迎大家，一起来做点有趣的事情 |
|
245
FrankFang128 OP @besteric 今年离开的，早期 1688 那边的 React DPL 我也参与了……
|
|
246
FrankFang128 OP @nino 不是很复杂呀，毕竟 HTML 很类似 XML
|
 |
247
lguan 2016-08-09 15:30:56 +08:00
说的挺好的，这个观点我也一直在思考，首先全栈我是最推崇的，我自己也是走的全栈的路线，在队伍允许的情况下，全栈我觉得会更好，当然队伍条件可以的情况下，怎么做都不会是问题。
不过就我个人来说，我也经常回头看自己的代码，比如 rails 做的项目，我会发现，大部分时候，都在写 js 或者 coffeescript ，所以我会考虑是否要在前端引入框架，但是做到后面，发现分离以后，后端无论用什么，都没有 rails 舒服。 但是回到队伍本身，有时候事情不是完全能按照自己的意愿去建立，在人员实际情况的限制下，前后端分离目前还是有一定的可取之处 |
 |
248
jarlyyn 2016-08-09 15:40:19 +08:00
难道不是越是全端越是喜欢前后端分离么？
|
 |
249
Wangxf 2016-08-09 15:43:10 +08:00
我是前后端分不分都无所谓，反正学点后端模版语言也没啥
|
|
250
besteric 2016-08-09 15:46:51 +08:00
@FrankFang128 嗯，变化挺快的，我们都已经经历了三次迭代升级了：）
|
|
251
Wangxf 2016-08-09 15:48:18 +08:00
不过楼主倒是说出了真相，国内有多少公司需要 react 呢？大部分业务 jquery ＋ template 足以，无非就是装逼显得自己很牛逼抬高门槛，我不是阴谋论，我就是前端，看到很多，比如新闻类的网站也装逼上 react ，知乎有阵子也特么上个 react ，神经病，现在是项目还没开始，先 react ， babel ， gulp ， webpack 全都搬出来了，好了，终于可以开始写 hello ， world 了，有意义么？不是说反对这些项目，而是没用到点，比如前端在线编辑器，管理后台重操作重数据编辑的用下 react ， vue 说提升效率我不反对，这个稍微了解下就知道，但是尼玛你一新闻网站，问答网站搞 react 不是装逼是干嘛？国内这风气，哎
|
|
252
Wangxf 2016-08-09 15:54:01 +08:00
不过全栈要求确实太高了，以现在创业公司体量，基本上是找不够人的，你说的是招软件工程师， web 工程师
|
 |
253
zanpen2000 2016-08-09 15:55:28 +08:00
@superkey 对啊，一套服务对应多个产品，这样的例子太多了
|
 |
254
ExploreWay 2016-08-09 15:57:25 +08:00
java 全栈开发的路过，目前进阶 node.js 开发
|
 |
255
DaraW 2016-08-09 15:57:40 +08:00 1
感觉楼主说的和我所理解的不太一样。。。
个人认为前后端分离后，后端服务化，而不只是 Web 层开发的前后端分离，这样分离后整个 Web 层都可以理解为前端。在这之前前端一方面有点闲了，分离增加点任务提高门槛也不是坏事，另一方面后端更后，专注底层服务的稳定。而分离后的前端，不用去考虑 API 的背后发生了什么，至于页面渲染在 B 端渲染和在 S 端渲染各有各的合适场景。各自做各自的测试等等也会更方便。 前后端分离个人理解为一种架构，这与设计模式等等类似，每种架构和模式都有对应的场景，抛开场景谈架构和模式意义不大。 楼上有人把 Vue 和 jQ 比较的个人感觉一个 view 层的库和一个工具类库没有比较性可言，要比也是把 Vue 常见的一套和 jQ+backbone 来比较。 至于 Node.js ，感觉这个出了有利有弊，利在于前端生产力的提升，推动了前端工程工具的发展，在这之前不可否认前端工程化不是没有，但推广程度挺差的， Node 的火爆让前端工程化工具层出不穷，工具优劣不做评论，个人感觉现在还是探索期，实践才能沉淀出最佳实践； Node 的弊端除了 Node 自身之外，还有就是一些人会将传统前端的开发思维带进 Node 。然而 Node 只是一个普通的后端平台，注定和其他的平台一样有优点和缺点，无脑鼓吹 Node 不可取，无视 Node 更不可取。 还有就是前面提到的 Node 和 nginx ，感觉 Node 和 nginx 没有什么竞争关系啊， nginx 是一个服务器，用做静态资源服务器和负载均衡等等， Node 虽然也可以实现 nginx 的功能，不过并不觉得他们会有什么冲突。 不可否认的是 JS 相关的东西都在越来越火， JS 一统天下可以当个笑话来看看，也可能被实现，无论如何可以看到的是 JS 相关的东西以及 JS 本身正在借鉴已经成熟的平台 /产品，变得越来越完善。我的态度是在这股热流中，保持自己的见解，学习值得学习的东西，不去过度迷信工具。 |
 |
256
railgun 2016-08-09 16:09:28 +08:00
其实就是前后端分离的架构并不适合楼主现在的业务，所以看不到好处，还带来了一堆问题。
我的观点是，前后端是否分离没有好坏，只有合不合适 |
|
258
FrankFang128 OP @oscarzhao 不分离一样要好好写文档，你看那些流行的 jQuery 插件，文档多好看啊
|
|
259
FrankFang128 OP @jerray 我说过啦，用 RESTful API 就能解决这个问题
安卓请求 json format ， Web 请求 HTML format |
|
260
jarlyyn 2016-08-09 16:31:04 +08:00
|
 |
261
andyL 2016-08-09 16:41:34 +08:00
看过楼主的两个帖子，都有干货，是抱着讨论的目的来发帖的，这一点我很欣赏，赞一个。
不过我觉得这篇文章写得不太好，最起码应该先就什么是”前后端分离”达成一致。 看了大家的回复，结合我不多的开发经验，我觉得“分离”之后的模块化更容易理解和被工程使用。 图不错。 |
|
262
FrankFang128 OP @jarlyyn 因为按照 REST 的观念， JSON 和 HTML 只是两种展示方式而已，数据内容是一样的。
|
|
263
FrankFang128 OP @andyL 不分离也能模块化，只是面向全栈的 Web 框架不多而已。比如 meteor js 。
前后分离之后只是让「写出针对前端的框架」更容易而已。 |
|
264
jarlyyn 2016-08-09 17:08:04 +08:00
|
|
265
FrankFang128 OP @jarlyyn 不包括 JS 的 HTML ， JS 是行为，不跟数据放在一起。
这个是「古代」 Web 开发的约定吧 |
 |
266
maxsec 2016-08-09 17:09:24 +08:00
楼主~ 艹粉么~ 加个微信呗
|
|
267
jarlyyn 2016-08-09 17:10:26 +08:00
|
 |
268
damonzhaofei 2016-08-09 17:16:35 +08:00
你做 webapp 也不搞分离，我给你点赞。。你们公司招的人都要全栈。你们老板有钱还是有耐心。。
|
|
269
FrankFang128 OP @damonzhaofei 彩程公司，你搜搜。
|
 |
270
wizardforcel 2016-08-09 17:50:37 +08:00
其实我觉得纠结分不分离，还不如直接写写 ios/安卓，你不分离都不行。
浏览器端的乱象是必然的，因为框架要发展，但是 W3C 好像也不重视这个，所以各个流派就起来了。我前几年就预料到了这种情况，所以一开始就选择安卓，等浏览器端发展好了再回来看看。 |
 |
271
lixia625 2016-08-09 17:58:48 +08:00
我觉得并不是会不会的问题，就算你是全栈，一个大项目一个人就是做不了（规模在那里），这个时候就需要分工，前后端分是一个相对较优的分工方式吧
|
|
272
FrankFang128 OP @lixia625 用现成的库或组件啊
|
 |
273
YvesX 2016-08-09 19:47:52 +08:00 1
脱离了工程实际，这种问题只会变成宗教争论。
“前后端分离”看上去很正确。其实即使从整个社会的尺度来看，“专业化”也特别政治正确。 但这个正确是建立在复杂度的基础上的，不应该不加权衡地奉为圭臬。 遗憾的是，许多人深知缺乏规范的弊端，所以特别喜欢追求规范，以至于矫枉过正，特别热衷于信奉信条。 既然以解决问题为目的，应该少谈些主义。 |
 |
274
xieguanglei 2016-08-09 19:50:06 +08:00
求作图的软件
|
|
275
FrankFang128 OP @xieguanglei balsamiq 加 hanzipen 字体
|
 |
276
zhibushiwo 2016-08-09 20:43:29 +08:00
看各位大大讲感觉好厉害的样子
|
 |
277
JamesRuan 2016-08-09 20:45:44 +08:00
我玩前端两个月的时候，打算重写一个每日 IP 量四位数论坛，用的设计就是前后端分离（ REST+Angular ），前端工程化方案，甚至连 Node.js 中间层都有考虑在扩展方案里面。这个项目想找人一起做，多半是因为我是学医学的，一直找不到能合作的人。
后来自己忙了，再加上 Angular 出了 2 有些犹豫，就一直搁置在那里。 当时还和某刚入职美团的前端妹子讨论这套方案来着，直到一年后，突然发现阿里那群人怎么弄的东西和我想得一样…… |
 |
278
jayyjh 2016-08-09 20:55:15 +08:00
前后端不分离写起来实在是累，又不是人人都是全栈
|
 |
279
8e47e42 2016-08-09 21:10:02 +08:00
楼主，我就在国外，大公司不用说了，小公司不单搞分离，而且搞的比国内还明确，归根结底是人工费用高要外包给不同的人，不分离以后怎么维护？
|
 |
280
metrue 2016-08-09 21:19:38 +08:00
除了刚开工作的时候使用 Rails 全栈之外，之后的所有的项目都是前后端分离，而且个人项目也一直前后端分离。
|
 |
281
Kevinww 2016-08-09 21:46:04 +08:00
开始学写后端了？
|
 |
282
NullMan 2016-08-09 21:54:06 +08:00
我觉得楼主说得很有道理, 前端单纯用 HTML + CSS + jQuery 一样能做复杂的业务.
|
 |
283
sigmadg 2016-08-09 22:03:44 +08:00
还有一条，前后端分离对 SEO 并不友好。
不过 在企业开发领域，前后端是很有必要分离的 |
 |
284
pandachow 2016-08-09 22:07:04 +08:00 1
这不是显然么……如果一个人都会了，当然就不分最好。。。
最好还是前端，后端，算法，设计全包了。。。 问题难道不是因为实在是这样招不到人，于是得想办法拆开啊。。。 |
 |
285
lfyzjck 2016-08-09 22:49:03 +08:00
前后端分离的意义除了能处理更复杂的交互以外，更大的意义来自协作效率的提升。
事实上规模稍大的公司，前后端都是独立的人负责的。要让前端理解后端的架构，让后端更写出性能好又没有 BUG 前端页面，这提高了双方的学习成本。 OK ，你们公司运气比较好，找到了 2 个全栈工程师，前后端都牛逼，那么某天其中一个人离职了，你的公司可以承受这样的风险嘛？无论怎么推崇全栈工程师，真正面向用户的产品，最终会回归到前后端独立工作的局面。而这种人员架构的分离，才最终导向了前后端分离的架构。 具体不分离的时候有多坑，有经验的都体验过，不多说了。 |
 |
286
MinonHeart 2016-08-09 23:21:27 +08:00 via iPhone
前后端分离是次要的。初期的架构设计太重要了，设计的烂，中后期各种坑，各种重构
|
 |
287
Actrace 2016-08-09 23:25:34 +08:00
作为一个长达 6 年的全栈工程师兼架构师，我说一下我的观点。
经手了很多项目后发现，一些稍大的项目（至少 4 人配合），前后端完全分离具备一定的意义，在磨合较好的团队中施行这套策略，可以很好地提升开发效率。不过前提是你能把握住局面，也就是清楚的知道各个部分的衔接，前后端彻底分离开后需要一个人来控制总体结构，才能保质保量。那么实质上考验的是负责衔接的那个人。 不过大多数创业项目可能在初期并没有那么多人负责开发，顶多一个人两个人，那么这个时候其实也可以做到前后端完全分离，怎么做呢？那就是预留。 把接口预留好，这样后端在做前端的时候使用接口（虽然还是用 PHP 之类的后端语言构建前端页面），等队伍壮大后，前端独立出来，这套接口还是可以继续用的。 稍微有进展的公司，项目都会从单纯的 web 扩展到移动客户端甚至是桌面客户端，前后端完全分离还是有一定的意义的，只不过过程可能是极其缓慢的，正如你考虑的那样，一开始就做前后端完全分离是不理智的，不过适当的预留也可以避免项目扩大后的重构危机（假如有机会）。 至于个人玩的项目，我推崇楼主的观点。 |
 |
288
bk201 2016-08-09 23:39:41 +08:00 via iPhone
后端那么好做？后端的学问很稳定，不像前端五花八门，但是知识面之广，做前端的小瞧了点吧.说实话，我觉得前端玩的一些概念后端早就有了.
|
 |
289
boogiefer 2016-08-09 23:49:00 +08:00 via iPad
后台服务要服务化，满足多平台接入，例如移动端， web 端，第三方等。
前台要组建化，统一体验，对用户友好。 还没说可用性和安全性，这就是分工的意义，最终保障的产品质量和服务质量。 楼主应该是想表达个人能力，技术的发展宽度，而非组织架构团队分工的问题。 |
 |
290
hasbug 2016-08-10 00:03:47 +08:00
问题是，不是人人都和楼主一样有能力啊，能前后通吃。
|
|
291
FrankFang128 OP @hasbug 你有没有想过，是因为我们用的框架，不前后通吃。而不是因为人。
|
 |
292
specialized 2016-08-10 00:04:44 +08:00
@urtrcc 说就说，不说就不说，呵呵个***玩意啊。估计你属于有技术那种，但无奈语文体育老师教的……组织不起来！
|
 |
293
luoway 2016-08-10 00:07:32 +08:00
我的前端团队的主要 Leader 就在上周提出了前后端不分离的想法，不过后端是用 nodejs 。讨论的结果是接下来的一个项目按页面而不是按功能分，要什么接口自己写。这样可以生产高聚合的程序，忽略适用性和可维护性，以提高效率。 Leader 自己也说这样做适合初创团队，适合小团队，有益于团队成员的成长，而不是在自己擅长的领域固步自封难以提升。与楼主不谋而合。
|
 |
294
liujin834 2016-08-10 00:25:19 +08:00
大公司我不知道，小团队来说前后端还是要分离的，后端 API ，前端完全独立一个项目是目前我们团队的状态，这样对每个人的要求都很高，但是业务逻辑十分清晰，每个人拉出来都能顶住一方面业务，还可以交换着做，很好。我们后端是 nodejs + python ，前端 angularjs 单页应用，后端是由好几个 git 项目组成的， API 同时面向 web 和 app ， web 前端也有独立的 git 项目，团队里每个人都是从 php ， nodejs ， python ， ruby ， java 到 jquery ， angularjs 都能写，数据库也是 pgsql, mongodb, mysql(极少)混杂，对这些全盏工程师来说要从业务到架构都分离，我们连模板引擎 ejs 和 jade 都省了，全部都是轻装上阵。
|
 |
295
orvice 2016-08-10 01:04:02 +08:00
看情况吧，我们分离就有好处：
* 后端写一套 api 给 web/app 通用 * 后端写测试也方便 |
 |
296
incompatible 2016-08-10 01:15:30 +08:00 via Android
作为后端开发，我觉得前后端分离蛮好的，后端专心做逻辑就好，不用操心前端这种复杂的东西。专业的事情就交给专业的前端工程师们搞就好了。
至于全栈，我若是有学会前端从而成为全栈工程师这个闲工夫，我宁愿多写几个 testcase 提升一下后端代码的质量。 |
|
297
FrankFang128 OP @orvice 不分离也能做到……请看 Rails
现在测试做得做好的社区就是 Rails 社区吧。 |
 |
298
NekoTora 2016-08-10 01:57:38 +08:00 1
从我开始写第一行 html 开始，我一直以为凭着一个 chrome 和一个记事本我就能做一个“优雅”的前端……
直到有一天，他们开始逼我用这些前端工具…… |
 |
299
binux 2016-08-10 04:36:47 +08:00 3
「一个人能做的事情变成需要两个人做了」
并没有，原来 20 个人做的事，并不是变成需要 40 人做了，而是其中 10 人做后端， 10 人做前端了。总人数并没有变啊。 而且作为后端，前端那些活我压根不想做好吧！ |
 |
300
majik 2016-08-10 08:32:51 +08:00 via iPhone
前后端分离一方面 web 、 app 可以复用同一个服务器，使用同一套逻辑，降低维护成本；另一方面可以将渲染的计算压力丢给客户端，降低成本，前端直接使用静态文件维护起来也方便，还能提升用户体验。
如果你看过 openstack horizon 那套渣渲染设计，就该庆幸前后端分离。 我司就是全栈开发，照样前后端分离，一样搓的比原来爽。 |
Select Language