推荐关注
› Meteor
› JSLint - a JavaScript code quality tool
› jsFiddle
› D3.js
› WebStorm
推荐书目
› JavaScript 权威指南第 5 版
› Closure: The Definitive Guide
› Closure: The Definitive Guide
这是一个创建于 3039 天前的主题，其中的信息可能已经有所发展或是发生改变。
原文在 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
 |
501
Markman 2016-08-12 23:44:20 +08:00
貌似题主其实问的是：渲染应该是后端搞还是前端搞？
|
 |
502
zhangkaizhao 2016-08-12 23:48:48 +08:00
断人财路，犹如杀人父母。
|
|
503
zhangkaizhao 2016-08-12 23:50:05 +08:00
一想起一个页面要发起 N 个 HTTP API 请求就头疼……
|
 |
504
moonou 2016-08-13 00:04:10 +08:00 via iPhone
想起一个前端还要去改生成的模版代码就头疼
|
|
505
zhangkaizhao 2016-08-13 00:14:50 +08:00
想起前端也是一大堆模板代码就头疼
|
|
506
moonou 2016-08-13 01:41:37 +08:00 via iPhone
想起我不用去改前端代码就开心
|
|
507
moonou 2016-08-13 01:52:30 +08:00 via iPhone
补充一下，楼主拿一种稳定的模式所开发出的产品去对比一种新生的模式开发的产品并不是很合适，况且这种新模式处于一种发展阶段，并未处于稳定。同样，也并未觉得分离模式的出现是前端的“阴谋”，它之所以出现并且还在发展中，正是因为老模式的瓶颈让人们看到了它的可能性。同理它的出现也并未妨碍你们使用传统方式开发，选用什么样的方式开发一直都是个人的自由，作为一个合格的程序员，应该有自己的主观意识。
|
 |
508
FrankFang128 OP @moonou 赚钱不算阴谋，但是大部分人不是根据需求选框架，这是事实。
|
|
509
moonou 2016-08-13 06:54:40 +08:00 via iPhone
@FrankFang128 不理解不是根据需求选框架，一个项目，就我们公司而言，所要选用的框架和技术路线，都是要前端后端和产品一起根据业务逻辑来讨论的。赚钱不算阴谋可以理解为“前端是为了高工资才提出前后端分离”吗？一个项目用不用前后端分离是 team leader 决定的，的确，选择新技术而踩坑，保留老技术而稳定，都是他们该考虑的，如果前端工作量提升，那么工资提升也是不争的事实。
|
 |
510
guodont 2016-08-13 09:43:04 +08:00
PHP 是世界上最好的语言。
|
 |
511
ragnaroks 2016-08-13 10:03:55 +08:00  1
我也觉得应该只有全栈,没有前后端,但是我希望将不重要的数据交由客户端去处理,能转嫁给用户的成本一定不要自己抗
|
 |
512
zhouquanbest 2016-08-13 12:47:08 +08:00 1
这个问题好火，忍不住也来 BB 两句。
我是个移动开发，同时也做些全栈的事，想从非专业角度看看 记得最早去豆瓣实习时，被 Leader 喊去写后端， template 用 mako ，帮前段实现简单通用的模板，然后渲染出一点数据丢在模板上让他们自己用，感觉这就是道完形填空题，前段留下空，我给他渲染数据。。。。 后来自己创业也沿袭这样干，但接触 AngualrJS 后发现用模板给前端传数据好蠢，同时也根本不需要模板啊， ag 这么方便，全都自己造就好了，就当自己是个 app ，接口自取。同时这样也节省了开发量，后端只负责数据接口，“前端”（ Android iOS Web ）自己玩。 我不知道这里有多少全栈工程师会有这样的体验，当混着写 python java css html 时，人特别烦躁，但是只单独写一部分时，整个人都变得清爽了。虽然前后端移动端都是我写，但将他们分离时，异常舒服。 创业失败后我在雪球混，以前自己搞量级小没发现的问题都出来了。比如后端接口的问题，如果只做数据接口，前端会很痛苦，可能为了渲染一个页面需要调用 4 5 个接口，又是异步状态，如何设计交互，如何快速响应都成了问题。但如果后端去帮前端封装，把几个接口合体甚至说直接给前端的类似模板的数据，比如第一行显示什么，第二行显示什么，那和当年直接丢个 html 出来有什么区别呢？？？ 现在的解决方案是，后端依旧只给数据接口，但是前端自己用 node 搞一层代理处理数据，相当于前端把一部分代码写到了 server 上，这样还能简单解决快速迭代不更新 app 的问题。 这种方式目前感觉弹性最高，也解决了前后端撕逼的问题，但其实前端也在写 server ，那到底还是不是“前后端分离”呢？ 总之我觉得讨论什么架构依旧没意义，关键是要看需求场景，工程师的任务是以尽可能小的成本解决问题。 |
 |
513
foru17 2016-08-13 15:10:32 +08:00
刚好参与了今年阅文起点这边的项目改造，门户站这变走的就是 Node 做中间层框架机渲染，后端只提供数据，好处真的是大太多了。
一个是解放了两个部门的人力，术业有专攻，原来的前端（偏重构）同事用本地构建工具(基本上就是本地模拟了一套 node server)来专心写页面，完全控制了 view 端还原和体验就好了，直出逻辑也全面接管（对于门户类站点直出需求很多)，后台的同事专心写数据相关和业务逻辑，提供 API 就好。让后端接手套模板，最后出来的乱七八糟的代码简直了，两边都不讨好。 说到前端的话语权和控制权这块，一开始我们还想争取接管一点业务逻辑，直接被 PK 让我们安静地做渲染框架机就好，毕竟开发资源主要还是在后端技术部门，前端也没这个人力来做，但是在路由管理、轻量的模板直出逻辑这块，我们还是能够做到了拓展。 |
|
514
FrankFang128 OP @foru17 你这不就是前端往前后端融合方向走，后端做服务吗？
说明你们也知道前后分离是错的。 |
|
515
FrankFang128 OP @foru17 你们用 client render 还是 server render
|
|
516
FrankFang128 OP @foru17 你是腾讯的？据我所知，「直出」是腾讯的前端才会说的。
直出背后的逻辑就是，前端受不了只用 JSON API 来本地渲染页面，为了用户体验和性能，回到 Web 的正轨：后台渲染。 |
|
517
FrankFang128 OP 没错， 客户端渲染注定是小众。
|
 |
518
janrykk 2016-08-14 00:21:04 +08:00
前后端分离真正的分离应该是前端仅仅只需要开发一系列的组件，后端自己配数据，组装出页面，这才是最高效的方式
|
 |
519
haven007 2016-08-14 00:27:57 +08:00
|
|
520
FrankFang128 OP @haven007 这说的是新技术，谁说新技术一定是客户端渲染
|
 |
521
yishenggudou 2016-08-14 13:14:40 +08:00
@janrykk 同意
|
 |
522
lyris 2016-08-14 13:47:15 +08:00 via Android
@janrykk 这也是我一直非常喜欢 bootstrap ， ace 这种前端库的原因，既能适配手机，又能满足功能，界面还快，现在每次看到新框架做的花里胡哨的页面，花了非常多的时间做出来，居然连手机也不能自适应，各种浏览器兼容问题，页面源码全是 js 就觉得这绝逼要玩玩啊，如果是微博网页版和微博聊天，纯 js 渲染我觉得是正道
|
|
523
lyris 2016-08-14 13:51:51 +08:00 via Android
但是大多数网站并不是单页面应用，却非得搞成单页面，或半单页面(肯定也有蹩脚的页面路由),我觉得就是走上邪路了
|
 |
524
lujiajing1126 2016-08-14 15:30:53 +08:00 via iPhone
就说一点。前后端分离跟 nodejs 有啥关系？和是不是全栈有啥关系？感觉楼主学艺不精啊。。
还有工作经历不代表能力好不。。很擅长刷题，进大厂不也很容易？工程问题和技术能力还是有区别的 |
 |
526
peterleung 2016-08-15 11:41:20 +08:00
爱分不分
|
 |
527
evil4u 2016-08-15 13:55:38 +08:00
前后端分离对于大公司才需要，小公司初创公司用最成熟的技术就可以了，验证业务才是主要原则。
但是楼主，请问在规模化的业务场景下面，几十个甚至上百个前端对接后端团队，这个时候前后端分离，用 node 做中间层来渲染业务， api 来控制接口，那效率是不是可以提升？前端控制交互逻辑，数据展现逻辑，后端控制业务逻辑。分工明确，前端不用等后端接口， mock 数据，同时开发，是不是效率能提升？ 一切新技术都是为了效率。 而且你也说了大公司喜欢搞这个，那是因为大公司的体积决定了他迈步子和小公司不一样。 blabla 说了一大堆，你的意思其实是“不要为了分离而分离"吧？ |
 |
528
binaryer 2016-08-15 17:59:07 +08:00
https://vpip.net/?from=v2ex 就没用前后端分离，而是 freemarker, 看了这个帖子后打算把 ajax 动态生成的部份改用 handlebars 实现
|
 |
529
iamxz 2016-08-15 19:33:03 +08:00
我们公司正在做前后分离的尝试，但是也是分场景的。
1 ，支持分离的场景。目前再分离 “个人中心”，类似后台，这块业务服务多，页面杂乱，又有几个团队负责，项目合并又很困难，分离迫在眉睫，大家要求声很高。现在渲染这块拿到前端去做，后端只需要关注自己的服务就可以了。我是支持这部分业务做分离的。 2 ，不支持分离的场景 还有个是纯展示的详情页。鉴于是纯展示，所以 html 代码还有 js 尽可能做的最快的展示，后端的模板又比较成熟文档，并且不会经常改动。所以这部分不太适合前后分离，但是在做业务分离的尝试。业务组件化。首先加载展示最重要的内容，其他次要的可以在浏览器渲染后 跟随用户的鼠标滑动 慢慢展示。这样既可以提高网站的负载，又不至于因为某个业务故障导致整体故障。 具体分离不分离，采用什么样的技术，都是针对业务场景，开发人员的技术素质决定的。分离这事情本来就没有对与错，只是为了解决不同的问题。 |
 |
530
hellokittyer 2016-08-16 08:38:31 +08:00
ctrl+f 了下，没有用户"体验"二字？
|
|
531
FrankFang128 OP @hellokittyer 前端渲染有效降低用户体验
|
 |
532
shijingshijing 2016-08-17 10:44:53 +08:00
@murmur 无限加载，瀑布流，固定的 Header/NavBar 还有各种动态闪烁效果都是我最讨厌的。无限加载总给人一种拉屎没拉干净的感觉，最不能忍；瀑布流如果是图片展示类我觉得还有存在的理由，现实是很多网站不管三七二十一就来一个瀑布流；固定 Header/NavBar 像一排赶不走的苍蝇呆在屏幕上方，抢占了有限的屏幕资源，真要用到顶部菜单的时候， iOS 轻触上面的状态栏， PC 直接按 Home 键都能快速跳过去；动态闪烁不说了，除了引起你的注意无其他卵用。上面喷的几个，可能不是前端的锅，像动不动就瀑布流这种，应该是产品经理脑残。
|
 |
533
mlyknown 2016-08-22 18:27:01 +08:00
1 、做 webapp 或者客户端渲染必须要前后端分离。 2 、大点的项目中间加成 nodejs ，前后端职责更加明确，个人觉得开发效率更高。 3 、一般的 web 网页的确传统的 mvc+jquery 一套就足够了。
|
|
534
FrankFang128 OP |
|
535
FrankFang128 OP @mlyknown http://v2ex.com/t/299785#reply81 不复用 JSON ，复用 HTML
|
 |
536
yvcold 2016-08-25 14:57:06 +08:00
我想知道这个图是用什么软件画的，楼主能告知吗 @FrankFang128
|
|
537
FrankFang128 OP @yvcold Balsamiq
|
 |
538
hyingzi 2016-08-26 12:42:42 +08:00
前后端分离指的是架构，不是人员分工……
|
|
539
FrankFang128 OP @hyingzi 现在的前后分离架构，哪个不是人员也要分工的？
|
|
540
binaryer 2016-08-31 14:29:14 +08:00
看了大家的讨论 https://vpip.net/?from=v2ex 已经部分实现前后端分离
|
 |
541
yxwqwgz 2016-09-08 16:21:11 +08:00
@FrankFang128
@scott1743 搅成一团的话，不够专业，难成大器。分离是实实在在能够提高生产率的东西。比如福特汽车发明的流水线作业，就大幅提高了汽车的生产效率，把竞争对手都虐出了翔。亚当斯密在《国富论》也提出过分工的概念，建议读一读再来谈也不迟。 js css html 分工我还真没仔细考虑过，但是也未必不可行。流水线上只做一个动作都可以， js,css,html 能不能分工，我持保留意见。 |
 |
542
loadinger 2016-09-14 10:29:07 +08:00
做个题:
当你要做一个 app,一个 pc web,一个 mobile / wechat,功能８０%重复,分离与不分离,工作量差距是多少? |
|
543
FrankFang128 OP @loadinger 全用 HTML 不就好了。
|
 |
544
zhangv 2016-12-12 10:07:04 +08:00
我觉得这应该是“全栈”们普遍的想法
|
|
545
FrankFang128 OP @zhangv 我是前端
|
 |
546
def1984 2017-02-06 17:27:47 +08:00
html 可能是软件行业最糟糕的一项发明。
|
 |
547
Sypher 2017-12-27 15:25:02 +08:00
支持
|
 |
548
morcble 2018-02-10 09:44:25 +08:00
同意楼主的大部分观点，
前后端分离是软件业发展的必然趋势和结果，分离的前端的代码可以不做修改的同时在 PC 和 App 上运行，对于节省产品开发成本有极大优势。 但是前端已经发展到过于炫技，已经忘记了追求最小成本去实现业务需求或者业务变更的初衷。 另外前端和后端分别由不同的人去开发，错误定位困难，无论接口，调试都会引起互相推诿的情况，会极大增加研发成本和周期。 15 年初次接触完全的前后端分离开发模式，我一直在想怎么去掉这些缺点，保留这些优点。逐渐有了一些实现的想法， http://cnautosoft.com 这个产品希望能帮你解决这些疑问，让前端美工和业务开发分离，一个人负责从前端到后端的所有实现。 |
 |
549
wzj92712 2018-07-16 11:35:50 +08:00
现在来看 这个问题
有定论了么 |
 |
550
wanguorui123 2018-07-26 11:15:42 +08:00
至少这些情况下需要前后端分离：
1、n 端开发做前后端分离还是有必要的 2、强交互网页做前后端分离还是有必要的 3、为了用户体验减少白屏次数还是有必要的 4、减少服务端渲染压力还是有必要的 5、规范前端代码管理还是有必要的 |
|
551
FrankFang128 OP @wanguorui123 你说的是代码分离吧，我吐槽的是人员分离
|
 |
552
avenger 2018-11-30 10:56:22 +08:00
有定论了么
|
|
553
FrankFang128 OP @avenger 定论是大部分公司还是搞人员分离，即使是错的
|
 |
554
wxiao333 2018-12-04 10:15:46 +08:00
很经典的帖子，过几年再回头看
|
 |
555
chiu 2019-04-22 00:02:51 +08:00 via Android
在找一些资料翻到了本帖，学习了~
|
 |
556
jiayong2793 2019-08-22 09:53:40 +08:00
产品：管你前端后端，我让你加的功能加了没？
|
 |
557
xianyukang 2019-09-21 20:58:03 +08:00
个人理解的
前后端分离说的不是技术结构, 而是将职责或任务分离, 如果前端没什么复杂性, 普通后端也能写出这种效果, 自然不需要前后端分离 当前端任务比较重的时候, 本来就需要一个独立的前端职位, 后端要学的要做的够多了, 还要负责写前端怕不是要累死 . |
 |
558
pingyuan9259 2020-04-23 19:14:09 +08:00
我是这么想的：等你到了三胖的那个位置，你们国家想不想分离都是你说的算；等你到了你们公司大老板这个位置，你们公司想不想分离都是你说的算；等你到了你们技术部门一把手一手遮天这个位置，你们部门想不想分离也是你说的算。。。所以说，我们上头说这个东西要分离，那我们就按照分离去做，那不分也更有不分的做法，你既然是个高手的话，为啥要纠结分不分离呢，不是应该分离也牛逼不分离照样牛逼吗？而且啊，总强调纯前端、后端这种工种的区别，就代表你内心都已经把这个职业给分离，问题是天下程序员不都应该是一家吗。一个合格的程序员应该分前后端吗？只是阴差阳错的正好做了前端、正好做了后端而已，如果想换工作内容，随时换就好（前提是合格程序员，野鸡不算）。
别再纠结这些奇奇怪怪的问题了，有时间多做点能够提高团队效率的事情，同事门天天加班，你不心疼吗？ |
 |
559
charlie21 2022-02-24 11:34:04 +08:00
按照渲染方式，前端技术被分成客户端渲染（ SPA / 带路由的 web app ）相关的部分 and 服务器端渲染（直出 ssr 同构）相关的部分，后者虽然也是前端，但更 “靠后”
参考 https://baurine.netlify.app/2019/08/16/website-architectures/#有 next.js 但不一定有网络安全方面的考虑 比如 发送 react form csrf 后端和前端的分界线并不那么明显，尤其是网络安全的部分。在一些 react 教程，对于表格提交的部分，我用 react form csrf 搜索只看到零星的建议，在那些前端入门教程里我更是没看到这方面的内容。这是网络安全 101 的内容，是网络安全必须考虑的责任。 |
 |
560
3dwelcome 2022-03-06 01:13:59 +08:00
这问题很经典啊，我以前一直不喜欢前后端分离，因为我觉得核心数据都在后端，用代码统一管理，输出 HTML 给前端非常方便。
但是渐渐的，随着项目复杂度提升，后端要加入很多模板，和 JS 去控制页面单独一些 DOM 的逻辑，变得越来越复杂。 一旦复杂后，代码的可维护性直线下降。最后只能变为前后端分离，不得不说，真香。 |
 |
561
pengliheng 2022-03-22 10:48:02 +08:00
正确的晋升路线就是 前端 -> 后端 -> 全栈 -> 架构 -> CTO
之所以要分离是出于公司管理的角度来考虑的, 毕竟码农地位比较低, 是没法做出这种改变公司结构的决定的, 将每个工作岗位拆分成随时可更替的螺丝钉, 只做前端 /后端, 对职业发展是非常不利的. |
 |
562
sudoy 2022-05-10 20:05:45 +08:00
楼主这个观点有一定的道理，但还是有些狭隘了。有的应用场景使用前后端分离这种理念能大大提高生产力，在移动设备开发上也有很大促进作用。
|
Select Language