尝试与改变
如果你没有尝试过前后端分离的工作流程，那么可以先试想一下这样的流程改变：
把流程从&PM：&我要这个功能&后端：&这个先找前端做个模板&前端：&模板做完了&后端：&我来对接一下，这里样式不对&前端：&我改完了&后端：&功能交付&PM：&春节要加这个活动&后端：&这个先找前端改个模板&前端：&模板做完了&后端：&我来对接一下，这里样式不对&前端：&我改完了&后端：&功能交付&
变成PM：&我要这个功能&前端：&我要接口&后端：&接口完成了&前端：&我来对接一下，功能交付&PM：&春节要加这个活动&前端：&需要增加接口&后端：&接口完成了&前端：&我来对接一下，功能交付&
由此可见，前后端分离的主要概念就是：后台只需提供API接口，前端调用AJAX实现数据呈现。
现状与分歧
作为一名前端开发人员，我们应该尝试一些新颖的技术，完善每一个细节性的问题，不断突破自我。虽然前后端分离已经算不上什么新颖的技术或思路，但是目前很多后台开发人员甚至前端开发人员都没有接触过。
据我个人的了解，如果在一个部门里，部门人员全是后台开发人员，前端的一些页面也是由后台人员完成的，那么前后端分离对于他们而言可能是一片未知的领域，项目大多是前后端强耦合的，甚至不存在前端的概念。
在不重视前端的公司或部门，不了解前后端分离这也无可厚非。在我刚进入一个全是后台开发人员的部门的时候，整个部门就我一个前端，我刚开始的主要职责就是负责项目前端页面的制作和JS功能的实现，虽然部门有前后端分离的意识，但都不知该如何去实践。在那时，部门的后台人员认为前后端分离就是后台不再需要写HTML和JS了，可以交给前端来做了，然而这只能叫做前后端分工。
以上讲述的是一种情况: 不了解前后端分离，也不知如何去实践的。下面还有一种情况：了解前后端分离，但不想去尝试的。
针对第二种情况，很多人也做过相应的解释，其实这就涉及到&前后端分离的利弊&问题。很多后台人员会认为自己所做的那一套没有问题，即便后台套用前端html也是司空见惯，一直是大势所趋，后台MVC框架也是这么推荐使用的，很合理。这时候前端开发人员在部门中的话语权往往是不够的，或者认为后台开发人员的意见永远是对的，没有主观性。
相反，也有可能是后台开发人员非常推荐前后端分离，而前端开发人员不想去实践的。这时候前端会认为后台开发人员在瞎折腾，之前前后端不分离项目做起来都很顺利，分离了反而会给自己带来额外的工作量和学习成本，而这就取决于前端的技术能力和见识了。
当然，这也是我个人认为的前后端分离所存在的一些现状和分歧所在。
场景与要求
对于前后端分离的应用场景，不是所有的场景都适合，但是大多数项目都能够通过前后端分离来实现。
由于我主要从事企业级后台应用的前端开发工作，个人认为对于后台应用的开发来说，前后端分离带来的利是远大于弊的。
大多数后台应用我们都可以做成SPA应用（单页应用），而单页应用最主要的特点就是局部刷新，这通过前端控制路由调用AJAX，后台提供接口便可以实现，而且这样的方式用户体验更加友好，网页加载更加快速，开发和维护成本也降低了不少，效率明显提升。
同样的，在展示类网站和移动APP页面中前后端分离也同样试用。前后端不分离的情况下，服务端要单独针对Web端做处理，返回完整HTML，这样势必增加服务端的复杂度，可维护性差，而web端需要加载完整的HTML，一定程度上影响网页性能，这对于移动端性能为王的地方非常的不友好。
随着前端技术的发展和迭代，前端MVC框架应运而生，利用目前主流的前端框架，如React、Vue、Angular等我们可以轻松的构建起一个无需服务器端渲染就可以展示的网站，同时这类框架都提供了前端路由功能，后台可以不再控制路由的跳转，将原本属于前端的业务逻辑全部丢给前端，这样前后端分离可以说是最为彻底。下面是一段前端控制路由的代码：
'use strict'
export default function (router) {
router.map({
component: function (resolve) {
require(['./PC.vue'], resolve)
'/m/:params': {
component: function (resolve) {
require(['./Mobile.vue'], resolve)
component: function (resolve) {
require(['./PC.vue'], resolve)
subRoutes: {
'/process/:username': {
component: function (resolve) {
require(['./components/Process.vue'], resolve)
前后端分离的实现对技术人员尤其是前端人员的要求会上升一个层次，前端的工作不只是切页面写模板或是处理一些简单的js逻辑，前端需要处理服务器返回的各种数据格式，还需要掌握一系列的数据处理逻辑、MVC思想和各种主流框架。
优势与意义
对于前后端分离的意义我们也可以看做是前端渲染的意义，我主要总结了下面四点：
1.彻底解放前端
前端不再需要向后台提供模板或是后台在前端html中嵌入后台代码，如：
&!--服务器端渲染 --&
&option value=''&--请选择所属业务--&/option&
{% for p in p_list %}
&option value="{{ p }}"&{{ p }}&/option&
{% endfor %}
这是前后端耦合的，可读性差。
&!--前端渲染 --&
&template&
&select id="rander"&
&option value=''&--请选择所属业务--&/option&
&option v-for="list in lists" :value="list" v-text="list"&&/option&
&/template&
export default {
lists: ['选项一', '选项二', '选项三', '选项四']
ready: function () {
this.$http({
url: '/demo/',
method: 'POST',
.then(function (response) {
this.lists = response.data.lists // 获取服务器端数据并渲染
上面是前端渲染的一段代码，前端通过AJAX调用后台接口，数据逻辑放在前端，由前端维护。
2.提高工作效率，分工更加明确
前后端分离的工作流程可以使前端只关注前端的事，后台只关心后台的活，两者开发可以同时进行，在后台还没有时间提供接口的时候，前端可以先将数据写死或者调用本地的json文件即可，页面的增加和路由的修改也不必再去麻烦后台，开发更加灵活。
3.局部性能提升
通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升。
4.降低维护成本
通过目前主流的前端MVC框架，我们可以非常快速的定位及发现问题的所在，客户端的问题不再需要后台人员参与及调试，代码重构及可维护性增强。
心得与体会
一路走来，项目一个接着一个，从一开始的后台控制路由、后台渲染页面到现在的前端控制路由、前端渲染数据，工作流程和方式都发生了很大的变化。每当遇到下面情形的时候，我都会为前后端分离带来的优势而感慨一番：
项目一开始制作前端页面的时候，我不再需要后台给我配置服务器环境了
项目的前端文件可以在需要调用后台接口的时候丢进服务器就好了，完全不需要事先放进去
增加一个项目页面需要配置路由的时候不再需要让后台同事给我加了，自己前端搞定
前端文件里不再掺杂后台的代码逻辑了，看起来舒服多了
页面跳转比之前更加流畅了，局部渲染局部加载非常快速
页面模板可以重复使用了，前端组件化开发提高了开发效率
等等。面对快速发展的前端，我们应该去适应其带来的工作方式和流程的改变，目前的前后端分离的工作方式必然是今后的趋势所在，作为一个前端开发人员，我们应当承担这个普及前端新知识和改变现状的职责。
只有尝试了才知道适不适合，只有切身体会才能辨别谁是谁非，本文并非推崇一定要前后端分离，而是希望大家在合适的应用场景下去尝试前后端分离，在丰富经验的同时或许也会擦出火花。
阅读(...) 评论()Nodejs在前后端分离中的作用与地位应该怎么去理解？ - CNode技术社区
本人在学习前后端分离的时候发现了一幅图(传说这是淘宝的)：
图片取自：
看完这幅图就出现了几个问题：
NodeJs自身不也可以做JAVA的东西吗？为什么还要要去用JAVA来处理业务逻辑什么的？
NodeJs在这幅图里面是一个中间层的作用，可是图上面的功能点的 “转发数据，串接服务” 与 “路由设置，控制逻辑” 就不是很理解，具体其实是什么意思？能举个简单例子就更好了；
NodeJs是怎么与前端框架共享路由的？是用Jade，Ejs等模板的意思吗？
前端也有MV*的框架啊，本人觉得AngularJs就很好的前端MVC框架啊，为什么还有由NodeJs来控制路由和模板？
前端数据可以通过AJAX等异步请求获取啊，为什么要通过NodeJs来渲染？是有什么好处吗？
以上有什么理解不对的地方欢迎大神们指出与讨论，谢谢大家指导。
1、nodejs对于数据的运算、逻辑处理，及数据库的操作不如java方便、快捷、稳定
2、你自己也说了nodejs是起中间层的作用，即根据客户端不同请求来做相应的处理或渲染页面，处理时可以是把获取的数据做简单的处理交由底层java那边做真正的数据持久化或数据更新，也可以是从底层获取数据做简单的处理返回给客户端
3、什么叫与浏览器共享路由？
4、关于前后端MVC的区分，自己去找资料、书籍看吧
5、如果客户端再请求页面时，服务器端可以把相应的数据在服务端给加载好，这样就免去了页面加载后再重新请求数据的过程，节省请求次数
不是与浏览器，不好意思，是与前端。
NodeJs与前端框架共享路由？你是不是理解有误。nodejs是创建路由规则，控制整个web的访问逻辑， 供前端使用。这是我个人理解
其实这是个前端工程化的问题~
5…这个问题，主要是可以减少页面请求，更主要的是seo和cdn的需要
好好学好node，做个全栈会对web有新的认识，那时候就是前后端融合了
有几点给你讲清楚:
第一：nodejs是后端语言,别和前端扯上关系,这个相当于做一嗰java里面的servlet核心,或者是.net的c#,只不过是用了javascript的语法减轻程序员多语言编程的复杂性。
第二：阿里这样的模型可以看出MVC的逻辑，当然，大家都说为什么nodejs可以实现java的还要加多一层，阿里经营了那么久一直用java，肯定不可能立马用node全程替代掉java，这是一嗰技术沉淀的问题，当然，nodejs运算能力比较低这个问题解决的方法也是很多，这也是阿里选择的方法之一。
第三：nodejs路由的实现逻辑是把前端静态页面代码当成字符串发送到客户端，他们并不是可以互相共享，简单理解可以理解为路由是提供给客户端的一嗰api接口，只不过返回的数据是页面代码字符串而已。你可以就把Nodejs当成跟前端交互的api。
总得来说，nodejs的作用在mvc中相当于C（控制器）.应该可以说是Nodejs的响应能力较强吧简单形容
受教了，谢谢
考虑这个问题的出发点要充分结合业务需要及现状，技术本身并不是限制。
CNode 社区为国内最专业的 Node.js 开源技术社区，致力于 Node.js 的技术研究。
服务器赞助商为
，存储赞助商为
，由提供应用性能服务。
新手搭建 Node.js 服务器，推荐使用无需备案的Web开发前后端分离 - 简书
Web开发前后端分离
作者：zjruan
日期：关键词：前后端分离，nodejs， thrift描述：本文讨论的范围是web开发，前端：前端开发工程师（html，css，js...），后端：后端web开发工程师（java，C#...）
近年来互联网发展迅速， 乘着“互联网+”的风，各行各业都在与互联网结合，产生了大量的web开发岗位，IT 行业悻悻向荣。web开发分为多个岗位，可以大致分为 前端、后端、测试、运维。今天我们来聊一聊前后端的那些事。
一、传统的web开发模式
前端是近几年才兴起的一个职业，web发展初期是没有前端工程是的，网页只是向用户单向的传递信息，只是一些简单的html，后来加入了css以及一些简单的 js ，用于美化页面与添加一些用户交互。个人感觉前端的高速发展是伴随着 Ajax 技术的普及而开始的。html5 、css3 ，越来越多的网站从页面开始想web 应用化的转换，导致网页的制作难度越来越高，用户体验已经页面的美观要求越来越高，使得前端开发工程师逐渐分离成为一个独立的职业。
目前，在大部分中小公司，前端实际上是处于一个附属的阶段（依附于后端），前端只写一些 html，css，以及一个交互js，然后将写好的的 html 交予后端套页面。后端拿到 html 页面后将其转换为后端模板，如 velocity，smarty，jade 等等。可能还会写一些数据加载js。所以基本上每个后端都会一些 js，他们最怕的是浏览器兼容性。
html2jade.png
这种模式的好处是对前端要求“很低”，以应对现在稀缺的前端资源。坏处也很明显，主要如下：
前后端的一部分工作（html-&vm...）重复了，降低了工作效率【后端模板统一以vm为例， vm是 java velocity模板的文件】。
后端转vm的过程中不能保证100%的转化，有时会遗漏一些东西，比如少了个闭标签。
有时会出现三不管文件，前后端都不想维护它，这个文件就会变的越来越烂，越来越没人维护它的恶性循环。比如一个 js 文件，第一手是一个前端写的，写了一些基础的事件绑定以及交互逻辑然后就交给后端了，第二手是后端在里面添加了一个他们的代码，用户行为统计或者其他一些内容。不知道你们是怎样的，反正一旦有人改了我的东西，我便不想维护它了，慢慢的这个文件就会变的越来越烂。作为一个前端工程师，不要指望一个后端按照你的规范去写前段代码，在他们眼里，这不是他的职责，才不管这代码写的烂不烂呢，至少我以前在做后端开发的时候是这样想的。
前端很难搞出一套漂亮的代码,原因很简单，或者后端有时也会去修改它，或者dom掌握在后端的手里，前端很难去优化它（dom结构），或者前端工程化（注：近期遇到的问题，版本控制会在文件名后追加MD5摘要，但是相应的要修改页面中的文件引用地址，vm的控制权不在我们手上，让后端频繁的改这个是不可能的）上一些问题，反正就是各种各样的问题，最后，前端代码就是一坨乱麻。好在前端足够简单，我们理一理还不会出什么大的幺蛾子。
因为前后端这种工作的交集，有时会互相甩锅，甚至出现一些对立。
前端vs后端
二、前后端分离
前后端分离的最终目的是问题提高工作效率。
传统的web开发模式，后端一定程度上依赖与前端页面的开发，而前端一定程度的依赖后端的数据接口的开发。整个开发过程中部分阶段处于串行状态。而前后端分离的核心思路就是打破这种串行，使得前端与后端能够并行开发，从而提高整体的工作效率。
很多公司都在尝试前后端分离，根据公司的情况，分离的程度也不同。个人感觉，前后端分离的火候，一定程度上依赖该公司前端团队的实力。
阶段1、页面分离
得益于 nodejs 的成功，前端可以不必安装后端开发环境，便可以直接编写后端模板，这样前端便直接提供的vm文件，而不需要后端去转页面，节约一部分后端的工作量。这种模式下，前端开发工作量会稍微的增加一些，但不会太多，当你熟悉后端模板后，几乎不会有什么额外负担。前端团队需要搭建一套自编译系统，将vm 自动转化为html，并刷新浏览器。主要node包：gulp、velocity、browser-sync
阶段2、数据接口分离
数据接口分离，就是开发之前，前后端约定好一个接口，大家都基于这个接口开发。类似于app开发。这样前端就可以与后端接口解耦了，在后端接口还没有开发完成时，也可以开发数据交互js。主要工具：
阶段3、展现层分离（展现层由前端维护）
这个也算是前后端分离的究极体了。在一部分公司，PHP承担着前后端分离的重要角色，有些人会有疑问，php不是后端语言么？对，但是在这个阶段，PHP 只负责 MVC 模式下的 View 和 Controller 层，Model 层交由Java 或C#。关键一点，这里的 PHP 是由前端团队维护，如果交由后端开发去维护，便失去了前后端分离的意义。也因为是前端去维护，我们随其自然的将这里的 PHP 换成了 NodeJS。该阶段对前端是一个考验，没有做后端开发的的同学入手比较困难，团队里至少有一个对mvc模式较为熟悉，且熟练掌握NodeJS 或者 PHP，在他的帮助下，最终每一个前端成员都能够独立的去写 view 和对应的 Controller。当做到这一步的时候，前后端也就真正的分离了。我们直接完全是接口化开发，并且有需要的话，针对后端接口编写单元测试。
前后端分离架构图.png
三、前后端分离Demo
基于阶段3的一个demo。该阶段的一个难点在于web 与 services 的数据交互。好在facebook开源的一个项目
为我们解决了这个问题。Demo中使用了Nodejs 的Express搭建web服务，使用 Thrift 生成 Node 的client和server的接口文件。
javascript */
var client = thrift.createClient(Calculator, connection);
router.get('/', function (req, res, next) {
client.add(10, 100)
.then(function (response) {
res.render('index', { title: 'Express + Thrift', desc: '：1+1=' + response });
/* jade */
block content
p Welcome to #{title}
p Thrift demo #{desc}
/* Nodejs server */
var server = thrift.createServer(Calculator, {
add: function (n1, n2) {
var result = n1 + n2;
console.log("localhost:9090");
server.listen(9090);
Demo Result.png图解基于node.js实现前后端分离
图解基于node.js实现前后端分离
首先庆祝 [w3ctech长沙站第12期技术分享会] 圆满成功，感谢组织方邀请~
因为会上出了个意外，ppt图片全部丢失，只好对着白板跟大家交流了半个多小时。由于我做演讲不喜欢写太多的文字，没有图片的情况下讲漏了一些内容。这篇文章是我在会上分享内容对照ppt进行地整理。
首先从一个重要的概念“模板”说起。
广义上来说，web中的模板就是填充数据后可以生成文件的页面。
严格意义上来说，应该是模板引擎利用特定格式的文件和所提供的数据编译生成页面。模板大致分为前端模板（如ejs）和后端模板（如freemarker）分别在浏览器端和服务器端编译。
由于当场有一部分同学对node.js并不是很了解，这里补充一下node.js的相关知识。官网上的给他的定义事件驱动、异步什么的就不说了。这里借用朴灵书上的一张图来解释一下node.js这个玩意的结构。如果懂java的同学可以将其理解为js版本的jvm。
浏览器一般包括渲染器和js脚本引擎，以chrome浏览器为例，用的webkit内核的渲染器，V8的脚本引擎，而node.js用到了v8引擎。总而言之它就是一个js的运行环境，就好比浏览器的F12调试工具，只不过node.js没有DOM和BOM。
这张图描述的是node.js周边的一些信息，比如npm这个出色的包管理器和cnode社区以及github，都在一定程度上促进了node.js的繁荣，提供了技术保障。
大公司通常都是技术的风向标，例如google的angular、facebook的react现在都很火。这里只列了3个大公司当作例子。淘宝的中途岛架构就不用说了，国内node.js的先行者朴灵就来自淘宝。去哪儿也出了个应该叫做“QTX”的技术框架。360月影带领的75团队出了个基于ES6/ES7的web服务器框架——thinkjs，当时我们技术总监很看好，但是由于鄙人没有时间学习ES6再加上插件不够丰富，所以还是选用了较为成熟的Express。
言归正传，这个表格列出了我所接触过的3种前后端分离的开发方式。
第一种是最常见的使用java之类的后端语言模板，SEO友好，缓存利用率和减轻浏览器渲染负担方面都比较好，最大的问题就是模板文件的耦合度太高，出了问题谁都不想来解决，前端人员看不到数据，后端人员不懂页面，模板文件就像是一个烫手的山芋。
第二种是目前我们项目移动端的实现方案，利用angular这种框架（angular的指令可以看成是前端模板）和nginx这种反向代理服务器，让前后端彻底解耦，只通过ajax交互数据。这种方案和前一种的优缺点刚好相反。前端模板的性能始终是个问题，尤其是在移动端，更尤其是在低端的移动设备上。
最后一种是新项目使用的用node.js做前端服务器，将前端的职责从浏览器划分到了模板这一层，解决了以上所有的问题，不过确实也有新的问题，这种问题稍后再分析。
当然全栈开发在小型项目中也是非常适合的。对于传统的jsp/php开发来说，全栈开发的沟通成本更低，开发人员能更容易理解整个功能模块，从而更好的还原产品的设计。尤其现在出现的以js语言为基础的全栈开发：meteor和MEAN技术，更是使得前后端开发用一种语言直接搞定，再配上Mongodb，数据从浏览器到数据库都无需转义直接使用，还不用写sql，开发成本又大大降低。
这次搭建node.js服务器用到的一些插件。
鼎鼎大名的express不用多介绍了，轻量级web服务器框架。
用handlebars模板引擎也属巧合，因为express4默认就是它，handlebars不愧为“弱逻辑”的模板引擎，主张的是减少模板逻辑，尽量只用变量和分页，基于它的设计理念，我只扩充了两个helper。具体文章：
superagent的使用还是因为express4，因为它的测试代码用的是supertest，supertest是基于superagent，所以用了superagent来转发和发起请求。superagent还是太弱了，长连接都无法建立，还是推荐request插件。
restfuleAPI就没什么好介绍了，前端服务器与浏览器，前端服务器与后端服务器都是用的这一套规范，基本上就是url指向资源，增删改查又具体的请求方法表示，状态码表示结果等~
gulp打包工具，webpack研究了很久，发现每增加一个页面都要修改配置文件，这个太蛋疼，遂放弃。
如果这次分享主要是讲怎样将node.js做为前端服务器来实现前后端分离的话那也没什么好讲的，看看淘宝UED的文章就好了。前后端分离其实最大的问题是带来沟通成本的上升，具体来说就是接口的定义和调试。在上图的传统开发流程中，接口的定义会放在接口服务器中，然后前后端各自根据接口文档造假数据进行本地调试，之后进行联调。这个环节就是前后端开始撕逼的时候了，这个参数不对，那个返回值不对，总之很浪费时间。接下来看这个问题在我们项目中是怎么解决的~
前后端因为接口撕逼的问题一直存在，作为保守主义的我相信迭代开发，所以第一步做的只是增加了一个mock服务器。这个服务器的神奇之处就是根据接口文档自动生成假数据，实现了接口即API，前端同学再也不用把数据写死进行测试了。没办法，谁叫我是前端开发，首先想到自己人，嘿嘿~当然这个只在一定程度上有利于前端开发，后端的接口和文档不一致联调时也会出现问题。怎么办？
偶然在破浪大神的博客上看到老马的一篇专门讲前后端分离的文章，其中一个重要的概念就是契约测试也叫双边测试吧。核心概念就是为了解决远程联调的问题。对前后端的参数都进行校验，要求大家按照接口文档进行开发。受其启发，加入json-schema规则，实现了对http请求的参数校验，谁不按规矩来谁改。
这个redmine是我们最早的接口文档管理器，除了记录和查看功能再无其他作用。
swagger号称世界最流行的接口文档服务器，界面美观，插件也还比较多，可以针对后端语言直接生成测试代码。不过部署的时候始终没玩懂，而且yaml格式不如json习惯，放弃了它。
这就是现在我们项目上用的文档服务器和mock服务器，基于MEAN技术实现的服务器，基本功能：
利用mockjs插件，可以动态生成随机数据
基于json-schema对接口参数实行校验和接口测试，并保存测试状态和接口响应时间。
简单的json编辑器
带有登陆校验功能，可登陆后进行接口调试
mock服务器按照api服务器来响应请求，接口更新时自动更新
node.js是前端工程师的翅膀，而插上翅膀是变成天使还是变成恶魔？这个要看能不能解决的使用它时带来的问题了。
首先前端的工作量毫无疑问地会增加，但沟通成本会降低。
node.js单线程的服务器稳定性确实不够好，不过代码的健壮性和完善的日志可以有效的规避。
回调。这个问题解决方法就太多了，node.js的q/async模块以及ES6/ES7。
node.js调试。虽然我一直排斥IDE，但不得不承认webstorm在调试上确实很方便。我用的node-inspector也还凑合，界面类似chrome开发者工具，看上去挺熟悉的。
如果对于后端程序员，更加应该拥簇node.js了。接口整合的工作交给了前端服务器进行处理，同时和前端耦合度大大降低，工作量和工作效率都减少了。
心得体会有两点
node.js的使用虽然有一定的学习成本，但对于前端开发人员还是很友好的。而且前端使用node.js的话，无论是技术含量还是工作量都会有所提升，从而提升了岗位的重要性。当前端开发人员能创造更多价值的时候才有资格要求更高的薪水~
工作中建议少提建议多给可行性方案，同时进行技术预研而不是写个简单的helloworld。
可能有人说你介绍的这一套东西这么复杂，用起来太麻烦了，还不如面对面沟通。
对于这样的质疑我只能用腾讯高级UI工程师余果在《web全栈工程师的自我修养》中讲到的一个例子。有一次他电面一家小公司的前端负责人问他怎么管理代码时，对方说直接用ftp上传，同时抱怨手下人老是更新错代码，又问他为什么不用svn或git，他说还不如手动更新方便。
这个故事的道理就是我面对质疑的回答~
作者：[亚里士朱德]
本文原创发布于慕课网 ，转载请注明出处，谢谢合作！
相关标签：
分享即可 +1积分
请登录后，发表评论
评论（Enter+Ctrl）
评论加载中...
评论加载中...
JSP工程师，多年大型国际项目开发经验。
WEB前端工程师，擅长PC端以及移动微信端开发。
js全栈工程师，熟悉node.js、mongoDB。
开发者头条top10专栏作者
个人博客：yalishizhude.github.io
作者的热门手记
Copyright (C)
All Rights Reserved | 京ICP备 号-2前后端分离之前
在前后端分离观点出现之前，我们往往都是后端直接使用后端模板引擎渲染出html页面，当然这个时候对于前端来说是异常痛苦的，他们不仅需要学习后端模板引擎的语法还得配置后端的开发环境。
前后端分离的萌芽
为了让前端无需配置后端开发环境和学习后端的模板引擎，一个简单的前后端分离方案出现了，它就是前端编写静态页面，然后通过ajax从后端拉取数据，然后渲染页面即可，而渲染方法往往就是拼接字符串或者使用js的dom操作。
前端模板渲染的进化
拼接字符串的方法对于后期维护来说是灾难性的，根本没有可读性。而js操作dom需要大量的代码量，对于开发效率来说是低效的。所以前端模板引擎应运而生，使用模板引擎往往只需要引入一个js即可，学习门槛也非常低，渲染出html之后，只需要替换特定的dom元素即可。
前端工程化
在前端进入ajax拉取数据，通过模板引擎渲染页面的时期之后。前端还存在一个亟需要解决的问题，就是多个页面之间往往存在重叠的部分，一开始前端是copy重叠部分代码到每一个页面，弊端也显而易见，就是这重叠部分一旦需要需改的话，每个页面都会被牵连到，这工作量是巨大的，这个时候前端打包技术出现了，能够让前端像后端一样页面可以引用，js和css可以合并。
Angular，React，VUE
前端圈子最热的三个框架莫过于Angular，React，VUE，从使用难度来说vue入门门槛最低，所以虽然最晚出现，但是普及相当的快。
正所谓存在即合理，那么这三个框架的出现是为了解决什么问题呢？
模板渲染前端路由能够组件化开发（需要配合打包工具）更好的维护
世间没有完美的事物，这三个框架也不例外：
哪怕是最简单的vue也是有一定的学习门槛要使用它们进行组件化开发，还需要额外学习打包工具的使用对于小工程来说，工作量还加大了，没体现出开发优势
一点点想说的
对于管理后台开发来说，就不要用前后端分离了，只会白白增加工作量。对于临时的，或者以后无需频繁修改的页面，也考虑一下有没有必要上前后端分离。对于小型应用或者小公司而言，考虑一下有没有必要使用vue等框架（注意前后端分离还是必须的），因为越使用这些框架的高级部分，就意味着对团队的技术能力要求越高，还需要考虑以后能否找到有能力维护的人。商业产品，业务为主，不要为了技术而技术每种技术都有自己存在的意义，本文只是作者个人观点，不是说这样做就是对的，请按实际环境确定自家产品的技术平台。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：54288次
积分：1349
积分：1349
排名：千里之外
原创：78篇
转载：58篇
(4)(4)(3)(3)(2)(12)(3)(1)(7)(2)(1)(4)(2)(5)(7)(3)(7)(9)(2)(1)(2)(2)(5)(6)(4)(4)(7)(7)(11)(3)}