基本前提：成本和效率
实现目标的成本和效率
现实遇到问题
- 这个技术很好，我先学几个月，然后再动手做
- 高手什么轮子都是自己造
衡量标准
- 通过良好的架构设计，能够真正有效的控制整个项目的复杂度
- 最终产品完成的品质，设计的还原度，可感知效能和稳定性
团队协作的成本和效率
首先你要通过自己的实践，然后调研，你必须要说服团队去用
后续迭代的成本和效率
这个方案它真正的可以提高可维护性，适应产品需求的快速变化和发展
选择的原则
库的选择
- 扩展语言能力的，Immutable.js
- 一些基础功能的，Lodash
- 解决一些兼容问题的，Core-js
- 还有一些少量成熟的一些组件，iScroll
缩小依赖范围和向稳定方向依赖
妥适性原则
一切要从实际出发，避免过度的去实现，引入一些暂时用不上的机制到项目中，最后项目变得很重。
每多依赖一个库就会增加一些不可控的复杂性。当这个库不稳定的时候，就会发生冲突或者出现一些 BUG。这种问题是在开发过程中会经常碰到，往往一出现这种问题，你是很难去发现和 DEBUG。
奥卡姆剃刀定律
- 选择的库其实功能越单一越好，一次只做好一件事，不要用一个大而全的库
- 一个设计得好的库和框架，它接口是很简洁的、很直接的
- 引入一个库或一个框架，它其实不是为了解决一个问题，它最好能解决一类问题
- 针对问题的实质，切实有效的解决我的痛点
- 避免引入很多无形的机制
可替代
依赖反转原则，对它进行解耦
主框架的选择
没有唯一法则
现在世界上没有独一无二的选择。
拥抱未来
确实应该多关注技术发展的趋势。只要是新的技术出来了，那它一定有它的那个点，你不一定非得在自己的项目中去用，但你应该需要扩展自己的技术视野，至少需要去了解它的。
经验价值高
如果当多个选项都满足的情况下，考虑学习和使用某一个框架的经验是不是具有长效价值。
架构上的优势为重
- 不能看体量和性能这些指标
- 也不能单纯的考虑学习成本和文档好坏这种东西
- 主要看它的模式设计上体现的优势
