推荐关注
› 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
 |
401
FrankFang128 OP @yxwqwgz 你司为何不招一个专门写 HTML 的、一个专门写 CSS 的、一个专门写 JS 的？
关注点分离没说粒度，跟没说一样。 |
|
402
FrankFang128 OP @yxwqwgz 说的好像不分离就是一团糟的样子
|
 |
403
swirling 2016-08-12 11:12:50 +08:00
我也是职业前端。有点同感，大多数人不知道自己的业务复杂程度在什么程度上。
|
 |
404
yunji3344 2016-08-12 11:32:49 +08:00
看公司的实力了，如果项目大，钱多那肯定要分离。由专业的管理协调工作
|
 |
407
scott1743 2016-08-12 11:39:48 +08:00
@FrankFang128 git 还得再招一个
|
 |
408
jarlyyn 2016-08-12 11:43:32 +08:00
@FrankFang128
有没有全栈和前后段分离有什么关系。 一个是代码结构，一个是分工。 我自己一个人写的内部项目也都是前后端分离的啊。 不考虑 SEO 的项目一定要把前后端搞在一起自己折磨自己有什么意思。 在各种模板引擎里写 Html/js 不痛苦么？ |
|
409
FrankFang128 OP @jarlyyn 大部分只有一个请求，提交信息的时候才有额外请求。
接受多种提交格式，返回多种提交格式。 |
|
410
FrankFang128 OP @jarlyyn 在各种模板引擎里写 Html/js 不痛苦么？ -> 你是在说 Angular/React/Vue 吗
|
|
414
jarlyyn 2016-08-12 12:18:57 +08:00
|
|
415
jarlyyn 2016-08-12 12:19:38 +08:00
|
|
417
FrankFang128 OP @jarlyyn 那是 NodeJS 的问题，它的 API 都是异步的
|
|
418
jarlyyn 2016-08-12 13:27:55 +08:00
|
|
419
FrankFang128 OP |
|
420
jarlyyn 2016-08-12 13:43:52 +08:00
@FrankFang128
我的浏览器天赋异斌啊。 Async is a utility module which provides straight-forward, powerful functions for working with asynchronous JavaScript. Although originally designed for use with Node.js and installable via npm install --save async, it can also be used directly in the browser. 一个页面请求多个数据，有多个 post 点不是很正常的，怎么可能通过一个 accept 或者 method 就区分开。 |
 |
421
MiguelValentine 2016-08-12 14:10:46 +08:00
诶。。你知道最大的区别么。。。 render 这个过程，在高并发下，严重占用服务器资源。。。
写这文章的人，让我喷你一句业务仔。 从用户体验上来讲，也是分离之后，延迟更小，感觉越少。 |
|
422
FrankFang128 OP @jarlyyn 你用影响啊， post /user 和 post /user_group 都行啊。
就是一个 ajax 请求，得到一段数据，根据数据弹框或进入新页面。 |
|
423
FrankFang128 OP |
|
424
jarlyyn 2016-08-12 14:14:47 +08:00
|
|
425
MiguelValentine 2016-08-12 14:16:14 +08:00
|
 |
426
est 2016-08-12 14:18:08 +08:00
哎哟我擦。都 5 页了
|
|
427
FrankFang128 OP @jarlyyn
controller: profile = loadProfile() news = loadNews() replys = loadReplys() render('html or json') 这样解决 |
|
428
FrankFang128 OP @MiguelValentine 就问你没有做前后分离的 GitHub 体验好不好
|
|
429
FrankFang128 OP @MiguelValentine 性能不行加机器，把性能转译到客户端当然能减轻压力，但是加机器并不贵，至少比招一个前端便宜。
|
 |
430
daysv 2016-08-12 14:29:41 +08:00
好吧， 可能我的项目符合非常非常非常复杂的软件
|
|
431
MiguelValentine 2016-08-12 14:30:36 +08:00
|
|
432
jarlyyn 2016-08-12 14:50:16 +08:00
|
 |
433
42thcoder 2016-08-12 14:54:24 +08:00
@jarlyyn
>我的浏览器天赋异斌啊。 Async is a utility module which provides straight-forward, powerful functions for working with asynchronous JavaScript. Although originally designed for use with Node.js and installable via npm install --save async, it can also be used directly in the browser. 一个页面请求多个数据，有多个 post 点不是很正常的，怎么可能通过一个 accept 或者 method 就区分开 一个页面请求多个数据，为什么会有多个 post 点, 你是想说 get? 大多数页面, 获取数据的 get 请求合并成渲染一个 html 页面, 完全没问题, 性能也只会更好. |
|
434
42thcoder 2016-08-12 14:58:30 +08:00
@jarlyyn
>一个前端页只有一个请求么？ 一个前端页只有一种提交信息的请求么？ `一个前端页只有一个请求么？` , 这就是典型的`没有困难, 发明困难也要上`. 未分离的时候, 大多数页面就是一个 HTML 请求, 不考虑静态资源. `一个前端页只有一种提交信息的请求么？` 不分离, 又不影响你提交信息. PS: 提交信息这种情况, 可以选择 ajax; 甚至是 ajax 也都不用, 直接原生表单提交, 而且速度还快? 至于怎么做到, 可以自行了解下 Turbolinks 5, . |
|
435
jarlyyn 2016-08-12 14:59:19 +08:00
@42thcoder
以 V2EX 的个人设置为例 http://www.v2ex.com/settings 有资料设置，上传头像，修改密码 3 个 POST 点。 这话真的是前端该问的么…… 性能？ 局部更新的问题考虑过么？缓存的问题考虑过么？ |
|
436
jarlyyn 2016-08-12 15:03:10 +08:00
@42thcoder
ajax 不就是前后端分离？ 或者你 ajax 也要获取整个页面？ 说真的，不要尝试着教我什么，毕竟你 3 年前还在求实习，至少从工作年限上，没啥好教育我的地方。 前后端分离的本质是数据和表现的分离。 |
|
437
42thcoder 2016-08-12 15:03:30 +08:00
@jarlyyn 分离或者不分离, 使用 ajax 的话, 没有区别.
不分离的话, 我使用原生表单, 借助 Turbolinks 这种技术, 也可以保证页面不重复获取静态资源; 而且页面的各个 block 都做服务端缓存 |
|
438
FrankFang128 OP @jarlyyn 三个 POST 点就对应三个 URL 来 POST 啊，有什么问题？显示还是用一个 URL
|
|
439
FrankFang128 OP @jarlyyn 另外，用 pushStage 很容易让 URL 更好看，用户感觉是一个 URL ，其实是三个 URL
|
|
440
FrankFang128 OP pushState
|
|
441
jarlyyn 2016-08-12 15:05:50 +08:00
|
|
442
FrankFang128 OP 一个页面操作多个表，传统开发方式没有问题的。
|
|
443
jarlyyn 2016-08-12 15:06:46 +08:00
|
|
444
42thcoder 2016-08-12 15:08:44 +08:00
@jarlyyn 我去, 讨论问题说错话, 就开始找对方个人的茬, 这套路.....
`ajax 不就是前后端分离？` 这种话都说出来了, 您到底懂不懂前后端分离啊. 在你了解什么是 `Turbolinks ` 之前不打算继续交流了 |
|
445
FrankFang128 OP @jarlyyn 如果你的路由是 RESTful 风格的，应该尽量做到一个页面表示一个资源。
具体到 V2EX 设置页面这样的，可以妥协 读取用一个页面返回三张表的内容， POST 的时候用三个 form 提交。 这个只是风格问题，看起来不优雅。 假设你做成全走 API 的模式， 那么读的时候，用 AJAX 取三个 API 的 JSON 写的时候也是分三个 AJAX 实质上并没有提速（反而减速了，因为一个 HTML 请求变成了一个 HTML 三个 AJAX ）。只是看起来条理清楚了 |
|
446
FrankFang128 OP @jarlyyn 现在的全栈 Web 框架，都会融合 form 提交和 Ajax 提交了，比如 pjax 技术方案。
只有在以前那些老旧的 Web 框架里，才会不用 Ajax 我说的前后分离，是把『是否全盘采用浏览器渲染』作为主要判断依据。 |
|
447
jarlyyn 2016-08-12 15:15:03 +08:00
@42thcoder
对不起，我看了下 Turbolinks ，真不懂这种东西有什么价值。 至于 ajax.从一开始指的就是 ‘ Asynchronous Javascript And XML ’ 只不过现在 json 代替了 xml 的位置而已。 这还不是前后端分离？ |
|
448
jarlyyn 2016-08-12 15:16:16 +08:00
|
|
449
jarlyyn 2016-08-12 15:17:49 +08:00
@FrankFang128
我说的前后端分离，是指： 服务器程序通过 api 提供 xml/json 或其他形式的数据。 由 html 静态页 /js 负责具体的渲染。 应该和你的定义一致吧？ 这应该是讨论的基础。 |
|
450
42thcoder 2016-08-12 15:19:00 +08:00
@FrankFang128
他提到的一个页面 3 个表单这种情况,可以不用 ajax. 直接上原生表单, 服务端处理, 渲染 HTML, 浏览器端端神奇的事情发生了: Turbolinks automatically fetches the page, swaps in its <body>, and merges its <head>, all without incurring the cost of a full page load. 服务端在渲染 HTML 的时候呢, 整个页面是基于俄罗斯套娃式的片段缓存, 以 V2EX 设置页面为例, 可以分为设置, 隐私, 屏蔽, 头像, 密码等多个 block, 分别做缓存. 渲染速度快到飞起~ |
|
451
FrankFang128 OP @jarlyyn 可以呀，只要不做客户端渲染，全走 server 渲染，就是前后端不分离。 API 的设计该怎么设计都可以。
一个四个 API get /settings post /settings1 post /settings2 post /settings3 页面上的 JS $('form[name=settings1').on submit --post /settings1, {accetp:'json'} $('form[name=settings2').on submit --post /settings2, {accetp:'json'} $('form[name=settings1').on submit --post /settings3, {accetp:'json'} 有啥问题 前后不分离 |
|
452
FrankFang128 OP @42thcoder 我觉得没必要具体提 Turbolinks ，毕竟很多前端没接触这个。
|
|
453
FrankFang128 OP @jarlyyn 你的概念和我是一致的。
我主张不要让客户端做渲染。要让 server 来渲染。 |
|
454
jarlyyn 2016-08-12 15:24:30 +08:00
@FrankFang128
好了，接下去会有两个问题。 1.你的错误提示怎么反馈。 2.既然处理数据都是 JS 处理，那么为什么不做成一个静态页，从一开始就让 JS 来处理呢？在有缓存的情况下，每次显示之需要一个很小的 json 就可以了，而不用更新整个包括 head/scipte/style 等标签在内的 html? |
|
455
FrankFang128 OP @42thcoder 我刚开始接触 Turbolinks 的时候，发现 React 不就是一个客户端的 Turbolinks 嘛，思路一致的。
但是 React 自己在浏览器端维护 Model 和 View ，让我觉得太过了。 |
|
456
jarlyyn 2016-08-12 15:26:49 +08:00
@FrankFang128
我主张尽可能的让客户端做渲染，不要让服务器来处理。 让客户端来处理的优点包括： 1.易于缓存。 2.易于维护。 3.前端控制力度强，易于做跨页面的处理。 缺点包括： 1.需要一定的 js 框架架构。 2.不利于 seo 。 |
|
457
jarlyyn 2016-08-12 15:27:41 +08:00
|
|
458
jarlyyn 2016-08-12 15:29:12 +08:00
|
 |
459
breeswish 2016-08-12 15:29:15 +08:00
HTML 应当是前端来控制的
HTML 传统是写 template 渲染，现在流行用 JavaScript 在浏览器端渲染，楼主其实是想说喷后者吧。 我觉得区分 WebPage 和 WebApp 是很重要的， WebPage 用 JavaScript 渲染就是不合适的， WebApp 用 JavaScript 渲染是合适的。当然一个网站上可能混合了 WebPage 和 WebApp 。 |
|
460
FrankFang128 OP @jarlyyn 用 jQuery 插件提示或者跳页面。
JS 没有处理数据，因为 server 才是数据处理者。 JS 只做了正则校验。 JS 不做校验都行，因为 server 一定会校验。 如果你全给 JS 来处理，你 server 的数据校验依然不能省略—— 这时你分别在浏览器和 server 做了两次数据处理。 没有更新整个 HTML 啊。 |
|
461
FrankFang128 OP @breeswish 98%的页面都是 WebPage ，我认为。所以 React 现在这么火，是不正常的。
|
|
462
jarlyyn 2016-08-12 15:31:41 +08:00
@FrankFang128
请你不要和我普及这种最基础不过的内容…… 错误后你不需要更新对应的 html,加红 /加提示吗？ 这种情况你是怎么处理的呢？ 我用过三种方法。 1.返回整个 html 2.返回对应需要更新部分的 html,不带 head/body 等信息 3.返回 json. |
|
463
FrankFang128 OP @jarlyyn 我默认把 Redux / FLUX 等同于 React 来讲了。你用 React 必须有一个 Store ，那不就是 Model 吗，这个 Model 跟服务器不一致了你怎么办。
|
|
464
jarlyyn 2016-08-12 15:32:45 +08:00
|
|
465
FrankFang128 OP @jarlyyn 你用一个 jQuery Form Alert 之类的插件不就好了么。 JS 的地位永远只是『修饰』 HTML
|
|
466
jarlyyn 2016-08-12 15:33:33 +08:00
|
|
467
FrankFang128 OP @jarlyyn React 排斥 HTML 、 DOM 、 CSS 。把所有东西变成 JS 。像是一个 Hack 方案，不是一个好方案。
|
|
468
FrankFang128 OP @jarlyyn 是的，要去服务器拉，但是又不想拉太多 API 。所以 Facebook 又发明了 GraphQL
|
|
469
breeswish 2016-08-12 15:38:49 +08:00
@FrankFang128 我觉得只要是交互性强的场景或者功能都可以用 WebApp 思路去解决。举个例子， V2EX 评论想 ajax 化的话，就可以考虑把这部分做成 WebApp 的方式来渲染，诚然有大材小用（针对目前功能而言），但对新增功能来说，实现代价低得多。当然，如果确实只有那么简单的功能，那么做成复杂的 WebApp 方式也是属于闲的没事干
|
|
470
FrankFang128 OP @jarlyyn 我之前的帖子吐槽过了，我就是看不惯现在的前端框架把原生的东西都跟否决了。
Virtual DOM 什么鬼，为了函数式而函数式，为了状态机而状态机。很说原生 DOM 渲染慢，那个用户手那么快能在 1 秒内频繁操作 DOM 。 CSS in JS 什么鬼，把 CSS 的伪类、继承都不要了，仅仅为了一个所谓的模块化。搞得好像以前的页面 CSS 都没有模块化似的。 JSX 又是什么鬼，搞得我写得 JS 都不能直接放在浏览器运行。 |
|
471
FrankFang128 OP @breeswish 不用分离，发个 AJAX 返回一段 HTML 不就行了。其实返回一段 JS 更好（ server javascript response ），不过考虑到很多前端没了解过，就不说了。
|
|
472
jarlyyn 2016-08-12 15:47:26 +08:00
@FrankFang128
react 只是一个渲染+双向绑定的解决方案而已。本质上并没有取代 js/css,是输出 html 和做相应绑定的。在做前端 mvc 的时候，一般也只是 v 来处理的。 既然要否决现在原声的东西，自然说明有相应的需求。 react 明显是为了复杂的网页 app 来解决的，但是，这个和前后端分离不能直接挂钩啊。 |
|
473
FrankFang128 OP @jarlyyn 没有取代 HTML 么，你看看用了 React 的项目里有没有 HTML 文件…… 全是 JSX （ JSX 里面的 HTML 只是语法糖，不是 HTML ，最终变成 JS ）
React 是前后分离的典型——全盘采用 Client Render 。 后来 React 被吐槽，于是 React 说我支持 Server Render 好了吧。 然后你再去看看 Server Render 出来的页面……各种标记各种 Hack 。你写的 HTML 跟浏览器里的 HTML 根本不一样。 还是那句话， 98%的页面都不是复杂页面，只有那些以前用 EXTjs 的页面才是复杂页面，比如 OA 、 ERP 、 CRM 、在线 IDE |
|
474
jarlyyn 2016-08-12 15:58:55 +08:00
@FrankFang128
React 项目里必然有 html 文件啊。 react 本身也是生成 html 啊 react 还能很好的和其他方式并用，至少和 jquery 就能结合的很好。 别人用偏了 react,和 react 本身有什么关系？ 只能说现在滥用 react 可能很严重罢了。 |
 |
475
yangxiongguo 2016-08-12 15:59:15 +08:00
战斗力真强
|
 |
476
fundon 2016-08-12 16:01:52 +08:00
2016 年的第一场雪，小汪和小袁决定出去创业，创立了洪荒之力科技有限公司。
两个人说干就干，小汪负责产品需求，小袁负责技术开发，为了求快，赶快把心中的 V1 版本做出来，快快快就是他们的口号！ 经过几个月的辛苦劳动， V1 版本终于出来，于是他们决定扔到市场上进行验证，老天不负有心人，他们收到了不错的用户反馈，业务也在不等增长，这个把大家乐坏了，喜上加喜的是他们也完成一轮可观的融资。 不断的需求， BUG 让单兵作战的小袁忙得不可开交，身心疲惫，借着这轮融资，小汪和小袁决定招人，他们面对问题是 1. 出移动端 App ， iOS, Android 2. Web 需要重新设计 3. 老 Web 还需要继续修 BUG 4. 招几个人呢 他们讨论了几天…… --- 未完待续 |
|
477
FrankFang128 OP @jarlyyn React 怎么跟 jQuery 结合……我真没听说过， jQuery 又不能操作 Virtual DOM
不是人用偏了，而是用了 React ，你就没法用以下东西了 1. HTML ，你只能在 JSX 里使用 HTML 2. DOM API (jQuery)， https://discuss.reactjs.org/t/jquery-with-react/683 3. CSS ，用也可以，那就「不函数式」了 4. 开发者工具，你需要使用 Facebook 提供的开发工具（这酸爽） |
|
478
scott1743 2016-08-12 16:11:40 +08:00
评论从头看到尾，先把观点意见撇一边。
不管辩手深浅总归是各持观点试图证明自己的立场，本来我是沉浸于讨论中。 结果有玛丽苏青铜小学生，估计帖子内容和评论都没看完就开喷；仿佛坐在 1y 平米的办公室，用纯金键盘告诉大家，我工资高就是屌。 真吓到宝宝了😂 😂 😂 |
|
479
FrankFang128 OP |
|
480
FrankFang128 OP @scott1743 谁。。
|
 |
482
zhangxiao 2016-08-12 16:21:14 +08:00
我觉得分离是发展的必然结果。 LZ 说不知道国外是不是有这样的运动，看看 React 和 Angular 这两个在前端算是最重量级的两个库就可想而知。一个来自 FB 一个来自 GOOG ，为什么他们要造这样的库，不是为了好玩炫技。
互联网的发展导致了应用的发展，要面对高并发，要面对高复杂度，要面对各种交互。 FB 算是一个典型的例子了。现在应用的界面交互复杂度导致了需要更好的结构化来保证可读性，可维护性。 数据和模板的分离早就存在，只不过以前一个人做，现在两个人做，无可厚非。 本人全栈 |
|
483
fundon 2016-08-12 16:21:23 +08:00
|
|
484
scott1743 2016-08-12 16:21:42 +08:00
@FrankFang128 431 😂
|
|
485
zhangxiao 2016-08-12 16:24:18 +08:00
突然觉得招中啊，本帖吸金好手
|
 |
486
wolffn 2016-08-12 16:32:23 +08:00
我是职业前段，支持 lz
|
 |
487
112852250 2016-08-12 16:42:21 +08:00
我有时也有作者的想法，觉得 web 前端照目前的情况发展下去，不就是走微软 webform 的路子?前端整了一堆 angular,react,vue 东西出来，然后发现不行，做东西是爽，但是体积太大，而且受限于 js 本身的缺陷，各种不伦不类的绕着走，然后 gulp,webpack 又整了一堆出来，各种插件，各种包，早知道还不如直接用后台语言写呢，但是没办法，骑虎难下了，又从头来过的话，老板会发飚，自己也觉得没面子。
前端：你们看，前端很有技术含量了吧，技术发展也是日新月异，谁再看不起做前端的？打到你不服都不行。 后端：一群 SB ，扔个接口，剩下的自己玩去，我下班撩妹去了。 为什么做技术的猝死多？因为喜欢自己把自己给玩死。 |
 |
488
binux 2016-08-12 16:50:56 +08:00
|
 |
489
nino 2016-08-12 16:56:17 +08:00
我觉得你不清楚 React 解决的是什么问题。
React 性能好吗，性能再好能好过直接用 Dom API 吗？ React 所谓的性能好指的是，我即使每次都重新全量 render 一遍，我还可以有能过得去的性能。 为什么 React 能火起来，就是因为现在的应用数据源越来越复杂，状态越来越多，你手动维护数据 => 状态当然是个灾难。不管你用 pjax 也好， server javascript response 也好（这些我还真都用过），都对这个问题无解。 当然，盲目 React 的情况现在确实存在，但我可以理解，一辈子写 WebPage ，怎么升职加薪。 |
|
490
jarlyyn 2016-08-12 17:02:35 +08:00
@FrankFang128
html....难道 react 本身不是最 html 的渲染组建么？ jQuery Dom 操作？吓得我翻了下之前用 react 的代码  好像直接 dom 操作问题不大啊，项目里还一堆 jquery 插件做幻灯片 /文件上传 /视频播放上的呢。 css 的话，这个项目也是全局 css 渲染的啊。 开发工具， kate 是 facebook 定制的吧？还是 chrome 的审查代码模式是 fb 定制的？ 所以说吧，我觉得，还是用的人的问题，而不是工具本身的问题。 |
 |
491
penjianfeng 2016-08-12 17:05:55 +08:00  1
哥们儿先了解下前端和后端的概念吧,你文章中的就是前端就是狭义的 web,那请问手机端,pc 端就不叫前端了?我服务端某个 APP 请求微信,你说的 qzone 的一些开放 api 我难道不是客户端(前端)?我写 PHP,Golang,Node,也是前后端都要写,就是在了我一个人全写的情况下还是前后端分离,不要问我为什么要分离,你自己多写几个项目就知道了,而且虽说的前端就是个页面仔,渲染的?谁说服务端开发就是给你提供数据的?其他的不参与讨论,写代码去了
|
 |
492
myqianlan 2016-08-12 17:39:59 +08:00
闲得蛋疼，该干啥干啥！混沌阶段，哪需要 web 这个东西，直接亲力亲为，还需要招什么程序员
|
|
493
FrankFang128 OP @binux 后端渲染就是我说的前后不分离
|
|
494
binux 2016-08-12 18:37:13 +08:00
@FrankFang128 难道说用 jinja2 在后端渲染个页面，就是前后不分离了？
|
 |
495
baconrad 2016-08-12 18:49:06 +08:00
一個真正的 Full Stack Engineer ，
他從生活中發現問題，洞察需求，他設計解決方案，並開發出初始版本的產品。 為了達到目標，他願意去學習任何領域的技能和知識。 同時他不追求一個人完成所有工作，如果有人可以比他在某方面做得更出色，便會十分熱情的邀請他們加入。 http://daily.zhihu.com/story/8676516 剛看到，就覺得這段挺適合拿來回覆。 |
 |
496
lyris 2016-08-12 19:53:19 +08:00
最为一个后端狗，恰好在前后两个公司经历过两种模式的开发：
第一种就是 前后端不分离， 前端用 freemarker 辅以 js, 页面的主体框架部分是 freemarker,数据提交验证，侧边栏之类的都是 ajax post 来验证或渲染。每个开发周期，前端负责和美工要图，切图，静态页面的 css+静态 js （ js 用的也是 jquery ）交互效果，后端负责后台实现接口，套 freemarker 页面， js 动态数据交互，后端一个人完成一个功能，由于 js 请求有各自的 namespace ，也不会出现各个模块 js 冲突之类。页面简洁干脆。各种前端技术稳定，浏览器兼容性好，周边工具（ js/css 合并,压缩，版本控制）基本不出问题 第二种就是现在前后端分离，后端提供 api ，前端用 mvc 前端框架 knockout js ，由于时间短+任务紧，开发的系统功能点繁多，使用对象复杂， api 数量暴增，尼玛一个鼻屎大的功能就得提供分页列表，增删改查各种接口啊，各种全局定义的枚举也需要提供接口给前端啊，由于 knockout js 有自己的 MVC, 所以后台接口增加一个字段，或者重构一个字段，推动前段去改比推动牛还慢啊，各种格式化库新来的前端不熟悉，要引入各种 js plugin (传统的各种控件要适应 knockout js 框架你不可能一行代码不改动就去适配吧)啊，时间来不及就强迫让后端做各种格式化好的数据喂到前段面前啊。 感受： 1.前后端未分离时代，本人还可以自称全栈，团队开发效果奇高，页面上的数据权限控制非常简单。 在前后端分离后，出现问题本人已经改不动那些 js 了，后端已经实现了一遍 MVC ，现在前端又来一遍业务上的 MVC ，心累，除了偶尔写过几个 knockout js 的 plugin ，但是前端这种 MVC 框架层出不穷，熟悉各种东西需要花时间吧，技能还停留在 Mongo + express + angularJS + NodeJS 阶段，对 bower, gulp ， yeoman 之类的非常有好感，但对新花样的前端 MVC 代码非常厌倦了。数据接口往往会把一些前端用不到的数据也吐给 json api 上来，个人觉得是一个安全隐患，但是不这样，前端的日子也不好过，真要做好权限控制，个人觉得前端的 MVC 中的 V 也要多做几套，否则那些页面元素只是隐藏啊，丑陋不堪。各种周边脚本一会是 grunt,一会儿是 gulp ，一会儿又是 webpack ，喜欢前后端分离的前端往往喜欢作死用最新的技术最新的版本，而自己又 hold 不住，线上各种问题。 2.前后端分离带来的好处。如果接口提供给多个终端用，比如手机，后端提供的接口标准化还是非常有用的。一套接口可以应付所有终端，以前前后端分离的时候接口的质量也没有太高。还有一个重大好处是部署的时候前后端分离部署，后端部署和前端部署各自部署各自的，没有耦合，但在前端用 MVC 框架下，本程序狗已经改不动一个完整的功能模块了，前端部分还要看到一遍业务 MVC 就感觉恶心，改不动。对于个人而言，工作量反倒变少了，只用自己写好测试格式好接口就行了，不依赖页面。 总之，痛点还是以前的 freemarker/velocity 和 jquery 太好用而新出的前端 MVC 框架喜欢挖坑；而我时不时喜欢做点东西，喜欢一个人做完整个功能，沟通太费事了，又目睹了前端 MVC 及其周边发布工具的挫样，哀其苦逼但又无可奈何。 |
 |
497
smalldragonluo 2016-08-12 19:59:14 +08:00
前后端分离之所以提出来，并且簇拥者甚多，肯定不仅仅是部门斗争的结果。毫无疑问，前后端分离后，前端的话语权有一定的提升，但这只是结果。
淘宝前后端分离的好处，有以下几点： 1. 当事物的粒度被划分得比较细，人员各司其职，注定会提升整体效率。这一切的前提是各环节之间的衔接必须顺利。前后端分离之前，频道页面的开发流程是这样的：前端和后端协商整个页面的路由；约定接口；前端写好页面，将 html 拿给后端，由后端写模板，这一阶段前后端衔接会有很大的沟通成本；然后预发（这一过程是比较长的），如果页面有问题，还得前端改好，让后端再次预发，这一直是开发过程中的痛点。 Node.js 让前端掌控了页面渲染，摆脱了这种困境。 2. 从体验上来讲，一般是同步渲染页面首屏， Java 端模板渲染页面后，前端往往又需要异步渲染剩余的数据（分页，瀑布流），这时候就存在两套模板，总体效率降低。使用 Node.js 后，模板语言统一，减少了不必要的开发成本。 3. 前端对页面的性能优化掌控能力增加，可以做很多事情，例如 BigPipe 。有人提到淘宝 CDN PHP 换 Node.js 是因为性能差，实际上之前的 PHP 性能差很大一部分是 PHP 版本过旧，还有一个原因是 fast-cgi 高并发和 Node.js 相比没有优势。 当然，劣势也显而易见：例如对前端要求变高，不专业的人员容易出现许多问题；增加了 Node.js 层，同机部署压力增加；许多监控，稳定性保障需要加强等。 |
 |
498
Markman 2016-08-12 23:11:46 +08:00 2
讨论好火热啊。
我从 2000 年开始用 HTML 写网页， 03 年开始用 ASP ， 07 年开始用 python 写网站。 现在后端用 Tornado(python)，前端用 vue+bootstrap+webpack ，很喜欢现在的开发方式。 从一开始就是自己一个人开发。 现在也是自己前后通吃，但即使是我自己一个人开发，我也是用前后端分离的方式。 没有什么酷炫的原因，只是这样做更加有序，效率更高而已。 1. 谁来负责页面渲染？ 界面可以由 JS 渲染，也可以由 Server 端渲染，界定不明确的话我自己都不知道应该写哪端的代码。 题主是倾向于在后端写，减轻前端的负担。 但是问题是，后端可以不处理页面，只处理纯数据，由 JS 渲染；但是反过来，但凡是稍微讲究一些体验的话，就没避免用 JS 来和界面打交道。 所以在我看来，答案很明显，界面和交互，交给 JS ；数据交给后端。 这种分工，项目更容易维护（即使是一个人项目）。 2. 为什么用 React ， jQuery+PHP 不是也一样吗？ 基于问题 1 的答案， Server 端已经不负责生成 HTML 了，所以如果用 jQuery 来拼接 HTML 的话，是很繁琐的。 于是就有了 React/Vue 这类的前端框架，可以将重复的代码逻辑封装为组件，用类似<input>这样加标签的方式，在页面中添加自定义的高级控件，而且 HTML/JS/CSS 都可以在一处定义（需要 webpack 协助），又进一步给项目带来了秩序。 再针对题主第 8 条附言发表一下看法： 1. 一个人知道整个业务。任何业务问题，马上解决。 前后端分不分离和和分工没有必然关系，我一个人也前后端分离，一个人也知道整体业务。 反而因为前后端分工明确，有问题更容易定位，解决效率更高。 2. 代码量少。同样的逻辑不需要写两遍（相比浏览器渲染而言）。 前后端分离了，后端没有展现逻辑，同样的逻辑才不需要写 2 遍。 如果你是指验证类的逻辑的话，确实前后端都写的现象也存在，但是也不是必须，牺牲体验的话，可以只由后台验证。 如果要 SEO ， React 火的一个原因也是同一份代码可以供后台渲染用，不需要写 2 遍。 3. 也能支持多端。/data 分 /data.json 和 /data.html 两种表现（ RESTful ） /data.html 也是多余的。 如果做 app/客户端也用 web 技术，也要利用服务器端提供的 data.html 吗？ 客户端更新了怎么办？服务器端同时存着所有版本的 data.html 模板吗？ 4. 简单。所有概念都来自 W3C 标准，没有那些私有的概念（我说的就是 Virtual DOM ） Virtual DOM 并不是强制需要理解的概念，只是用来解释 React 原理的，不知道 Virtual DOM 的情况下用 React 毫无障碍。 而且 React 也是在往 W3C 标准靠（ JSX 主要作用就是可以用接近 HTML 的写法来写 React ），相比直接用 jQuery ， React 封装好组件之后，用起来已经和原生 HTML 差不多了。 5. 省人力。多了 100% 的人力啊（分离需要两个人） 分离不需要 2 个人。 |
 |
499
int64ago 2016-08-12 23:24:43 +08:00 1
我居然又看完了，我之前就是前后端分离+全栈，现在工作了，于是就是个前端了，我觉得楼主观点太偏激了，而且讨论的时候完全侧重赞同自己观点的
每个人所处的场景和经历的事情是不一样的，所以很容易从自己的经验里直接得出一些结论，我个人的经历告诉我，不分离的设计就是一坨屎（大工程的前提下） 原因： 前后端不分离给我的感觉就是在人员水平参差不齐的时候很容易把项目代码搞的一团糟，然而项目的复杂度（ ERP/CRM 等系统）又必须招很多人来干 因此，导致的问题就是项目就是乱七八糟，而且越来越乱（乱到添加的代码格式对齐都不管了），员工的很多时间都是花在不该花的地方，比如填坑，而这些都可以从良好的设计上避免，而不是假设在项目的整个生命周期上每个开发人员都是有极高修养或者有严重技术洁癖 一旦项目出现不可控的情况，比较坏的情况是什么？当然是重构，而如果是前后端分离，重构工作会处理容易很多 如果前端用的模板杂糅在后端逻辑里，又是同步数据，又是异步数据，很难想想整个团队有人能有决心调动所有人搞重构这个事，因为此时重构的复杂度跟重新开发几乎无异 另外，从我的经历看，搞后端的人真的比前端轻松，我自己自认为是个全栈，其实更喜欢写后端 |
 |
500
shawngao 2016-08-12 23:33:27 +08:00
放下理念之争，一切以实用为准
|
Select Language