什么样的前端框架才是一个好框架

够得着

我们开发一个软件，最终目的都是为了提供一个产品或者服务给我们的客户。站在公司或者组织的角度，当然是想这个产品用户越多越好，这样产生的效益才越大。

怎么让用户量最大化？

除了市场营销和推广外，我们技术可以做的就是让产品具有让世界各地的人们随时随地的用到它的潜力。

换句话说，就是我们幸幸苦苦开发出来的产品应该让人们：

1. 看得见
2. 够得着
3. 看得懂

看得见就是市场推广的事，我们暂且搁置一边。够得着就需要我们的软件能跨平台、跨终端，这就是涉及到我们对技术的选择。看得懂就涉及软件的本地化。

开发快

紧接着，客户已经在用我们的产品，但是产品必然有各种问题：功能缺失、体验不够好、性能太慢、各种Bug等等。这就要求我们的软件能快速反应、快速更新。涉及到两个问题：

1. 开发快
2. 部署快

唯有快，迭代次数多，才有可能把各种问题给解决掉，才能无限接近用户想要的理想产品。有人可能说，我一次把问题想明白不就行了，不需要迭代。很遗憾，那是不可能的。人活在这个世上，就干两件事：认识世界和改造世界。认识世界很难，就像盲人摸象，对?的认识带有片面性，只有在无限试错中（摸摸鼻子、再摸摸大腿...）才可能得到较满意的结果，除非已经有现成的答案。但是答案也要经得起实践的检验才行，而时代在变化，旧答案可能也不再适用。

怎么让开发快？需要框架把复杂的问题简单化、提高工作效率。所谓复杂就是指：

1. 多。工作量大
2. 杂。涉及对象类型多
3. 乱。无序
4. 缠。对象关系互相纠缠。

所以需要框架：

1. 减少工作量
2. 抽象前端对象类型，控制数量
3. 定义它们的交互逻辑
4. 解耦

一般框架都对2、3、4有自己的一套建构，我们不深入分析。今天主要把精力放在1上，怎么减少工作量。我觉得有两种办法：

1. 空间上，框架帮忙干了部分工作
2. 时间上，可利用历史积累，减少了部分工作。

在前端。框架自动干的事越多，我们的开发效率就越快。最理想情况什么都干了，我们就啥都不用做了，哈哈。

历史积累简单说就是UI组件化，可重用，可组装。充分利用以前的工作成果，来降低本次的工作量。

部署快

部署快的理想结果就是修改完代码，立即部署、用户那边就能立即能看到改变。部署流程一般是编译、打包、上传、用户下载、安装。前三个阶段时间一般还能控制，后面两个就不一定。整个打包可能文件大，如果用户下载时间依赖网速。即使下载完毕，用户也不一定安装。频繁的提醒新版本考验用户的耐心。所以最好是免安装。

结论

最后总结一下，一个好的前端，除去一些标配，应该是：

1. 跨平台、跨终端
2. 组件化
3. 免安装

这不是大家都知道的么?是的！还有就是对不起，让您失望了，没有什么先进的架构、强大的组件、性能牛x的渲染模式....