- 体验类：包含大量交互，同时用户体验很重要。比如 GMail, 支付宝收银台、淘宝购物车等等。
- 功能类：包含大量交互，以功能为主，体验不是第一位的。比如后台系统、认证流程等。
- Web Apps 的开发，前端投入了大量人力，但前端资源依旧存在潜在的瓶颈（比如新增加一条业务线时，很可能无前端去支持）。现有前后端配合的开发模式，沟通协作成本偏高，可维护性不够方便。在现有的研发模式下，前端自身的价值点也很难体现出来（花了大量时间在业务上，但得到的认可不多）。
- 最核心的问题，依旧是前后端的解耦：如何让前后端的工作彼此更独立，如何让更合适的人做更合适的事，把事情做得更好。
- 对于体验类，目前业界有很多新兴的解决方案：Backbone, Ember, Knockout 等等，包括 YUI 的 App framework 等。这些解决方案，都希望后端专注于提供 REST 接口，其他的都交给前端来搞定。
- 对于功能类的，目前业界解决方案依旧是比较老的一套，比如 GWT 等，包括 ExtJS 也是希望能让后端搞定一切。
二、体验类应用的框架要解决的问题
我们知道了自己的产品所属的类型，也知道了每一种类型业界已有的一些解决方案。是不是引入这些成熟的解决方案就可以了？实际的应用场景要复杂很多。要知道任何一个开源框架都有他的适用范围，不可能跟自己的应用100%匹配。举例说明，以下这些通讯层的需求是比较常见的：
（1）统一拦截http请求，转换请求报文格式（json转xml等）
（2）接口超时或者异常则上报日志
（3）统一拦截http响应，非法JSON解析异常进行日志上报，转换响应报文的数据格式（xml转json等）
（4）添加统一的请求头部
（5）html5分块上传的特殊处理
如果我们的MVC框架选型为backbone，要满足这些需求我们不得不去修改backbone的通讯层源码。如果这种需求场景过多，我们就得频繁的修改源码，最终代码将变得难以维护。引入框架必将失去一部分灵活性，这是代价。记得不久前，infoq上看过一个facebook的前端工程师的视频，他对前端趋势的部分观点，我比较认同：前端未来的趋势应该是去框架化。每个公司都应该根据自己的产品类型，打造属于自己的框架。当然在这个过程中我们可以吸取优秀框架的思想，甚至对开源框架进行必要的裁剪，复用核心功能。在架构层面我们通常至少要解决以下问题：
1、模块化
2、视图与数据解耦
3、视图与视图解耦
4、健壮的通讯层
5、DOM操作
6、工具库
7、业务层代码的水平拓展
8、减少重复代码
9、静态资源的版本管理
10、语法检查、自动打包
三、为体验类应用打造框架
模块化。AMD（require.js、curl.js）、引入命名空间
视图与数据解耦，可引入模板引擎比如：underscore的template、jquery Template、自定义模板引擎（139邮箱的Repeater）
试图与视图解耦，可引入backbone的事件机制，使用trigger、on切断视图之间的直接调用
健壮的通讯层，建议自己封装通讯层。通讯层需要具备以下功能：
1、路由功能。接口可配置，业务层只需传递接口名称即可获取接口绝对路径，并发送ajax请求，是否需要跨域由通讯层自行解决。
2、拦截请求，统一设置请求头部，将报文转换为接口需要的数据格式
3、容错能力。设置超时时间避免浏览器锁死。捕获error事件，并上报日志
4、拦截响应，校验接口返回的数据格式，报错则上报日志。
DOM操作。引入开源JS库，jQuery当仁不让。
工具库。underscore、自定义业务工具库（手机号码加86、邮件地址解析手机号码等）
业务层代码的水平拓展。新增需求，只需按照规范创建视图层与模型层，根据需要调用公共组件即可完成交互
减少重复代码。抽象各业务模块的共性，组件化，业务层只需调用组件专注于业务，从而提高代码的复用率。
静态资源的版本管理。可为每一个文件生成MD5值，页面引入静态文件时URL后加上MD5值，文件有更新只需重新生成MD5值即可。
语法检查、自动打包。可采用ant调用jar包（jslint、compiler.jar）
近期我会分别整理出每一环节的部分源码，方便自己记忆。
四、参考资料
