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

[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. 小公司别搞前后端分离，徒增复杂度！！！

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

工作经历：

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

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

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

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

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

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

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

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

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

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

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

其他：

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

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

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

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

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

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

再说不分离的好处：

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

OA 跟 ERP ……

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

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

[ll0jj0xx0]

前后不分离的话 UI 元素有的是后端直接渲染出来的有的是前端 ajax 得到的
久了之后会很混乱，会让人不想去改 UI
项目小的话不分离没啥问题人脑理得清，项目大了久了就有问题了

[superkey]

前后分离应该是考虑到今后用 app 的，保证数据统一性。

[xiangtianxiao]

@newghost

[xiangtianxiao]

@xiangtianxiao 不好意思手抖了...

[ChefIsAwesome]

你所说的简单网站里有 ajax 吗？ ajax 取到的数据，塞到模板里头，这是后端的事还是前端的事？前端负责 ajax 的话，这是不是就前后端分离了？把调接口，塞模板这一块放 node 那层，跟页面里头 ajax 取数据区别大吗，你觉得这就能算后端了吗？

[zsx]

现在的前端又不是只是做几个展现页面的。我现在在做一个 WebApp ，并且没什么心情一个一个$$$$，开发效率太低都在做无用功。另外我没懂楼主强行扯上 Nodejs 中端有什么意义。

你说前端的东西要让后端可插手，然而后端的东西仍然要配置一堆环境才能跑得动（ PHP 都要起 cgi 呢）。而且双方互相插手有什么意义？前端出现了一大堆构建工具，恰恰说明现在的前端正在工程化、正规化，也大大提高了双方的开发效率。

而且你说不提倡前后端分离，那这么多年的客户端开发全部都要变成后端直接给 XAML 之类的渲染吗？大部分的软件也是如你所说可以直接后端模板渲染出来的呀。

分离需要两个人就完全是强词夺理了。


我赞同的是，例如活动页等一次性展示页、博客等基本没什么交互的页面，直接模板+jQuery 方便。剩下的，就前后端分离吧。

[jerray]

楼主说的前端的概念很局限，只局限在了浏览器是吧？

如果项目只给网站提供服务，团队又足够小，那爱咋写咋写。一旦你的产品既要为浏览器端提供数据模板渲染，又要给移动 App 提供数据，那么前后端分离的做法是不是会降低一些后端压力呢？

后端只提供数据接口，处理业务逻辑。前端管你是什么浏览器还是桌面应用还是移动应用，来后端拿数据就是了。
这样，浏览器前端因为浏览器的特性，就要自己去实现登录态管理，去实现部分缓存以降低后端压力。

跟语言没关系，跟框架也没关系。你的后端只是一个单纯的数据业务中心，把它当成一个数据库就好。

另外，一个人就能知道整个业务，说明还是业务太少，项目不够大（小项目瞎折腾个啥）。没见过哪个医生啥病都会治的。

[Rand01ph]

正在前后端分离的团队工作，可是业务逻辑前端尽然不闻不问？！鉴于这种现状，我更倾向选择全栈式开发。

[urtrcc]

只能呵呵

[williamx]

1. 一个人知道整个业务。任何业务问题，马上解决。
这个不是好处，有些时候还是必须要避免的弊端。

4. 简单。所有概念都来自 W3C 标准，没有那些私有的概念（我说的就是 Virtual DOM ）
看似简单，其实很混乱。你也说了，不利于招聘。

只有前后端分开，才能各自快速的发展，而不需要拖个大油瓶，互相掣肘。这一点参考物理学的发展史就可以了。

[nevin47]

@Rand01ph 前端没必要知道业务逻辑啊，只要完成前端应该完成的工作就行了吧

[zoues]

@FrankFang128 我很荣幸

[Rand01ph]

@nevin47 这就是问题所在，后端负责数据相关的处理，页面上也有很多业务逻辑。

[phxsuns]

感觉楼主看问题不够透彻啊。哪有这么简单的。。。

[YuJianrong]

看起来像是废柴前端和废柴后端写的东西。

为什么这么说？以为一个工程师要能 精通前端的时候还能把后端也掌握到精通（或者反过来）？

呵呵。

[ajan]

很多前端都会后端，这个话题还有什么好争论的...，一个人写完了

[FrankFang128]

@phxsuns 哪有那么复杂的？

[coetzee]

同意楼主观念，很多时候，前后分离是多此一举的举动，反而徒增复杂度，如无必要，勿增实体。当然我们也要考虑到具体的场景来分析，如果所构建的应用比较复杂，前端开发人员水平比较高的情况下，前后分离对于工程化，结构化等系统性架构问题还是很好的。

但是，大多数情况下，真的没有必要，只会增加成本，当然对于行业来说是一个利好，但事实上，该有的问题依然存在，甚至增多。开发效率，项目管理，代码可维护性等，未必会好，开发成本可能更高。当然这一切都是取决于团队人员和项目的具体分析而来。

总之：不要为了前后分离而分离，项目的人员水平和项目具体业务等情况，都是参考因素。

[foomorrow]

人员上是否要分离主要看团队内人员的能力，代码上是否要分离就要看 leader 是否重视质量了。
鉴于目前人才市场上充斥大量培训班水平的，能分还是分吧，一端腐烂总比总体烂好

[FrankFang128]

@Rand01ph 前端如外包，对业务不关心（不愿关心），也关心不了（无法关心）。

[nino]

工程师当然是要往全栈发展，但是技术架构上肯定是前后端分离的，即使后端模版渲染，也要做到前后端分离啊。这里的前端指的是直接面向用户的部分，并不是按语言分，不管你写 PHP 也好， Java 也好。

[FrankFang128]

@YuJianrong 一个三五年的后端，花点时间学下前端，不是什么问题。反过来就不一定了。

[foomorrow]

@nevin47 后端没必要知道需求啊，完成 PM 布置的任务就好了吧

对自己不了解的领域不要太想当然

[DevineRapier]

以前后台开发新功能不用做管理，现在前后分离还要写文档，唉，文档真的好恶心。。。。。。

[imn1]

想知道 LZ 的“分离”定义是什么
从文章及回复看，存在人手分离和业务分离两种概念混杂，而且一会儿说这个，一会儿又是那个，很不清晰
前后端分离理应指的是业务分离，即使同一个人做，也是应该分离的

为什么业务分离？
很重要一点是前端和后端并不是一对一关系，是多（前端）对一甚至多对多关系
从后端摆脱前端直接输出，是可能要使用很多套输出方案并行的

再说人手分离
一个人同时做网页（ N 大浏览器兼容）、 Android/iOS/WindowsMobile 、非面向公众的业务客户端……呵呵

[FrankFang128]

@imn1 分离指后端输出 JSON 就不做了，前端负责渲染界面。一般分给两个人做一个业务。

[wobuhuicode]

抛开业务说技术都是耍流氓的

[FrankFang128]

@wobuhuicode 大部分业务都不需要前后分离。 只有上面说的几个特例需要。

[gxm44]

@YuJianrong 赞同

[zenliver]

@FrankFang128 解耦， 必要时后端和后端也要分， 前端和前端也要分，，，

[xiaonengshou]

@FrankFang128 纯粹引战啊。。。每个项目都有自己的架构思路的。。。

[xylitolLin]

我是前端，刚开始看到这个题目，我也觉得楼主是来引战的，看着看着，确实有点道理

[FrankFang128]

@xylitolLin 你再看看我以前的帖子

[FrankFang128]

@xiaonengshou 不是的， 90%的网站都是增删改查而已，而且不需要做成单页面

[FrankFang128]

@zenliver 分开和分离还是两个意思。
在后端把数据和标记做好，然后在前端去初始化、去请求数据。逻辑分开当然是对的。
现在的前后分离是前后端互相看不懂，只通过 HTTP 交流。

[magicdawn]

分离挺好的, 职责清晰, 就像当年 MVC 要分开一样, 现在是 MC 了, 直接不管 VIEW 了, VIEW 独立出来, 更爽...

[liyj144]

我只说一句话：一大帮比自己牛 X 的人都在努力的方向，基本不会是偏离的方向，尤其是技术上。 全栈工程师在此飘过。

[imn1]

@FrankFang128
你这是偷换概念啊，前后端分离是大概念，怎能大幅缩小范围呢？纯粹是引战

json 只是一种数据格式而已，例如以前，包括现在还很普遍的使用 xml ，网页端就用 xslt->html+css ，其他客户端就用各种 xml paser 解析器+渲染器
诸如此类，但总的来说就是后端输出一个不限客户端的通用可解析数据，这就是目前前后端分离的概念

如果不分离，后端至少要输出两个方案：一个 BS ，一个 CS ，而且根据需求，极可能要两套或以上设备运行，之间还要做数据同步

[FrankFang128]

@liyj144 那可不一定啊……比如 XHTML 、 Flash ……

[FrankFang128]

@imn1 输出两个 format 是很简单的事情， RESTful API 就行了
不然 HTTP 请求头里面的 accept 是干啥用的。

[nino]

@FrankFang128 后端 model 映射到一个结构化数据是很简单，映射成一个 HTML 文档简单吗？ UI 说白了就是一直在变，就是复杂，所以把他单独管起来。

[wind4]

你这里所说的前端是指 web 前端，但在我们划分前后端职责的时候说的是：前端负责交互和展示。而这个范围包括 PC 、 App 、网页等等。

[zenliver]

@FrankFang128 你只需要知道服务的接口怎么用就行， 干吗知道那么多呢， 比如你要用到 twitter api, 难道你不知道他怎么内部实现的， 就不能工作了，，， 说白了就是抽象

[besteric]

楼主很早就离开阿里了么？

目前我们已经开始主推「全栈工程师」了，内部项目和控制台类应用，甚至部分线上项目，开发同学都是从前端写到后端（基于 React 封装的 DPL ，包含基本的样式和交互），前后端分离的概念已经越来越淡了：）

这套技术方案，我们即将开源，可以关注下

PS ：阿里巴巴-国际 UED-前端团队（ Base 杭州 /深圳）欢迎大家，一起来做点有趣的事情

[FrankFang128]

@besteric 今年离开的，早期 1688 那边的 React DPL 我也参与了……

[FrankFang128]

@nino 不是很复杂呀，毕竟 HTML 很类似 XML

[lguan]

说的挺好的，这个观点我也一直在思考，首先全栈我是最推崇的，我自己也是走的全栈的路线，在队伍允许的情况下，全栈我觉得会更好，当然队伍条件可以的情况下，怎么做都不会是问题。

不过就我个人来说，我也经常回头看自己的代码，比如 rails 做的项目，我会发现，大部分时候，都在写 js 或者 coffeescript ，所以我会考虑是否要在前端引入框架，但是做到后面，发现分离以后，后端无论用什么，都没有 rails 舒服。

但是回到队伍本身，有时候事情不是完全能按照自己的意愿去建立，在人员实际情况的限制下，前后端分离目前还是有一定的可取之处

[jarlyyn]

难道不是越是全端越是喜欢前后端分离么？

[Wangxf]

我是前后端分不分都无所谓，反正学点后端模版语言也没啥

[besteric]

@FrankFang128 嗯，变化挺快的，我们都已经经历了三次迭代升级了：）

[Wangxf]

不过楼主倒是说出了真相，国内有多少公司需要 react 呢？大部分业务 jquery ＋ template 足以，无非就是装逼显得自己很牛逼抬高门槛，我不是阴谋论，我就是前端，看到很多，比如新闻类的网站也装逼上 react ，知乎有阵子也特么上个 react ，神经病，现在是项目还没开始，先 react ， babel ， gulp ， webpack 全都搬出来了，好了，终于可以开始写 hello ， world 了，有意义么？不是说反对这些项目，而是没用到点，比如前端在线编辑器，管理后台重操作重数据编辑的用下 react ， vue 说提升效率我不反对，这个稍微了解下就知道，但是尼玛你一新闻网站，问答网站搞 react 不是装逼是干嘛？国内这风气，哎

[Wangxf]

不过全栈要求确实太高了，以现在创业公司体量，基本上是找不够人的，你说的是招软件工程师， web 工程师

[zanpen2000]

@superkey 对啊，一套服务对应多个产品，这样的例子太多了

[ExploreWay]

java 全栈开发的路过，目前进阶 node.js 开发

[DaraW]

感觉楼主说的和我所理解的不太一样。。。

个人认为前后端分离后，后端服务化，而不只是 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 本身正在借鉴已经成熟的平台 /产品，变得越来越完善。我的态度是在这股热流中，保持自己的见解，学习值得学习的东西，不去过度迷信工具。

[railgun]

其实就是前后端分离的架构并不适合楼主现在的业务，所以看不到好处，还带来了一堆问题。
我的观点是，前后端是否分离没有好坏，只有合不合适

[oscarzhao]

@jerray 确实。另外分离有利于保持 小团队运作，文档写清楚，不用天天开会讨论。 怎么感觉楼主在故意挣积分呢。。

[FrankFang128]

@oscarzhao 不分离一样要好好写文档，你看那些流行的 jQuery 插件，文档多好看啊

[FrankFang128]

@jerray 我说过啦，用 RESTful API 就能解决这个问题
安卓请求 json format ， Web 请求 HTML format

[jarlyyn]

@FrankFang128

为什么要

“安卓请求 json format ， Web 请求 HTML format ”？

难道 在某个语言的模板里写 html 会比直接写 Html 更舒服？

[andyL]

看过楼主的两个帖子，都有干货，是抱着讨论的目的来发帖的，这一点我很欣赏，赞一个。

不过我觉得这篇文章写得不太好，最起码应该先就什么是”前后端分离”达成一致。

看了大家的回复，结合我不多的开发经验，我觉得“分离”之后的模块化更容易理解和被工程使用。

图不错。

[FrankFang128]

@jarlyyn 因为按照 REST 的观念， JSON 和 HTML 只是两种展示方式而已，数据内容是一样的。

[FrankFang128]

@andyL 不分离也能模块化，只是面向全栈的 Web 框架不多而已。比如 meteor js 。
前后分离之后只是让「写出针对前端的框架」更容易而已。

[jarlyyn]

@FrankFang128

肯定不一样啊。

html 还包括 js,样式。

而且一个 html 未必只调用一个接口的数据。

[FrankFang128]

@jarlyyn 不包括 JS 的 HTML ， JS 是行为，不跟数据放在一起。
这个是「古代」 Web 开发的约定吧

[maxsec]

楼主~ 艹粉么~ 加个微信呗

[jarlyyn]

@FrankFang128

html 也不是数据。

你不在 html 中插入 /使用 js 的吗？

[damonzhaofei]

你做 webapp 也不搞分离，我给你点赞。。你们公司招的人都要全栈。你们老板有钱还是有耐心。。

[FrankFang128]

@damonzhaofei 彩程公司，你搜搜。

[wizardforcel]

其实我觉得纠结分不分离，还不如直接写写 ios/安卓，你不分离都不行。

浏览器端的乱象是必然的，因为框架要发展，但是 W3C 好像也不重视这个，所以各个流派就起来了。我前几年就预料到了这种情况，所以一开始就选择安卓，等浏览器端发展好了再回来看看。

[lixia625]

我觉得并不是会不会的问题，就算你是全栈，一个大项目一个人就是做不了（规模在那里），这个时候就需要分工，前后端分是一个相对较优的分工方式吧

[FrankFang128]

@lixia625 用现成的库或组件啊

[YvesX]

脱离了工程实际，这种问题只会变成宗教争论。
“前后端分离”看上去很正确。其实即使从整个社会的尺度来看，“专业化”也特别政治正确。
但这个正确是建立在复杂度的基础上的，不应该不加权衡地奉为圭臬。
遗憾的是，许多人深知缺乏规范的弊端，所以特别喜欢追求规范，以至于矫枉过正，特别热衷于信奉信条。
既然以解决问题为目的，应该少谈些主义。

[xieguanglei]

求作图的软件

[FrankFang128]

@xieguanglei balsamiq 加 hanzipen 字体

[zhibushiwo]

看各位大大讲感觉好厉害的样子

[JamesRuan]

我玩前端两个月的时候，打算重写一个每日 IP 量四位数论坛，用的设计就是前后端分离（ REST+Angular ），前端工程化方案，甚至连 Node.js 中间层都有考虑在扩展方案里面。这个项目想找人一起做，多半是因为我是学医学的，一直找不到能合作的人。
后来自己忙了，再加上 Angular 出了 2 有些犹豫，就一直搁置在那里。

当时还和某刚入职美团的前端妹子讨论这套方案来着，直到一年后，突然发现阿里那群人怎么弄的东西和我想得一样……

[jayyjh]

前后端不分离写起来实在是累，又不是人人都是全栈

[8e47e42]

楼主，我就在国外，大公司不用说了，小公司不单搞分离，而且搞的比国内还明确，归根结底是人工费用高要外包给不同的人，不分离以后怎么维护？

[metrue]

除了刚开工作的时候使用 Rails 全栈之外，之后的所有的项目都是前后端分离，而且个人项目也一直前后端分离。

[Kevinww]

开始学写后端了？

[NullMan]

我觉得楼主说得很有道理, 前端单纯用 HTML + CSS + jQuery 一样能做复杂的业务.

[sigmadg]

还有一条，前后端分离对 SEO 并不友好。
不过 在企业开发领域，前后端是很有必要分离的

[pandachow]

这不是显然么……如果一个人都会了，当然就不分最好。。。

最好还是前端，后端，算法，设计全包了。。。

问题难道不是因为实在是这样招不到人，于是得想办法拆开啊。。。

[lfyzjck]

前后端分离的意义除了能处理更复杂的交互以外，更大的意义来自协作效率的提升。

事实上规模稍大的公司，前后端都是独立的人负责的。要让前端理解后端的架构，让后端更写出性能好又没有 BUG 前端页面，这提高了双方的学习成本。 OK ，你们公司运气比较好，找到了 2 个全栈工程师，前后端都牛逼，那么某天其中一个人离职了，你的公司可以承受这样的风险嘛？无论怎么推崇全栈工程师，真正面向用户的产品，最终会回归到前后端独立工作的局面。而这种人员架构的分离，才最终导向了前后端分离的架构。

具体不分离的时候有多坑，有经验的都体验过，不多说了。

[MinonHeart]

前后端分离是次要的。初期的架构设计太重要了，设计的烂，中后期各种坑，各种重构

[Actrace]

作为一个长达 6 年的全栈工程师兼架构师，我说一下我的观点。
经手了很多项目后发现，一些稍大的项目（至少 4 人配合），前后端完全分离具备一定的意义，在磨合较好的团队中施行这套策略，可以很好地提升开发效率。不过前提是你能把握住局面，也就是清楚的知道各个部分的衔接，前后端彻底分离开后需要一个人来控制总体结构，才能保质保量。那么实质上考验的是负责衔接的那个人。

不过大多数创业项目可能在初期并没有那么多人负责开发，顶多一个人两个人，那么这个时候其实也可以做到前后端完全分离，怎么做呢？那就是预留。
把接口预留好，这样后端在做前端的时候使用接口（虽然还是用 PHP 之类的后端语言构建前端页面），等队伍壮大后，前端独立出来，这套接口还是可以继续用的。

稍微有进展的公司，项目都会从单纯的 web 扩展到移动客户端甚至是桌面客户端，前后端完全分离还是有一定的意义的，只不过过程可能是极其缓慢的，正如你考虑的那样，一开始就做前后端完全分离是不理智的，不过适当的预留也可以避免项目扩大后的重构危机（假如有机会）。

至于个人玩的项目，我推崇楼主的观点。

[bk201]

后端那么好做？后端的学问很稳定，不像前端五花八门，但是知识面之广，做前端的小瞧了点吧.说实话，我觉得前端玩的一些概念后端早就有了.

[boogiefer]

后台服务要服务化，满足多平台接入，例如移动端， web 端，第三方等。
前台要组建化，统一体验，对用户友好。

还没说可用性和安全性，这就是分工的意义，最终保障的产品质量和服务质量。

楼主应该是想表达个人能力，技术的发展宽度，而非组织架构团队分工的问题。

[hasbug]

问题是，不是人人都和楼主一样有能力啊，能前后通吃。

[FrankFang128]

@hasbug 你有没有想过，是因为我们用的框架，不前后通吃。而不是因为人。

[specialized]

@urtrcc 说就说，不说就不说，呵呵个***玩意啊。估计你属于有技术那种，但无奈语文体育老师教的……组织不起来！

[luoway]

我的前端团队的主要 Leader 就在上周提出了前后端不分离的想法，不过后端是用 nodejs 。讨论的结果是接下来的一个项目按页面而不是按功能分，要什么接口自己写。这样可以生产高聚合的程序，忽略适用性和可维护性，以提高效率。 Leader 自己也说这样做适合初创团队，适合小团队，有益于团队成员的成长，而不是在自己擅长的领域固步自封难以提升。与楼主不谋而合。

[liujin834]

大公司我不知道，小团队来说前后端还是要分离的，后端 API ，前端完全独立一个项目是目前我们团队的状态，这样对每个人的要求都很高，但是业务逻辑十分清晰，每个人拉出来都能顶住一方面业务，还可以交换着做，很好。我们后端是 nodejs + python ，前端 angularjs 单页应用，后端是由好几个 git 项目组成的， API 同时面向 web 和 app ， web 前端也有独立的 git 项目，团队里每个人都是从 php ， nodejs ， python ， ruby ， java 到 jquery ， angularjs 都能写，数据库也是 pgsql, mongodb, mysql(极少)混杂，对这些全盏工程师来说要从业务到架构都分离，我们连模板引擎 ejs 和 jade 都省了，全部都是轻装上阵。

[orvice]

看情况吧，我们分离就有好处：
* 后端写一套 api 给 web/app 通用
* 后端写测试也方便

[incompatible]

作为后端开发，我觉得前后端分离蛮好的，后端专心做逻辑就好，不用操心前端这种复杂的东西。专业的事情就交给专业的前端工程师们搞就好了。
至于全栈，我若是有学会前端从而成为全栈工程师这个闲工夫，我宁愿多写几个 testcase 提升一下后端代码的质量。

[FrankFang128]

@orvice 不分离也能做到……请看 Rails
现在测试做得做好的社区就是 Rails 社区吧。

[NekoTora]

从我开始写第一行 html 开始，我一直以为凭着一个 chrome 和一个记事本我就能做一个“优雅”的前端……
直到有一天，他们开始逼我用这些前端工具……

[binux]

「一个人能做的事情变成需要两个人做了」
并没有，原来 20 个人做的事，并不是变成需要 40 人做了，而是其中 10 人做后端， 10 人做前端了。总人数并没有变啊。
而且作为后端，前端那些活我压根不想做好吧！

[majik]

前后端分离一方面 web 、 app 可以复用同一个服务器，使用同一套逻辑，降低维护成本；另一方面可以将渲染的计算压力丢给客户端，降低成本，前端直接使用静态文件维护起来也方便，还能提升用户体验。

如果你看过 openstack horizon 那套渣渲染设计，就该庆幸前后端分离。

我司就是全栈开发，照样前后端分离，一样搓的比原来爽。