接下来我会在不同阶段去分析前端架构的一些细则和前后端交互的要点，逐一剖析
前端架构概念
web应用复杂度的增加，特别是单页面应用的风靡。组件化，工程化，自动化成了前端发展的趋势。或者说一线的互联网公司就是这么做的。通常说架构，指的是架构模式，自创的架构很少。了解架构模式，才能心有余力的应对项目的发展。
前端工程的阶段
第一阶段： 库/框架选型（解决开发效率）
Animate.css
jQuery
vue.js
underscore.js
React.js
Backbone.js
Bootstarp
zepto.js
jade
normalize.css
compass
Angular.js
第二阶段： 简单构建优化 整体渲染
选择构建工具，对代码进行压缩，校验，之后再以页面为单位进行简单的资源合并。
所有页面代码放到了一个html文档中，适合个人实验室项目。
新建一个文件，快速的验证某个功能或者开发某个组件，再移植到开发环境中。
优点：开发速度快，执行过程清晰
不足：不容易分工合作
第三阶段： 结构行为表现分离，JS/CSS模块化开发
结构：HTML
行为：JavaScript
表现：CSS
解决维护效率
js的模块化方案
ADM/CDM/UMD/ES6 Module
css的模块化：less，sass。
第四阶段： 插件
对需求的响应快，更快的实现页面的UI样式，前端更快捷的实现页面布局，使前端把重点放在业务逻辑上
第五阶段：模块
主要以下几种模块规范
（1）AMD规范（用户客户端，RequireJS实现）
（2）CommonJS规范（用于服务端，Browserify实现）
（3）EcmaScript 6 Module
js
现在ES6已经在语言层面上规定了模块系统，完全可以取代现有的CommonJS和AMD规范，而且使用起来相当简洁，并且有静态加载的特性。
1.用++Webpack + Babel++将所有模块打包成一个文件同步加载，也可以搭乘多个chunk异步加载；
2.用++System+Babel++主要是分模块异步加载；
3.用浏览器的< script type="module">加载。
css
虽然SASS、LESS、Stylus等预处理器实现了CSS的文件拆分，但没有解决CSS模块化的一个重要问题：选择器的全局污染问题。
按道理，一个模块化的文件应该要隐藏内部作用域，只暴露少量接口给使用者。而按照目前预处理器的方式，导入一个CSS模块后，已存在的样式有被覆盖的风险。虽然重写样式是CSS的一个优势，但这并不利于多人协作
资源的模块化
Webpack的强大之处不仅仅在于它统一了JS的各种模块系统，取代了Browserify、RequireJS、SeaJS的工作。更重要的是它的万能模块加载理念，即所有的资源都可以且也应该模块化。
资源模块化后，优点是：
依赖关系单一化。所有CSS和图片等资源的依赖关系统一走JS路线，无需额外处理CSS预处理器的依赖关系，也不需处理代码迁移时的图片合并、字体图片等路径问题； 资源处理集成化。现在可以用loader对各种资源做各种事情，比如复杂的vue-loader等等； 项目结构清晰化。使用Webpack后，你的项目结构总可以表示成这样的函数： dest = webpack(src, config)。
第六阶段：前端工程化
前端工程化项目分为3大模块
- Node服务，提供数据代理，路由，和服务器渲染，通过restful api和后端通信。
- web应用开发，专注于web交互体验。
- 前端运维：包含构建，测试，部署及监控等。 静态资源与Node端衔接：
- 前端静态资源构建工作与Node服务相互分离，Node服务在开启的过程中会读取前端构建生成的静态资源映射表。
- 静态资源映射表的生成：
- 预编译：ES6语法转义，css预编译器处理，源码质量审查，测试
- 模块依赖解析
- 压缩，静态资源版本号
第七阶段：组件化
组件组件并不是一个新兴的概念， 但是React.js强制组件化，所以看来才那么新颖。它把JavaScript，CSS，HTML重新打包。 从UI拆分下来的每个包含模板(HTML)+样式(CSS)+逻辑(JS)功能完备的结构单元，我们称之为组件。
单一职责原则：一个类应该只有一个发生变化的原因。
组合/聚集复用原则：尽量使用合成/聚合，而不是使用继承。
鼓励遵循下面几条“约定”：
- Ajax请求从Node端代理，而非具体后端服务。
- 鼓励将JavaScript、CSS、HTML视为前端领域的“汇编”。
- 重视前端页面状态管理，推荐的方案有Redux、vuex及MobX等。
- 强调组件化，面向组件集开发。
- 项目的脚手架，来搭建项目的开发环境。
