推荐关注
› 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
 |
301
likezun 2016-08-10 08:40:38 +08:00
楼主说的对啊
|
|
302
likezun 2016-08-10 08:41:02 +08:00
楼主说的是对的
|
 |
303
xiaoshenke 2016-08-10 08:45:05 +08:00 via Android
围观
|
 |
305
hhacker 2016-08-10 08:58:34 +08:00
社会分工的明确化，在网页程序员的时代，是没有这种东西的。。。
|
 |
306
arzusyume 2016-08-10 09:15:56 +08:00  7
评论 TLNR, 针对原文吐槽下...
1. 让问题复杂化 恰恰相反, 前后端分离之后把一群乱七八糟的东西分离开了, 并保证了在一定程度内不会变回乱七八糟的状态 2. 很容易出现各自为政的情况 不是很懂你们 BAT 3. 又学后端又学前端 其实这点并不是前后端分离的理由, 从来都不是. 过去的开发流程通常是切图人员提供了纯 html 的设计图, 由程序员丢进模板里嵌入数据(从楼主的工作经历看应该经过了这个时代). 现在只不过让过去的切图仔(前端))能做更多的事情, (后端))程序员能更专注的取做页面无关的事情... 而且这在 LZ 眼中做更多的工作就是争权夺势的行为么, 想必 LZ 是个很勤奋的人 w 3.2. 不要搞什么 Angular 、 React 。用原生 JS 或者 jQuery 能满足大部分网站 之类于不要搞什么 MVC, OOP, 用原生流水线能满足大部分网站后端 4. 小公司别搞前后端分离 恰恰相反, 越小的公司技术管理和架构越容易混乱(我知道有很多反例), 分离一是可以让整个架构不会乱成一团, 另一方面也更好的应对频繁的需求变更 5. 前端也要学后端知识 就如同程序员也要了解一定程度的数学知识. (虽然我认识的许多敲键盘的连矩阵运算都不会...) 但是技术发展始终趋向复杂化, 前端还是更应该专注前端技术的变革 关于你没有提到的 1. 构建 修改一个 html 可能需要重新构建一个 jar 包, 同理一个简单的页面 hot fix, 可能要发布整个服务 2. 测试 基于接口的测试是黑盒且更容易拆卸 3. 复用与开源社区 组件复用与共享不依赖后台架构 4. 成本的转移 不用前后端分离无非是使用别的方式去解决架构的各种问题而已. 最后, 并不是 angular 跟 react 让前端变得复杂, 而是复杂的前端需求诞生了 angular 和 react |
 |
307
Mark24 2016-08-10 09:24:17 +08:00 1
我喜欢全栈。前后端分离，沟通成本好高
|
 |
308
theJian 2016-08-10 09:41:41 +08:00
TL;NR
|
 |
309
Durandal01 2016-08-10 09:42:35 +08:00
楼主你根本没考虑过应用会跨平台吗？
前后端分离的背景是 Native App 兴起，为了让一个后端可以服务于多个客户端，为了让 Web 开发和 Native 开发从形式上更接近啦。 |
 |
310
FrankFang128 OP @Durandal01 没学过 RESTful 吗
|
 |
311
frjalex 2016-08-10 09:48:48 +08:00
楼主你没考虑过性能问题吗？用服务器端做 REST API + 客户端渲染会比一般的纯服务端快速不少，这是趋势啊
|
 |
312
jiujianlu 2016-08-10 09:49:41 +08:00
现在的前后端分离，最大的好处就是接口复用。
比如你的产品有 Android/iOS 端，这时候就可以与 Web 端共用同一套接口。 再说了，谁说前后端分离后必须要两个人做的？放开她，让我来！ |
|
313
FrankFang128 OP @jiujianlu 谁告诉你分离了才能复用接口
|
|
314
FrankFang128 OP @frjalex 谁说会快不少，快还是慢不一定的。
|
|
315
FrankFang128 OP @frjalex RESTful 不是只能做 API 的
|
 |
316
orvice 2016-08-10 10:21:18 +08:00
|
 |
317
lk920724 2016-08-10 10:25:09 +08:00
新的角度看待问题，主题确实不错。
不过我个人认为还是分离比较好，可能是因为做移动端的缘故吧。还有一点，你所说的全栈挺理想化的，就算全栈也会偏科。更极端的情况公司花了大笔钱请了一位全栈，全栈工程师离职后谁来维护呢？（毕竟后端或前端的人比招全栈的好招。）这是我从公司的焦点的一点看法。 |
 |
318
jy02534655 2016-08-10 10:26:15 +08:00
呃，感觉楼主完全把 css 这一块给遗忘了呀，前端除了 js 还有 css 呀。感觉楼主是在吐槽 node.js 呀， php 、.net 、 java 这些都被遗忘了吗。
前后端是否分离还是要看具体业务吧，不能一概而论。 简单的小网站啥的说实话直接 php 就能搞了，复杂的项目肯定前后端分类比较好咯。 平时我也接接外包什么的，要干时间肯定不能一个人把前后端都做了吧，所以前后端分离了有助于开发。 我现在主要做前端，公司的项目我也不管后端哪些鸟事，不明白楼主怎么就上升到权力斗争高度了，作为一个懒人，我才懒得理哪些鸟事。 话说以前前端没地位是真的，我最开始是做.net 的，那时侯用.net 开发网站简直是作死呀，就算是小网站，自己看着代码都有想作死的感觉。从技术层面来说，前后端分离应该是好的。前端懂服务端懂数据库这些也是不错的，至少和服务端沟通交流不会有问题 |
|
319
jy02534655 2016-08-10 10:27:35 +08:00
呃，前端还有 html ，其实前端工作量也不小了。你叫服务端来写会让他吐血的
|
 |
320
geek123 2016-08-10 10:31:25 +08:00
@FrankFang128 这篇文章能转载不？
|
|
321
Durandal01 2016-08-10 10:35:19 +08:00
@FrankFang128 典型的 Native App 都是客户端渲染的，这和你用不用 HTTP 协议，或者是不是 RESTFul 架构都没关系。
既然要支持客户端渲染，那就干脆全都变成客户端渲染呗。 另外，“全栈”是指工程师，全栈工程师也可以写“前后端分离”的应用啊。 |
 |
322
iversong 2016-08-10 10:36:52 +08:00
我是后端，我司的前端工作都是后端在做，未分离和分离的项目都在做。
为了更好的分治和协同工作，目前在做工程化和组件化方面的工作，这套东西适用所有项目，无论分离还是未分离。当然了，未分离的后端模板针对开发还是做了项目结构上的分离，目的是为了让新人前端更好的上手。 个人感觉： 不分离：认同作者说的好处，同时多快好省，节省更多的沟通时间。 分离：更加分治，让前端伙伴更容易上手，更专注前端。最重要的是我们很难招到懂点后端的前端，太难了！！ |
 |
323
xi2008wang 2016-08-10 10:43:10 +08:00
楼主从前端转全栈，就不管前端同学的死活了。。。。
|
 |
324
quix 2016-08-10 10:53:31 +08:00
万事都要看情况的...
但不得不说,很多情况下,前后端不分离的交互模式是非常低效的,很可能仅仅为了变更一个视图状态就要多产生好几次渲染和通讯 |
|
325
FrankFang128 OP @xi2008wang 因果倒了，是看前端看不懂，才跑去学后端的。
|
|
326
FrankFang128 OP @iversong 这个中肯。分离唯一的好处就是招聘
|
 |
327
professorz 2016-08-10 11:01:01 +08:00
web 开发本来就是做一件事情，分离和不分离都有各自的好处，疯狂推崇服务器端渲染和疯狂推崇前后端分离就是两个极端。全栈工程师应该是 web 开发的前进方向。
|
|
328
FrankFang128 OP @professorz 但是讨论问题必须要有明确的偏好才行。
|
|
329
FrankFang128 OP @quix React 解决的不就是视图被频繁渲染的问题吗？说明分离之后，多次渲染问题依然存在，没有得到解决。
|
|
330
jiujianlu 2016-08-10 11:16:01 +08:00
举个例子呢？
|
|
331
quix 2016-08-10 11:17:18 +08:00
@FrankFang128 然而网络通讯就可以节省了, 而且界面相应速度也得到了提升
只有在页面数据和视图高度绑定的情况下, 前后端不分离的劣势在比较不明显 另外... 前后端分离也不只 react 一种解决方案, 其实任何 json xhr 请求都是某种意义上的分离 |
|
332
FrankFang128 OP @quix 网络通讯增加了吧，你每多一个 json ，就多一次 HTTP 请求。界面『看起来』变快了，但是『可响应时间』变慢了。
任何分离方案，都要在客户端渲染 HTML ，一定存在多次渲染。 |
|
333
quix 2016-08-10 12:09:21 +08:00
@FrankFang128 多个 json ? API gateway 可以解决这个问题啊, 另外渲染 Html 本身并不费多少客户端资源, 但集中在服务器端渲染就对服务器产生了很大负荷
|
 |
334
kevin1852 2016-08-10 12:13:45 +08:00
国外有。。
|
 |
335
daysv 2016-08-10 12:29:29 +08:00
楼主大大高估了大部分后端写前端的能力，就我这家公司来说
如果不分离： 前端出页面， 后端填充数据。前端还要熟悉后端那一套流程（比如控制路由），每次都需要沟通， 效率极其低下 分离开来：前端写前端，后端提供接口， 各司其职， 并且前端不需要装后端那一套环境，还可以直接使用诸如 HMR 等模块开发 同样是 2 个人写代码，你觉得哪种好？ |
 |
336
shunia 2016-08-10 12:35:29 +08:00
赞同楼主，简单的当然全栈好。
复杂的还是分离好。 楼主过于强调‘简单的’这种情况了。 实际上‘复杂’的情况应该是远远多过‘简单’的情况。 作为从业过传统 web 和游戏行业的前端选手来看，还真没碰到过整个项目是‘简单’需求的情况，当然这里面不排除项目中的个别需求是‘简单’的。 分离有一个好处是在管理上，既包括项目，也包括人。 在项目上来说，比如说 hotfix ，前后端分离与不分离的工作量级和上线代价就完全不一样。 在复用上也有很大差别，多端和可用性的问题，分离的帮助是非常大的。 在人上来说，楼下有很多人提到，很难招到懂一点后端的前端，其实反过来也是，很难招到懂一点前端的后端。这里的懂，我想说的是：对前端来说能稍微懂到数据库设计的层面，对后端来说能稍微懂到 dom 优化的层面。因为达不到这个量级，懂不懂并没有任何意义。随便找个前端也能写写后台接口逻辑，随便找个后端也能 jquery 掏出来给你写一个表单验证。 分离之后，在一个较大的项目里，可以有效降低沟通成本。各端的 tech leader 可以提前达成一致，只需要向下传递，然后在开发的时候一对一迭代就行，对整个项目来说成本很低。出现 bug 或者问题的时候，至少有两个人是知道什么情况的，反馈起来也更顺畅。 假如你只是做个公众号，还分个啥的前后啊， php+jquery 一口气写完了拉倒。 假如你要做个 100 多个页面的网站，不分前后怎么开展工作，招 5 个全栈，各自写 20 个页面吗？ |
 |
337
yehon 2016-08-10 12:46:34 +08:00 via iPhone
一般这种引战贴都很火。
|
|
338
FrankFang128 OP @shunia 简单的情况远远多于复杂情况。 我说的简单不是业务逻辑简单，是操作模式简单。
|
|
339
FrankFang128 OP @daysv 因为你们的后台框架不是面向全栈的。前端用起来当然痛苦。
|
|
340
FrankFang128 OP @shunia 任何框架都解决不了『业务逻辑复杂』的问题，但是由于 Web 的操作模式基本都是增删改查，所以交互是简单的，比游戏简单 1000 倍。
所以我不知道大部分业务为什么需要 React 、 Vue 这样的东西，为什么要在客户端渲染 HTML |
|
341
shunia 2016-08-10 13:41:07 +08:00
@FrankFang128
框架的优势在于提供了一套易用和设计合理的组件化框架。迎合了页面前端开发的多年未曾被满足的需求。所以大部分业务都需要。 客户端渲染 HTML 的原因非常多， 1 、开发和测试更简单，开发不需要安装复杂的服务器环境或者对接服务器，测试可以更快的介入。 2 、因此更容易迭代，在开发工程中能更快速有效的迎合产品需求。 3 、上线过程简单可靠。其他种种可能我无法说全。非特殊情况下，我认为始终应该前端渲染 HTML 。 React 和 Vue 其实都非常非常着重组件化，甚至在我看来，更加易用和设计合理的组件化功能才是他们受欢迎的最重要因素，也是前端需要他们的核心原因，所谓的虚拟 DOM 和各种优化这种藏在表象背后的功能，只是前端应用化的“噱头”而已，因为要满足设计良好易用的组件化需求，核心的功能是必不可少的，只是大家实现的方法越来越“先进”。 这些框架，只是刚好迎合了多年未曾满足的页面前端开发需求而已。爆发式增长，是因为有太多需求没有被满足，干柴遇到烈火了。 有多少用 jquery 的前端同学会写一个 jquery 组件？大家习惯性都是用它来操作 DOM 。 而 React 和 Vue 呢？他们一开始就在教你怎么又快又好的写组件。 |
 |
342
w7938940 2016-08-10 13:46:41 +08:00
嗯 我们搞 Rails 的都是这么想的 :smile:
|
 |
344
ourai 2016-08-10 14:33:56 +08:00
我就想问你——
后端是 Java 的 SpringMVC ， HTML 代码写在 Velocity 里的开发模式下，只修改一点点样式或文案时，怎么发布？ |
|
345
FrankFang128 OP @ourai 那是因为这个后台框架没有考虑这个问题。而且做页面的时候也要思考这个问题。
|
|
346
daysv 2016-08-10 15:19:48 +08:00
@FrankFang128 呃，那有什么现成的方案呢？ 我们后端是 java
|
|
347
FrankFang128 OP @daysv 你搜 rails java
|
 |
348
AjaxMa 2016-08-10 15:41:03 +08:00
呃 。。。 。。。 说一下 我们公司前后端分离开发的原因 ： 加快项目进度 。。 。。 。。 没有错， 仅此 足已 ~~ 项目方案确定，原型和数据库设计给出，然后是设计和 JSON 规范， OK ， 准备完成，开始工作 。。 。。 。。要知道，项目开发的过程中，客户和产品有各种可能更改各种需求，但变化最大的其实就是页面上的东西，包括方案调整、布局调整，配色调整，图标调整等等 ， 所以，前后端分离，保持业务数据一致性，界面根据动态需求快速调整，更快的把东西反馈给客户或产品，也才能更快的拿到改进意见，也才能更快的完成项目；另外，页面尽快完成也能更好的去演示，使用动态数据演示比纯展示静态页面关系更有说服力 。 小公司，坚决执行 Scrum ~~~
|
|
349
FrankFang128 OP @AjaxMa 如果你们的后台环境能很方便的在本地搭建的话，就能避免一些问题了。并不是说分离才能 Scrum 。
当然你为了让前端迭代更快，然后采用分离的方式，是对的。但这个不是唯一方案。 |
 |
350
pockry 2016-08-10 16:29:49 +08:00
分离还有一个原因是前端和后端的目标并不相同，后端需要操心安全、稳定性，前端则需要面对快速变更的需求。如果每一次涉及到数据渲染的页面修改都要改好几个链条，系统要上个新版本，那开发效率必然高不到哪儿去。
另外楼主的阴谋论太幼稚了，前端的重要性提升原因只有一个，那就是用户体验的地位提高了，而 GUI 是用户体验最直接相关的部分。 |
|
352
FrankFang128 OP @pockry 用户体验的功劳被分到设计师啦，没前端什么事情。
|
|
353
pockry 2016-08-10 17:18:39 +08:00
@FrankFang128 应该说产品、设计、前端都因之而受益
|
 |
354
jiongxiaobu 2016-08-10 18:52:27 +08:00
talk is cheap ，楼主分享一下你用的构架把
|
 |
355
whimsySun 2016-08-10 19:01:43 +08:00
看完楼主的帖子后，我有感而发 为什么我不喜欢「后端开发和运维分离」。。。逃~
|
 |
356
victor 2016-08-10 20:42:13 +08:00
@whimsySun 逃什么？你说的很对啊。楼主目前在用的 Rails 框架也要求后端人员自己写好测试代码，所以测试岗可以取消了。对了，有个软件叫 Sketch 的，学起来很简单嘛，设计师的岗位也可以干掉了。 cool
|
 |
357
tww316 2016-08-10 21:44:46 +08:00
赞同👍
然而楼主似乎低估了国内 coder 的水平，嗯。 |
|
358
tww316 2016-08-10 21:48:11 +08:00
BTW ：楼主忘了国内的开发语言笔试链，😄
|
 |
359
barbery 2016-08-10 21:51:06 +08:00
我觉得前后端分离在团队合作过程可以提高开发效率，并不觉得有什么不堪~
没有最完美的架构，只有最适合自己业务的架构 |
 |
360
mailto1587 2016-08-11 00:47:22 +08:00
一句话，关注点分离，至于全栈工程师，我没奢望，也不奢求写前端的人都能去写好 Node ，那才是噩梦
前后端领域本身关注点就不一样，前端做好状态管理，后端尽可能做到无状态，为什么要扭到一起？ 背景创业三年中，团队很早做了前后端分离，对产品质控提升很大 至于小网站用好 jQ 就够了，能用就用，但现在大环境告诉大家前端不止 jQ ，这是很好的趋势，不然 ES 还需要迭代什么？曾经写 Flash 学 ES4 的人，看了 ES5 那模样，觉得 ES6 甚至 7 都来得太晚 |
|
361
FrankFang128 OP @mailto1587 我上一篇已经吐槽用 Babel 了
|
|
362
geek123 2016-08-11 09:43:04 +08:00
@FrankFang128 很想转一下这篇文章，挺有意思。
|
 |
363
jaky666 2016-08-11 10:06:24 +08:00
个人认为前后端分离可以节省后端的开发时间，产出更高效点
|
|
364
FrankFang128 OP @jaky666 一件事分给两个人做，每个人做得少了。但是合起来的时间比一个人用得多。
|
|
365
FrankFang128 OP @geek123 别转，阿里的前端要骂死我
|
 |
366
wizardforcel 2016-08-11 10:39:38 +08:00
@FrankFang128
[用户体验的功劳被分到设计师啦，没前端什么事情。] 除了页面的布局和配色之外，交互也是体验的重要组成部分。如果不分离，那么起码查询操作就得重新刷新页面，何来体验一说？ 前后端分离不是指用框架，只要你增删改查四个交互全用 Ajax ，就算前后端分离。 Web 2.0 的前端基本上增删改的交互是 Ajax ，只有查还需要刷页面，你不觉得后端渲染和 Ajax 混用很麻烦吗？ |
|
367
FrankFang128 OP @wizardforcel 老旧的后台框架才不支持局部刷新，你看 GitHub 用 pjax 做局部刷新，体验很差么？
|
|
368
geek123 2016-08-11 11:02:32 +08:00
@FrankFang128 我们自己的用户，我觉得他们可能也能讨论讨论。哈哈。
|
 |
369
elseif 2016-08-11 11:07:36 +08:00
表示赞同~
|
 |
370
coconne 2016-08-11 11:54:43 +08:00
好吧，能问个外行的话，前后端不分离的项目，你们的复用率高吗？
|
|
371
wizardforcel 2016-08-11 12:46:49 +08:00 via Android
@FrankFang128 局部刷新是 ajax 和 dom api 的操作，跟框架不框架没关系。此外，提供不提供和用不用是两回事，你可以随便找个网站的 html 文件看看源代码，查询操作直接刷模板而不 ajax 获取的，不占少数。
前后端分离下的页面一定是纯 html+js 的页面，这些页面可以放在 cdn 上面，进一步提高加载速度。后端的接口做好健壮性之后按需给跨域就行了。 |
 |
372
lii 2016-08-11 13:28:33 +08:00
只看了标题
|
 |
373
masterzh01 2016-08-11 13:38:01 +08:00
所谓"全栈工程师"跟 Web 工程师有啥区别。
|
 |
374
ssoftlns 2016-08-11 14:19:01 +08:00
手动 mark 一下 感谢 lz 把这事儿辨明了 合适的才是最好的
|
 |
375
stevenlee 2016-08-11 15:02:59 +08:00
分层与不分层的设计，需结合现实实际业务场景来看，没有绝对完美的架构设计，也没有绝对完美的编程语言。
|
|
376
FrankFang128 OP @stevenlee 如果我这么写得话，大家就没得碰撞了。
|
 |
377
y 2016-08-11 17:53:42 +08:00
@FrankFang128 我试了试好像现在禁用 js 还是可以用的啊（我是说 Amazon.com 不是 .cn ）
|
 |
378
tamyiuchau 2016-08-11 23:27:49 +08:00 via Android
小網站，依然決定前後端分離，原因只有一個， CDN
|
|
379
FrankFang128 OP @tamyiuchau 你把代码部署两份不就好了
|
|
380
tamyiuchau 2016-08-11 23:54:26 +08:00 via Android
@FrankFang128 對於 pull cdn,前後端不分離的話每次請求整個頁面都會回源， cdn 的緩存加速的能力等於零；分離的話，只有部分需要由服務器發出去，而且大部分都能塞到一個封包裡解決。
對於 push cdn,你不事先把前端 /靜態推送到 cdn 的話根本不能用... |
|
381
FrankFang128 OP @tamyiuchau 不分离也能做前端打包预编译的呀……
|
|
382
tamyiuchau 2016-08-12 00:49:23 +08:00 via Android
@FrankFang128 感覺有些根本的概念觀點不同...這裡講講我的定義
渲染：產生最終 html 的過程,比如有非共同內容,ie:用戶名字，在模板 html 填入用戶名字這一步就叫渲染（這裡不是解瀏覽器根據 css 和 html 產生圖形的那步） 前端後端結合:存在伺服器填入非共通內容產生 html 的情況，不管是否後續還有 ajax 什麼的 前後端分離：對模板 html 的填入只在客戶端進行 如果只進行唯一一次 html/js 的組合（靜態化）產生模板 html （在這步依然沒有非共同內容），並不是前後端結合，因為這等價于編譯而已，不是渲染 服務器後端的運作不依賴模板 html,只是因為開發的方便 |
|
383
tamyiuchau 2016-08-12 00:52:26 +08:00 via Android
把文件放到一起，用同一個伺服器處理 cdn 回源，算前後端分離
|
|
384
FrankFang128 OP @tamyiuchau 我的前后不分离就是：拒绝前端渲染，必须后端渲染。前端没有 MVC 之类的结构。
前后不分离，服务器依然不依赖 HTML 模板，服务器先产生一个 data ，然后根据 request header 里面的 accept 字段来决定将 data 渲染为 JSON 还是 HTML 或是 XML |
 |
385
jsjscool 2016-08-12 02:28:11 +08:00
同意楼主的观点，但是实际在项目分工时，后端和前端的关注点是不一样的，后端求性能『稳』，前端求用户『爽』。
让一个后端去写前端，多几次循环多几行冗余的代码都会难受，因为 3 位数以下的循环前端不需要关心。 让一个前端去写后端，会先找有没有现成的扩展用，分分钟出活才是真，他的关注点是能实现功能就行。而后端注重可维护性和稳定性。 前后端分离能减少很多不必要的沟通成本，大家都参照 UI 的设计图出活。后端出接口文档后，去做自己喜欢做的事。前端把新学的框架拿来练练手，大家共同进步 |
 |
386
kslr 2016-08-12 03:25:38 +08:00 via Android
单纯的分离我是不愿意的
但是如果 Pc,app 都可以共用一套 ap 岂不是很方便 |
 |
387
immatt2015 2016-08-12 08:19:30 +08:00 via iPhone
楼主做项目的时候用过前后端分离吗？ 还是说只是思维定势？
|
 |
388
yidinghe 2016-08-12 08:21:23 +08:00 via Android
怎么感觉一个好好的项目开发变成权力游戏了。。。这不是一个项目该有的状态。
由于开发工作量的增加和工作内容的细分，前后端分离是必然出现的。因为前端框架从没有过像今天这么复杂，而这也是随着浏览器得越来越强大、用户体验要求越来越高而导致的。 至于为什么一个业务要几个人来写，如今微服务开始流行的背景下，即使是后端，一个业务也都不是一个人完成的，所以这没必要抱怨。 |
|
389
FrankFang128 OP @jsjscool 造成你说的问题的原因，不就是因为前后分离了吗？一个团队只需要一个经验丰富的前端顾问和后端顾问就行了，其它都是全栈
|
 |
390
42thcoder 2016-08-12 09:54:33 +08:00
难得碰到跟我观点一致的, 尤其是技术政治那段~
1. 一个人知道整个业务。任何业务问题，马上解决。 这个真心是我现在的痛点, 项目页面出个小 bug, 还要发邮件找前端部门, 排期才能改.是的, 前后端分离的结果之一, 是我们这个小公司也有单独的前端部门, 而非各个团队有自己的前端. |
|
391
42thcoder 2016-08-12 09:57:15 +08:00 1
@frjalex
> 楼主你没考虑过性能问题吗？用服务器端做 REST API + 客户端渲染会比一般的纯服务端快速不少，这是趋势啊 九成页面, 服务端渲染速度能秒杀客户端渲染, 协商缓存都用不了, 还有白屏的问题, 谈什么速度快. |
|
392
42thcoder 2016-08-12 10:01:20 +08:00 1
@daysv
> 楼主大大高估了大部分后端写前端的能力，就我这家公司来说 如果不分离： 前端出页面， 后端填充数据。前端还要熟悉后端那一套流程（比如控制路由），每次都需要沟通， 效率极其低下 分离开来：前端写前端，后端提供接口， 各司其职， 并且前端不需要装后端那一套环境，还可以直接使用诸如 HMR 等模块开发 同样是 2 个人写代码，你觉得哪种好？ 你这个是大大低估了前端同学的能力, 控制路由这种还需要每次都沟通? 是在不行还可以交给后端同学做. 不分离的话, 短期内前端同学的效率会低一点, 毕竟还要配置环境, 花俩小时学习后端的路由. 但对于整个团队来说, 效率是大大提高的 |
|
393
42thcoder 2016-08-12 10:03:47 +08:00 1
@kslr 对服务端来说, 客户端( 原生 && browser )请求 xx.json 就返回 JSON 格式数据, 请求 xx.html 就返回页面, 业务逻辑是复用的, 区别只在于渲染数据的 adapter
|
|
394
FrankFang128 OP @42thcoder 他们后台人员太差了，不知道你说的这些，只想把工作分到前端做，这些可爱的前端还真信了
|
|
395
jiongxiaobu 2016-08-12 10:15:45 +08:00
感觉可以用 PHP 是世界上最好的语言 来总结此贴
|
|
397
FrankFang128 OP |
 |
398
scott1743 2016-08-12 10:37:05 +08:00
@frjalex 提升渲染效率可以用 turbolinks 这种工具或者局部用 vue 加载，并不是一定要分离。
另外重复楼主一句，产品设计测试开发加起来不到 30 人的团队真的没必要分离，徒增工作量，降低了效率。有那个钱招专业的前端，还不如买好点的服务器。 |
 |
400
yxwqwgz 2016-08-12 10:58:32 +08:00
楼主的对自己无知是无知的。
Separation of Concerns (SoC) – 关注点分离 这个原则，就是在软件开发中，通过各种手段，将问题的各个关注点分开。如果一个问题能分解为独立且较小的问题，就是相对较易解决的。问题太过于复杂，要解决问题需要关注的点太多，而程序员的能力是有限的，不能同时关注于问题的各个方面。 |
Select Language