如今前端新技术层出不穷，且各有特色和使用场景。那么，在众多框架中，如何避免错误，如何选择框架？比如框架设计和实践过程中，对框架设计的考虑，在对某些技术点应用场景的处理，踩过的“坑”我们来看看。
1. 构建前端业务框架前的思考
    程序员在设计业务框架时很容易陷入技术思维的陷阱：用最新最牛的技术，要做大做全。如果只是执着于这两点，就会忽略成本，适用范围，使用者的满意度等这些重要因素。要理解开发框架的价值，一个框架的价值就是基于它开发出的产品质量，开发过程要注重高效，开发成本要低；要明确开发框架的目标，对于开发目标要分为业务目标，技术目标和人事目标三部分；要定义框架适用的场景或范围。当我们理解了框架的价值，明确了开发的目的，我们就需要定义适应场景和范围，我们需要对产品目标用户的环境进行确定，这对开发，测试以及产品三个层面都是有意义的。产品预测和定位用户群体，开发用来预算开发周期和成本，测试用来确定用例的边界和测试的范围。
2. 技术选型与实用性分析
    框架开发技术选项首先要考虑的是提供什么功能才能让业务系统开发人员更加方便开发。SPA作为用户体验好的一种产品类型，用户体验是框架开发需要考虑的一个重要因素。要选定的基础层次结构和实用选型思路：首先是开发规范，无论是从代码清洁度、可维护性、健壮性、还是团队配合效率，我们在开发框架时的第一步都是制定和确定团队的开发规范。
3. 构建脚本执行生命周期和开发流程
    脚本执行生命周期，即是将脚本执行过程拆解成一系列的顺序阶段。目的是为了对整个应用做更好的控制，让复杂繁多的代码更清晰。同时也便于开发人员理解整个脚本执行过程，对后期性能优化也非常有帮助。框架分为两个周期：应用生命周期和页面生命周期。框架应用生命周期——框架开发人员在开发过程中定义好每个阶段职责。当我们定义的阶段职责明晰后，后期性能优化就有了一个非常清晰的路线图；页面生命周期——框架开发人员负责定义好这个流程，业务开发人员负责用业务代码来填充这个流程。和应用生命周期一样，对性能优化也有重大意义，同时给业务开发人员编写也提供了一个根据页面生命周期编写的开发流程。
4. 前端插件化，组件化，服务化，模块化的应用
    组件化、插件化、服务化和模块化并非为前端而提出，在后端存在已久，都非常成熟。而他们的目的就是“高内聚”和“低耦合”。
1）引入组件化，可以获得以下好处：
●开发方便，无需关注组件的依赖关系
●测试方便，写完组件即可测试。
●职责清晰，独立开发，功能高内聚
●接口规范，维护性更高
●框架层直接提供大量公共组件，缩短业务系统开发时间
●灵活组合，方便调用，效率更高
2）插件化的好处：可以这么概括插件化，就是不破坏原有程序和生命周期，现在流行的框架中用到极致的就是Webpack的插件系统。
3）服务化：可以这么概括服务化，将一些特定功能由提供方以服务的形式提供出来，应用方不用关注其实现方式，只需关注调用功能即可；服务化在后端很好理解，前端如何理解？每个特定功能都能看成一项服务，可以是组件，插件，以及单独的功能模块；把这些功能都封装部署在一个特定的站点，业务系统需要用的时候直接异步调用这些服务的地址即可，不用关注其依赖和实现过程。在SPA框架中，把一些功能组件和模块当成服务，业务系统不需要预先引进，只需要在用的时候调用相应地址就可以了。
4）模块化：模块化就是功能拆解，将小功能内聚，拆解系统耦合。也就是说拥抱模块化就能避免在代码中嵌入依赖关系。