推荐关注 Meteor JSLint - a Javascript code quality tool jsFiddle D3.js WebStorm 推荐书目 Javascript 权威指南第 5 版
Closure: The Definitive Guide
Closure: The Definitive Guide 
这是一个创建于 3398 天前的主题，其中的信息可能已经有所发展或是发生改变。
原文在 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
 | 1 8023 2016-08-09 07:28:59 +08:00 via Android oh 找到同类了... 前些天还在跟同学吵吵这事儿... |
 | 2 passion336699 2016-08-09 07:36:06 +08:00 via Android 分离之后，感觉前端框架，工具等东西上手的周期太长了 |
 | 3 xujif 2016-08-09 07:36:51 +08:00 via iPhone  4 用楼主的腹黑逻辑，这个肯定是担心被抢饭碗的后端。 后端只提供 api ，关心数据结构，不知多开心。 |
 | 4 genffy 2016-08-09 07:39:37 +08:00 3 1. 有个重要的消耗，且还是非常严重的你没考虑到（尤其是移动端），那就是 http 。如果你的测试仅在于 127.0.0.1 或者内网，那没啥说的； 2. 存在即合理； 3. 前端没有自 high ，也是被逼的； 4. 前后端分离的主要目的是解耦，保持简单，术业有专攻。 至于你说的前端话语权啥，前端不得志才搞前后端分离啥的，只能呵呵 |
 | 5 loading 2016-08-09 07:42:14 +08:00 via Android 1 不是所有人都能做全端的，楼主放心。 |
 | 6 FrankFang128 OP 1 @genffy 我搜了下通篇没有『测试』两个字。 合理不代表正确。 解耦？以前也没有耦合呀。看看 amazon.com ，禁用 JS 页面都能正常运行，这才是解耦。 |
| 7 FrankFang128 OP @loading 我现在公司的每个人都是全端 |
| 8 FrankFang128 OP @xujif 没说后端不开心啊。一件事分给两个人做，两人当然开心，都只做一半。 |
 | 9 wizardforcel 2016-08-09 07:58:56 +08:00 via Android html 页面的本质是应用， dom 的本质是控件，偏要当成文档来处理，这就是最大的问题。 我不知道你接触没接触过安卓。安卓的布局 xml 里面可以包含别的 xml ， java 代码中可以直接 inflate xml 生成控件，也可以把 xml 封装成自定义控件。鉴于浏览器的这个德性，这些想做的话，要么手写，要么用框架。 |
| 10 FrankFang128 OP 1 @genffy 测了下，现在的亚马逊禁用 JS 不能用了…… 去年牛逼呀，禁用了 JS 还能用 |
| 11 genffy 2016-08-09 08:02:13 +08:00 2 @FrankFang128 ，我的意思的你压根就没考虑 http 的事，就出来 BB 。 |
| 12 FrankFang128 OP @wizardforcel Web Component 是可以做到这样的，一个自定义标签就是一个控件，不过现在还没有普及。先尴尬着用 React 的方案吧…… |
 | 13 sohu022 2016-08-09 08:03:12 +08:00 via Android 只想说没人逼着你前后端分离，不喜勿用! 如果连用不用的话语权都没有，那来这里抱怨也无济于事，该跳槽就跳槽，该转行就转行！ |
| 14 FrankFang128 OP @genffy HTTP 的哪件事？ Web 少不了 HTTP ，跟前后端分离没关系，不管分离不分离， HTTP 该优化的还得优化。所以我的文章就不说这个了。 |
| 15 FrankFang128 OP @sohu022 现在明明是『不要前后端分离』一方的话语权较弱。 |
 | 16 murmur 2016-08-09 08:05:29 +08:00 1 前后端分离有个好处，就是这些接口基本不用改就可以拿给 APP 用，你的数据如果全用后端渲染，到移动端甚至 web 端，你还单独出一套代码？ |
 | 17 kindjeff 2016-08-09 08:10:14 +08:00 via iPhone 经验不多，我个人感受，后端只提供 api ，前端负责渲染，不考虑 seo ，代码明显更好写了，逻辑更清晰。在后端的模板渲染 html 甚至是字符串拼接，还需要后端来考虑应该有哪些 html 结构的页面，结构应该是什么样的。 |
 | 18 FrankFang128 OP @murmur 这个点说得好。 1. 不用 JSON 接口依然可以做移动端。比如 Rails 的 Turbolinks 工具。 2. 一个数据接口有两个展示形态（ JSON 和 HTML ）是很容易做到的，没必要限定只做 JSON API 。 比如 /data 接口有两种形态： /data.html 和 /data.json ，移动端用 /data.json ， Web 端用 /data.html |
| 19 FrankFang128 OP @kindjeff 如果后端也是你写的，你就不这么认为了。 |
 | 20 noli 2016-08-09 08:20:11 +08:00 via iPhone 2 我发现声称不喜欢前后端分离的人，大多数是做 web 开发的。只能说，浏览器和 nodejs 给了你们迷之自信。 |
 | 21 dazui 2016-08-09 08:20:31 +08:00 1 鸡蛋不要放在一个篮子里，分而治之是 web 开发一直以来的趋势，分层的目的是降低耦合，提高抽象。 |
| 22 FrankFang128 OP @noli 我是纯前端…… |
| 23 FrankFang128 OP @dazui 以前并没有耦合。哪里耦合了？ |
| 24 FrankFang128 OP @dazui 现在 React 把 HTML 和 CSS 写在 JS 里，才是耦合，哈哈。 |
 | 25 adv007 2016-08-09 08:29:05 +08:00 via iPhone 1 楼主的言论就是停留在猜测，一点点优化打开 qzone 的速度，你认为真有那么多后端愿意搞？推 cdn 你以为是后端发起？首屏域名收归你以为后端愿意搞？ |
| 26 FrankFang128 OP @adv007 你用业务说话就对了，确实腾讯前端唯一一个前端架构师出自 QZone 。 不过你又反面支持了我的观点：分了前后端之后，后端不愿意管前端的杂事（推诿） 这个论据也正好说明，前端想晋升，必须从后端手里抢资源控制权（比如 CDN 、 DNS 、服务器） |
| 27 FrankFang128 OP @adv007 我不是猜测啊，你这个例子我本来想作为**我的论据**的，但是想到当事人大家都知道，就没说了。 前后端造成的问题，最后用『统一前后端 /全栈』来解决，这就是我的论点啊。 |
| 28 FrankFang128 OP 前后端分离造成的问题 |
| 29 noli 2016-08-09 08:34:57 +08:00 via iPhone @FrankFang128 你以前没有用过远古时代的 asp jsp 这类已经淘汰的技术，所以你觉得以前也没有耦合过。 |
 | 30 hanxiV2EX 2016-08-09 08:35:24 +08:00 via iPhone 我的观点:即使不前后端分离，也要数据和渲染分离。我是支持前后端分离的。支持 js 的浏览器就把渲染放前端，不支持的就请求服务器渲染好了再发 html css 过来。这样哪天要把网站做成 app 也就是改客户端，没服务器啥事。 |
 | 31 newghost 2016-08-09 08:37:19 +08:00 楼主字写得很有个性…… |
| 32 FrankFang128 OP @noli 有些人非要把 jsp 代码跟 JS 混合起来，那是那个人的错误。将后台数据统一放到一个地方，然后用 JS 去取，就解耦了。 所以还是人的水平的问题。 现在 React 的耦合成都令人咋舌。你想把 HTML 、 JS 和数据分离几乎不可能。 |
| 33 noli 2016-08-09 08:38:15 +08:00 via iPhone @FrankFang128 请问前端有什么本事从后端手里抢资源？先学会负载均衡，微服务，冗余服务等等的技术再说吧。当然做，小网站可以当我放屁，爱咋弄都行 |
| 34 FrankFang128 OP @hanxiV2EX 我不支持客户端渲染……客户端渲染问题太多：异步、状态维护、内存爆炸…… |
| 35 FrankFang128 OP @noli 所以目前为止，只抢了 HTML 渲染权，其他都搞不定。 |
| 36 FrankFang128 OP @noli 我倾向于消灭前后端的区别，人人做全栈（理想化了点） |
| 37 FrankFang128 OP @noli 不过 QZone 的前端，全部都抢到了，连 Nginx 都由前端 Node.js 代替了。 |
 | 38 cccRaim 2016-08-09 08:43:01 +08:00 楼主的后端其实是我们口中的前端，真正的后端根本不处理 HTML 这类小事 |
| 39 noli 2016-08-09 08:43:41 +08:00 via iPhone @FrankFang128 天真，想太多动手太少了。 jsp asp 之类的问题根本不是什么你说的把 js 混杂在 asp jsp 代码之间，而是服务端直接输出 html tag 导致页面设计改动影响太大。 你真要试试资源都用 js 加载，你就知道页面显示有多慢了 |
| 40 FrankFang128 OP @cccRaim 你说的是数据服务后端吧。 你的意思其实也是全栈的意思，只不过是让前端做全栈，吃掉以前的后端，让以前的后端没饭吃。 |
 | 41 likezun 2016-08-09 08:44:55 +08:00 我同意楼主的观点！ |
| 42 FrankFang128 OP |
 | 43 stackboom 2016-08-09 08:47:35 +08:00 前后端分离不是阿里炒出来的嘛， 不是因为阿里前端写 PHP 性能差才转 Nodejs |
| 44 FrankFang128 OP @stackboom 你哪听来的？阿里明明只写 Java |
| 45 noli 2016-08-09 08:51:58 +08:00 via iPhone @FrankFang128 你说这个话说明你根本不知道 nginx 在大站中的作用是什么。当然，我也不认为，用 nodejs 取代了 nginx 就能说明什么前后端不分离。 |
| 46 FrankFang128 OP @noli 确实没关系，这只是一个小故事…… |
 | 47 bmy 2016-08-09 08:55:40 +08:00 it depends |
 | 48 gamexg 2016-08-09 08:56:56 +08:00 我只说全栈太难了，很少有人能够前端后端都搞好。 另外个人是觉得 nodejs 火起来很奇怪，之前为了使用 socket.io 用了一下，觉得完全是回调地狱。 异步回调其他语言很早就有了，现在其他语言都已经开始推进到了多线程阻塞语言自动转换成为异步协程方式了(python+gevent 、 go)。但异步回调却是 nodejs 宣传的重点。 另外听说 js 也新增了原生异步语法能够解决回调地狱，不过没在接触。 |
 | 49 shyling 2016-08-09 08:57:00 +08:00 via iPad 大概是因为 webapp 的流行吧。。 |
| 50 FrankFang128 OP @gamexg Node.js 语法层面的难用还不算什么，更坑的是没有成熟的解决方案，你做任何一个功能，都要去 npm 里面找库，找到了再拼起来。而且每个人都说自己的库好用。 |
 | 51 zoues 2016-08-09 08:59:06 +08:00 via iPhone @FrankFang128 那我感觉你的理想挺蠢的 |
| 52 FrankFang128 OP @shyling 除了在线 IDE 、在线游戏做成 web app 我没意见，我没看出大多数网站做成 web app 是为了什么。 |
| 53 FrankFang128 OP @zoues 你是本帖第一个人参攻击的。 |
| 54 stackboom 2016-08-09 09:03:01 +08:00 |
| 55 noli 2016-08-09 09:03:18 +08:00 via iPhone @FrankFang128 partial view 也还是耦合太大，你试试做同时支持，移动端，浏览器，还有瘦客户端上的 web group chat ，我想你就知道前后端分离的好处了。 |
| 56 FrankFang128 OP @newghost 字不是我写的，是 HanziPen SC 字体 |
 | 57 killerv 2016-08-09 09:03:53 +08:00 个人觉得应该分离，术业专攻，真正的全栈工程师毕竟不是那么多…… |
| 58 murmur 2016-08-09 09:04:05 +08:00 1 @FrankFang128 为了使用新技术而使用新技术 现在的网站 应用都在炫技 真正有用的功能 能解决到用户痛点的是越来越少 说句不好听的 现在随便抓个 APP/网站 砍掉 50%+的东西 bug 少了 更清凉了 用户用着也舒服了 就是产品经理不爽了 |
 | 59 dbfox 2016-08-09 09:04:13 +08:00 via iPhone 总之工作好做就行 |
 | 60 xchange 2016-08-09 09:04:22 +08:00 前端就是事儿多，都是闲的慌 |
| 61 FrankFang128 OP @noli 用 RESTful 结构的话，不存在问题啊 /data API 分成 /data.json 和 /data.html 两种形式就好，移动端只用 /data.json 就好啦。（当然某种意义上这就是前后分离） |
| 62 FrankFang128 OP @murmur 我觉得是的，不然我真的无法理解那些吵着用 React 的人是怎么想的。 |
| 63 genffy 2016-08-09 09:06:32 +08:00 via iPhone @FrankFang128 要跳槽么？来么？ |
| 64 FrankFang128 OP @xchange 对，除了做页面，得找点事情折腾折腾才好。 |
 | 65 ChiangDi 2016-08-09 09:08:31 +08:00 via Android 我们公司前后端分离没有 node 做中间层 |
| 66 FrankFang128 OP @ChiangDi 那应该是图二吧？用 JS 做渲染。 |
 | 67 mdluo 2016-08-09 09:10:40 +08:00 Rails 的 turbolink 不就是残废版的 virtual DOM 吗 Rails 确实很优秀，但是也确实很老了，至少在处理前端方面 还以为在前端技术里就 Vue 和 React 能互喷，没想到 Rails 居然也能 |
 | 68 just4test 2016-08-09 09:11:08 +08:00 为什么我不喜欢 mvc 架构，明明只用 jsp 就能搞定一切的 |
 | 69 mazyi PRO HTML 是什么？我只关心数据。 后端的逻辑为什么不分离？和前端一起画画？ 并且呀，前端学了那么久了，早就该开始写后端了嘛， nodejs 不是很火嘛~ |
 | 70 Phariel 2016-08-09 09:12:01 +08:00 via Android 1 我所见过的全栈 前端代码根本不行 都是拿后端思维在搞 术业有专攻 前端还要考虑渲染交互浏览器优化等等很多事情 前后不分离的时代又不是没有过 Dreamweaver 各种 IDE 级的绑定我就在写 .net 还是 2.0 的时代我就在写 最后感觉都不靠谱 直到前端这个专业分工出现我才觉得 WEB 开发有希望了 |
 | 71 XueSeason 2016-08-09 09:12:39 +08:00 非常喜欢楼主的几篇有个人见解性质的文章，从批判的角度看前端，给人更多的思考。 |
 | 72 xiaonengshou 2016-08-09 09:14:28 +08:00 做 web app 就前后端分离，不是就后端渲染。看产品需求咯。 |
| 73 FrankFang128 OP @mdluo Virtual DOM 不就是残废版的游戏渲染器吗？ 这种话语没有实质的意义，我认为 Virtual DOM 是在炫技，对业务没有很大提升。当然如果你的业务一秒钟操作 DOM 100 次， Virtual DOM 还是有意义的。 我把所有前端渲染的框架一起喷。 |
| 74 FrankFang128 OP @xiaonengshou 相信我，大部分项目都应该后端渲染。除了我上面列举的在线 IDE 和在线游戏不能后端渲染。 |
 | 75 Felldeadbird 2016-08-09 09:17:40 +08:00 前后分离 多了中间层去处理后端的数据，其实真的很不优雅。不过在现在讲求 分布式业务下，这点性能损失也是可以容忍的。 /td> 只要业务大了，后端肯定需要和前端分离的。否则多端开发的时候，后端都要写一次，很辛苦的。 |
| 76 noli 2016-08-09 09:17:56 +08:00 via iPhone @FrankFang128 所以你也知道了，前后端分离几乎是必然的。事实上除了 web 相关开发，我没发现哪里不是前后端分离的。当然我也觉得全栈的理念很合理，只是目前全栈的工具链发展得还不是很完善。然而全栈也是应该支持前后端分离的思想的。 |
 | 77 marvinwilliam 2016-08-09 09:18:10 +08:00 你觉得都愿意这样么?你在大公司呆久了没啥,人家业务多,分离可能会比较和你,但是你去过小公司么,你知道有一部分的小公司的后端有多水么?前端的东西是完全不会写,人家 HR 也是没有办法才要求招的前端,这些后端当然喜欢分离了啊,毕竟自己工作就少了啊. |
| 78 mdluo 2016-08-09 09:18:49 +08:00 1 @FrankFang128 说 webapp 没场景，举个例， QQ 空间要不要滚动无限加载，要不要动态更新回复要不要动态通知，微博知乎同理。用 React 来做就是分拆分拆组件， redux 绑定好数据，组件内部状态跟界面绑定好，分分钟搞定。用传统方法做，要判断多少条件？ |
 | 79 deadEgg 2016-08-09 09:21:09 +08:00 1 支持楼主 , 一切为了开发效率 大公司前后端分离是为了开发效率以及分工明细， 小团队前提倡敏捷开发,没必要太过的提倡前端的复杂度 |
| 80 FrankFang128 OP @mdluo 我认为像 Vue 和 React 这么重的前端，是没有必要的。我认为前端应该不要再在「 JS 统一宇宙」的路上深陷下去了。 现在 CSS 用 JS 写 HTML 用 JS 写 服务端渲染用 JS 写 DOM 被 JS Virtual DOM 取代 Web Components 被 JS 框架取代 SEO 不要了 不用 GulpJS 开一个 Watcher 都不能开发啦 |
| 82 FrankFang128 OP @noli 你要给安卓 iOS 提供数据接口那分离肯定是必然的，不过现在的趋势是在 app 直接展示页面，所以不分离的情况也很多。 |
| 83 FrankFang128 OP @mdluo jQuery 做个无限滚动好简单…… |
 | 84 zongwan 2016-08-09 09:24:40 +08:00 记得最后次谈到这个问题的时候说的是 API 是否可以共享给第三方 搞后端有一段时间了，前端和 node 相关的那套还什么都不懂。。。 附近也没 node 工程师，除了资深 java 就是应届毕业生。。。前后端分不分也还是得看环境。。。 负责的项目反正一个人做，爱咋咋地。。。 |
| 85 FrankFang128 OP @mdluo 你说的这些功能，确实适合做成 web app 的，那么用 React 我没意见。 |
 | 86 SourceMan 2016-08-09 09:25:44 +08:00 前后端分离： JS + Java （ node.js ）前端 C 后端 我们现在的情况，挺好的 |
 | 87 kalman03 2016-08-09 09:26:06 +08:00 楼主你好，我司坚决不玩前后端分离，你若乐意，来我司搞个完美的搭配吗？ |
 | 88 feilaoda 2016-08-09 09:26:49 +08:00 1 分离后，反正现在就是出活比较慢 |
 | 89 czheo 2016-08-09 09:28:10 +08:00 2 1. 全端工程师贵且少。 2. 你让一个工程师从 Hadoop 一直写到 CSS ，很难精益求精，况且很多人也不愿意学的这么杂，员工难免抵触。 3. 当手机， web 甚至桌面至少两三套前端代码，前后分离是很自然的选择。 4. 你的经验谈可能来自你最近创业经验，小公司一锅端有利于用最少投入快速开发。但后期随着逻辑越来越复杂，做的优化越来越细小，投入的码农越来越多，分离也是水到渠成的。br />规模不太大的项目不分离也挺好的， ror 就是这哲学。总之，这是一个 tradeoff ，分与不分各有利弊。 |
 | 90 guyskk 2016-08-09 09:28:20 +08:00 via Android 我是后端，我很喜欢前后端分离。分工明确啊，后端可以多花心思在优化性能，完善测试，提高安全性这些问题上，前端就多花心思研究交互，还有浏览器的兼容问题等等。术业有专攻。 |
 | 91 yimity 2016-08-09 09:29:04 +08:00 适合的地方不一样。不过也有几分道理。不是所有的都适合前后端分离。 |
| 92 dazui 2016-08-09 09:29:49 +08:00 @FrankFang128 比如前后端不解耦的情况下，前端搞了很多用户体验方面的功能，这部分工作后端服务完全不关心，但这些功能必须要在 jsp 里渲染才能呈现，而 jsp 跟后端 service 还不能分开开发，所以后端开发既要是个粗壮的能做饭的大厨，同时还要是个漂亮的能传菜的小妹，这种情况真不好协调。 |
 | 93 nikymaco 2016-08-09 09:30:17 +08:00 呵呵，说得挺好的。虽说是吐槽，但是不经意间道出了前后分离的意义。 |
 | 94 viko16 2016-08-09 09:34:04 +08:00 1. 各司其职挺好的 2. 全端工程师又不是全干工程师  |
 | 95 tairan2006 2016-08-09 09:34:57 +08:00 后端的任务本来就是数据结构，性能这些东西。小公司后端还要兼职运维、数据统计。 前端不仅仅指 web ，其实安卓、 iOS 客户端这些都是前端。况且还有 React Native 这种跨平台的思路。 前后端解决的问题核心完全不一样，我赞同前后端分离。当然有些内部用的小项目，一个人完成的话，没必要。 |
 | 96 ibudao 2016-08-09 09:36:40 +08:00 渲染是有 CPU 和内存开销的，在大量渲染场景中，你觉得这个开销是放在服务端自己维护，还是利用现在越来越高性能的终端设备呢？ |
 | 97 mengzhuo 2016-08-09 09:39:51 +08:00 楼上的喷点不对啊。 人家 LZ 说的是反对前后端分离中的 Nodejs 把前端渲染又做了一遍。 |
 | 98 buckyRRRR 2016-08-09 09:41:39 +08:00 via iPhone 这个话题这么火 |
 | 99 chaleaoch 2016-08-09 09:45:32 +08:00 牛逼，帮你顶一下。 我的一个同事和楼主的思路差不多。 而我的思路和楼主的正好相反，我想尝试前后端分离（我所在项目一共两个人）。 看了楼主的文章，看来我要好好反省以下了。 |
 | 100 zlgodpig 2016-08-09 09:49:18 +08:00 1 按照前端出静态页面的开发模式，后端其实分偏后后端和偏前后端，偏前的需要去套页面，所以从工种上，偏前的后端的一部分工作被 node 替换，其实变化不大。 前端和后端的工程性质不一样，后端要稳，前端要酷炫点并且快速迭代。所以两端放在一起管理，发布的频次，稳定性的要求都不一样。 另外前端出来 bug 怎么办？后端来修前端 bug ，对后端要求也太高，前端来修，后端要之前待命，等前端修好，然后去发布吗？ 除了首屏 html ，前端 ajax 的请求越来越多，开发时，前端需要的数据哪里来。后端可能还没开发好；开发好了，前端起后端服务，起个 java 工程，起得你想哭。 前端工程独立管理是必须的。（如果这点，你不同意，其实就什么好说的了 所以如果是后端只提供 api ，前端 ajax 后，第二屏在渲染页面，后端开发就舒服多了，两端各自管理自己的东西，这个工程上好管理，个人觉得开发效率也高。 但是这种方式有它的适应场景： seo 不好处理；一下精细化的控制不好做，比如针对不同的用户，输出不同的静态文件。所以有些地方加 node 也是 ok 的。 加了 node ，可以做 api 的合并，这个 app 端也可以用，一些简单的验证和分流，还有页面静态化等。 所以还是按工程规范，人员水平，这种分离都算是对现在情况的一种回应，最后 KPI 也是现在情况的一个部分 |
Select Language