要问我迄今为止用过最多的是哪个 JavaScript 库，毫无疑问是 jQuery，但是 jQuery 并不是一个 framework，它是一个 library，一个伟大的 library。
Framework 是什么？ A software framework provides a standard way to build and deploy applications。Framework 最重要的特点就是以可重用的方式构建应用程序，而且是在特定场景的约束之下。在这个定义之下，前端的 framework 真的是有点多如繁星（同后端相比）。
CSS framework
-
bootstrap
-
purecss
-
semantic-ui
-
foundation
-
bulma
-
...
JavaScript framework
-
reactjs
-
angularjs
-
vuejs
-
riot
-
emberjs
-
donejs
-
canjs
-
...
可选项变多，如何选择？
随潮流，跟风选，这可能是很多人的选择方式。
做 CMS bootstrap 是首选，angular 火用 angular，react 流行用 react，vuejs 很简单，拿来撸一撸。当然如果只是写着玩，为了观摩而实践，选哪个无可厚非。但在实实在在的项目中，对团队成本、公司利益有重大影响之下再做选择就需要做到细思而后决。
Bootstrap 是 css framework 中当之无愧的王者，在大部分后端人员不懂 CSS 的年代，bootstrap 让那些只会写后端的程序员也具备了构建漂亮 UI 的能力，但是现在 bootstrap 在类似 CMS 这种复杂的内容系统已经不是一个必要或者最佳选择了：
-
class 名称冗余，语义性差
-
css 浸入性强，覆写困难
-
html 结构不简洁表达性差
-
基于 jquery
正因为 bootstrap 有这些问题，才有不少新秀后来居上。
semantic-ui 正如其名是个语义化的 css framework，html 结构能恰如其分的表达视图，而且 css 名称语义性非常明确，易学易用，并提供了大量的 ui component，这点与 bootstrap 不同，bootstrap 很多 component 都来自第三方。
bulma 虽然只是一个 css framework (No JavaScript)，但其简洁、美观、语义化、mobile-first 的特点迅速赢得了很多拥趸，并且提供了常用的站点布局方案，几乎可以一键完成官网等特定网站的布局。
很多公司 angular 的项目还如火如荼的跑在 angular 1.x 上时，angular 突然宣布 angular2 不兼容 angular 1.x 了，现在 angular 已经出到4，升级就相当于重写了。我亲自见过有团队在仅仅只有一个页面的 application 用 angular 实现：选几种支付方式，然后提交付款，生产环境每日上百万的访问。杀鸡焉用牛刀。
react 写 ui component 是够爽的，但是 react router 是个什么货谁用谁知道，全栈都用 react 生态的是不是跟着官方一起踩坑才过来。
vuejs 很简单，入门容易上手快，多人(3人以上)协作 vuejs 项目如何规范，组件数目迅速达到几十上百时 component 如何组织？
emberjs 又笨又重，很多人都不会喜欢，但是就有估值10亿的公司全线产品都用的是 emberjs，他们哪里来的勇气？
诚然，每个 framework 都有各自的使用场景，各有优缺点，但是选择之前你真的想好了么？
那该如何选？看场景，谋定而后动：
-
投入时间做到必要的了解
-
评估成本，能力成本，人力成本，时间成本
-
快速实践试错
这是从坑中学来的，交的都是不菲的学费。
此系列开篇我曾提到过，自己用 jquery 撸了一解决方案一用三年，三年来前端技术日新月异，已经有很多更好的技术方案出现了，为什么不换呢？没有必要。那个方案已经成熟稳定，久经考验，换就意味着有成本：学习成本、重写成本，这样的成本没有必要付出。
我也曾踩过坑，而且是大坑。2014 年左右当时 emberjs 工具和生态都不是很完备，彼时公司的 CMS 已经乱的不可开交了，维护的问题日益凸显，匆忙之中想用 emberjs 全实现一遍，实践中慢慢发现很多问题解决起来比维护现有的还要麻烦，成本更高，遂弃之。到了 2015 年，emberjs 的生态出成，工具链开始逐渐完备，此时又再次决定用 emberjs 重写 CMS，并且打造自己的工具链。用时一个多月，后台功能基本全部完成，可维护性提高了很多，代码结构也比原来更清晰。
回顾 2014 年的选择为什么会失败呢？其因有二：
-
团队技术实力不够雄厚，无法在可接受的时间成本之下攻破难题
-
emberjs 工具链不完备，生态基础差
能意识到自身的不足和工具的不足是难能可贵的一件事，不下水，难知深浅。
2015 年我们的团队已经生产环境中用了 react 和 vuejs 了，虽然那时 react 和 vuejs 的 router 、model等全部单页应用的功能都还不是很完备，问题较多，但我们团队仍然顺利实施了几个项目，积累了一定的经验。为什么能成功？我们只用了它们最核心的部分：UI component，路由全部用传统路由替代，甚至数据传输也是从后端直接 render 到页面中（没有通过 ajax），封装成普通 JavaScript 对象传递到 component 中。于是我们的项目每个页面上只有一段普通的 JavaScript 数据组织和一个 ui component。
<pay order-id="{{order_id}}" :total="{{total}}" :balance="{{user_balance['total']}}" paymethod="dandanpay" ></pay>
<main class="live-wallpaper">
<section id="photo"></section>
</main>
<script>
var photo = {{live_wallpaper}}; //后端渲染
window.onload = function(){
if (photo && HomeApp) HomeApp.renderLiveWallpaper(photo);//传递全局变量到 component 中
}
</script>当然，如果团队人手充足、时间充足，有大把精力可以跟进新技术的发展那就另当别论了。
在 wecatch 我们更偏爱 CMS 之类的应用 emberjs + semantic-ui，客户端应用 react + redux，偶尔也会用 vuejs，还是看场景。
riot 这货我挺看好的，如果是一个人写，用这货完全没问题，多人协作要尽早给出规范，因为这货是在太简单了、太随意了。
TypeScript 真的是值得拥有，也许这能成为一个我们用 angular 的理由？
I have no idea 。
