早几年前端还处于刀耕火种、JQuery独树一帜的时代，前后端代码的耦合度很高，一个web页面文件的代码可能是这样的：
这意味着后端的工程师往往得负责一部分修改HTML、编写脚本的工作，而前端开发者也得了解页面上存在的服务端代码含义。
有时候某处页面逻辑的变动，鉴于代码的混搭，可能都不确定应该请后端还是前端来改动（即使他们都能处理）。
前端框架热潮
有句俗话说的好——“人啊，要是擅于开口‘关我屁事’和‘关你屁事’这俩句，可以节省人生中的大部分时间”。
随着这两年被 angular 牵头带起的各种前端MV*框架的风靡，后端可以毋须再于静态页面耗费心思，只需要专心开发数据接口供前端使用即可。得益于此，前后端终于可以安心地互相道一声“关我屁事”或“关你屁事”了。
以 avalon 为例，前端只需要在页面加载时发送个ajax请求取得数据绑定到vm，然后做view层渲染即可：
|
1 2 3 4 5 6 7 8 9 10 11 |
var vm = avalon.define({ $id: "wrap", list: [] }); fetch('data/list.php') //向后端接口发出请求 .then(res => res.json()) .then(json => { vm.list = json; //数据注入vm avalon.scan(); //渲染view层 }); |
静态页面的代码也由前端一手掌握，原本服务端的代码换成了 avalaon 的专用属性与插值表达式：
|
1 2 3 |
ul ms-controller="wrap"> li ms-repeat="list">{el.name}li> ul> |
前后端代码隔离的形式大大提升了项目的可维护性和开发效率，已经成为一种web开发的主流模式。它解放了后端程序员的双手，也将更多的控制权转移给前端人员（当然前端也因此需要多学习一些框架知识）。
弊端
前后端隔离的模式虽然给开发带来了便利，但相比水乳交融的旧模式，页面首屏的数据需要在加载的时候向服务端发去请求才能取得，多了请求等候的时间（RTT)。
这意味着用户访问页面的时候，这段“等待后端返回数据”的时延会处于白屏状态，如果用户网速差，那么这段首屏等候时间会是很糟糕的体验。
当然拉到数据后，还得做 view 层渲染（客户端引擎的处理还是很快的，忽略渲染的时间），这又依赖于框架本身，即框架要先被下载下来才能处理这些视图渲染操作。那么好家伙，一个 angular.min.js 就达到了 120 多KB，用着渣信号的用户得多等上一两秒来下载它。
这么看来，单纯前后端隔离的形式存在首屏时间较长的问题，除非未来平均网速达到上G/s，不然都是不理想的体验。
另外使用前端框架的页面也不利于SEO，其实应该说不利于国内这些渣搜索引擎的SEO，谷歌早已能从内存中去抓数据（客户端渲染后的DOM数据）。
so 怎么办？相信很多朋友猜到了——用 node 来助阵。
直出和同构
直出说白了其实就是“服务端渲染并输出”，跟起初我们提及的前后端水乳交融的开发模式基本类似，只是后端语言我们换成了 node 。
09年开始冒头的 node 现在成了当红炸子鸡，包含阿里、腾讯在内的各大公司都广泛地把 node 用到项目上，前后端整而为一，如果 node 的特性适用于你的项目，那么何乐而不为呢。
我们在这边也提及了一个“同构”的概念，即前后端（这里的“后端”指的是直出端，数据接口不一定由node开发）使用同一套代码方案，方便维护。
当前 node 在服务端有着许多主流抑或非主流的框架，包括 express、koa、thinkjs 等，能够较快上手，利用各种中间件得以进行敏捷开发。
另外诸如 ejs、jade 这样的渲染模板能让我们轻松地把首屏内容（数据或渲染好的DOM树）注入页面中。
这样用户访问到的便是已经带有首屏内容的页面，大大降低了等候时间，提升了体验。
示例
在这里我们以 koa + ejs + React 的服务端渲染为例，来看看一个简单的“直出”方案是怎样实现的。该示例也可以在我的github上下载到。
项目的目录结构如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
+---data //模拟数据接口，放了一个.json文件 +---dist //文件构建后（gulp/webpack）存放处 | +---css | | +---common | | ---page | +---js | | +---component | | ---page | ---views | +---common | ---home +---modules //一些自行封装的通用业务模块 +---routes //路由配置 ---src //未构建的文件夹 +---css | +---common | +---component | ---page +---js | +---component //React组件 | ---page //页面入口文件 ---views //ejs模板 +---common ---home |
1. node 端 jsx 解析处理
node 端是不会自己识别 React 的 jsx 语法的，故我们需要在项目文件中引入 node-jsx ，即使现在可以安装 babel-cli 后（并添加预设）使用 babel-node 命令替代 node，但后者用起来总会出问题，故暂时还是采纳 node-jsx 方案：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
//app.js require('node-jsx').install({ //让node端能解析jsx extension class="crayon-s">'node-jsx').install({ //让node端能解析jsx extension">
这意味着后端的工程师往往得负责一部分修改HTML、编写脚本的工作，而前端开发者也得了解页面上存在的服务端代码含义。 有时候某处页面逻辑的变动，鉴于代码的混搭，可能都不确定应该请后端还是前端来改动（即使他们都能处理）。
前端框架热潮 有句俗话说的好——“人啊，要是擅于开口‘关我屁事’和‘关你屁事’这俩句，可以节省人生中的大部分时间”。 随着这两年被 angular 牵头带起的各种前端MV*框架的风靡，后端可以毋须再于静态页面耗费心思，只需要专心开发数据接口供前端使用即可。得益于此，前后端终于可以安心地互相道一声“关我屁事”或“关你屁事”了。 以 avalon 为例，前端只需要在页面加载时发送个ajax请求取得数据绑定到vm，然后做view层渲染即可：
静态页面的代码也由前端一手掌握，原本服务端的代码换成了 avalaon 的专用属性与插值表达式：
前后端代码隔离的形式大大提升了项目的可维护性和开发效率，已经成为一种web开发的主流模式。它解放了后端程序员的双手，也将更多的控制权转移给前端人员（当然前端也因此需要多学习一些框架知识）。
弊端 前后端隔离的模式虽然给开发带来了便利，但相比水乳交融的旧模式，页面首屏的数据需要在加载的时候向服务端发去请求才能取得，多了请求等候的时间（RTT)。 这意味着用户访问页面的时候，这段“等待后端返回数据”的时延会处于白屏状态，如果用户网速差，那么这段首屏等候时间会是很糟糕的体验。 当然拉到数据后，还得做 view 层渲染（客户端引擎的处理还是很快的，忽略渲染的时间），这又依赖于框架本身，即框架要先被下载下来才能处理这些视图渲染操作。那么好家伙，一个 angular.min.js 就达到了 120 多KB，用着渣信号的用户得多等上一两秒来下载它。 这么看来，单纯前后端隔离的形式存在首屏时间较长的问题，除非未来平均网速达到上G/s，不然都是不理想的体验。 另外使用前端框架的页面也不利于SEO，其实应该说不利于国内这些渣搜索引擎的SEO，谷歌早已能从内存中去抓数据（客户端渲染后的DOM数据）。 so 怎么办？相信很多朋友猜到了——用 node 来助阵。
直出和同构 直出说白了其实就是“服务端渲染并输出”，跟起初我们提及的前后端水乳交融的开发模式基本类似，只是后端语言我们换成了 node 。 09年开始冒头的 node 现在成了当红炸子鸡，包含阿里、腾讯在内的各大公司都广泛地把 node 用到项目上，前后端整而为一，如果 node 的特性适用于你的项目，那么何乐而不为呢。 我们在这边也提及了一个“同构”的概念，即前后端（这里的“后端”指的是直出端，数据接口不一定由node开发）使用同一套代码方案，方便维护。 当前 node 在服务端有着许多主流抑或非主流的框架，包括 express、koa、thinkjs 等，能够较快上手，利用各种中间件得以进行敏捷开发。 另外诸如 ejs、jade 这样的渲染模板能让我们轻松地把首屏内容（数据或渲染好的DOM树）注入页面中。 这样用户访问到的便是已经带有首屏内容的页面，大大降低了等候时间，提升了体验。
示例 在这里我们以 koa + ejs + React 的服务端渲染为例，来看看一个简单的“直出”方案是怎样实现的。该示例也可以在我的github上下载到。 项目的目录结构如下：
1. node 端 jsx 解析处理 node 端是不会自己识别 React 的 jsx 语法的，故我们需要在项目文件中引入 node-jsx ，即使现在可以安装 babel-cli 后（并添加预设）使用 babel-node 命令替代 node，但后者用起来总会出问题，故暂时还是采纳 node-jsx 方案：
|
