本文已参与「新人创作礼」活动，一起开启掘金创作之路。
本文写于2018年5月，当时我司使用的基础前端框架是knockoutjs+ejs，而三大框架的潮流已经形成，使用老框架在资源、效率、人员招聘与培训上面的缺陷越来越明显，在2017年末已开始考虑更换架构，为了选择最适合当时团队的现状的架构，特整理了此文协助梳理思路。
背景
目前最主流的前端框架。
angular官网：angularjs.org/
React 官网：facebook.github.io/react/
Vue官网：cn.vuejs.org/
对比了这几个框架，认为vue.js最适合我们当前的情况。主要理由是其学习曲线平缓，而且中文社区强大，更针对国内的情况。相比而言，其他框架的英文社区更活跃，但现在我们的英文水平还比较薄弱。
vue官方也提供了对比其他框架
争论~ vue作者参与的撕逼 知乎：怎么说服公司将knockout.js换成vue.js？
目前使用的框架
目前我们使用的框架是knockoutjs，它算是最早的MVVM框架，当初选用这个方案是因为要兼容IE8，现在不是必要的了，因而有了更多的选择。
带来的便利
- 兼容IE6+！！！！
- 使用模板来绑定数据
- 监控数据变化来触发事件
- 利用组件来实现功能复用
- 组件可以递归嵌套使用
- 多层循环foreach时，能访问到每一层的数据
parents[0,1,2,3..] - 灵活的绑定上下文
$data、$element、$parent、$root... - ....
存在的问题
- 没有生命周期，无法得知数据绑定与渲染何时完成
- 技术有些旧，生态系统不够丰富，社区不够活跃，现成的解决方案少，新员工一般都没有使用过这个技术，需要重新学习
目前的前端架构与开发环境
- 整体架构是以nodejs为基础，使用express作为web服务器，proxy作为代理中间件，ejs作为模板（对于ejs做了少许修改，在处理中将body中的script标签放到的最后，将对应页面的less编译成css格式写入html文件中，主要使用include来实现复用，和打包时按照参数添加对应的内容），使用less作为css预处理器，增加了less解析器作为express的中间件，打包的过程是使用request去获取经过ejs处理后的html，使用fs模块在生成对应的文件。
- 开发模式是将一个页面拆分成若干个子页面，放在同名的文件夹内，使用ejs的include引入主页面
带来的便利
- 引入less并参与到整个开发过程中，定义了一整套变量，便于通用UI的形成，在独立页面的开发中，也可以使用这些变量，方便维护
- 拆分个按功能拆分成各个子页面，任何地方都可引用，便于复用
- 将引用的js库集中管理，在打包时根据参数去引用该页面需要的js
存在的问题
- 静态资源（css\js...）没有合适的管理，无法保证用户用到的都是最新发布的，总需要清缓存才能解决问题
- 会加载一些不必要的js库
- 各个通用的js\css库之间没有合并压缩，图片也是零散的没有合并，浪费了许多资源
- 缺少相应的脚手架辅助，重复工作较多
- 开放方式过于灵活，不利于形成统一的风格
- 对于关键部分埋点、代码风格检测、自动化测试方案没有支持
- ...
目前方式的总结
需要保留的部分
- 便于配置的反向代理，用于解决跨域和服务端地址切换
- 全局的css变量定义，通用样式方案
- 模块复用方案
- 更好的打包方案
期望解决的问题
- view层框架生命周期
- 更佳的用户体验，提升加载性能
- 静态文件缓存问题的处理
- 静态文件合并与压缩处理，图片合并处理方案
- 更严格的开发方式，统一编码风格
- 在开发过程中加入测试方案，在开发环境能自动化测试，单元测试，白盒
- 在开发过程中关键部分埋点，能利用规则在打包后的程序自动化测试，e2e测试，黑盒
- 有更多的常用组件支持
- 多个项目间共用组件、模块方案，版本管理方案
- 尝试用户体验更佳的富文本方案、文档播放器等
需要更换框架的理由
- 需要跟上时代的潮流，es6+已被广泛使用，可以大大简化代码，提高开发效率，babel也可以将es6+编译成es5，能够支持绝大多数浏览器
- 需要更好的过渡方案，更快的加载、渲染速度，更佳的用户体验，性能提升
- 必须解决静态文件缓存问题
- 合适的自动化测试方案
选用vue的理由
- 学习曲线平缓，而且中文社区强大
- 国人使用较多，针对国内的具体情况的问题有更多的资源
- 其具体表现不输于其他框架
- 较完整的生态系统
- 更多的前端开发人员有相关开发经验，招人更容易上手
- 单元测试方案 karma
- e2e测试方案 nightwatch
