共计 1603 个字符，预计需要花费 5 分钟才能阅读完成。
最近，在持续关注一个 Twitter 话题，就是 Why do people decide to use frameworks?，这个话题是由 Nicole Sullivan 提出的。
刚开始，我对这个问题也没有太在意，也就是随意的看了看，正如提问者 Nicole Sullivan 说的那样，我刚开始也觉得这是一个愚蠢的问题。但是这个问题就像蒲公英的种子一样，就这么在我的脑海里扎了根，截至到我这写这篇文章之前，我都有一直关注这个问题，并且在思考这个问题。
虽然这个问题看似简单，你或多或少都能回答出那么一两点，但是我想你可能自己也对自己的回答不太满意吧？不管你怎么想的，但我渐渐收起了我从一开始的轻视态度，开始正视这个问题。
在这里，我还要感谢 Nicole Sullivan，是她的这个话题，让我对为什么使用框架有了全方位的了解。
为什么用
可以集中精力在业务的实现，而不用把过多的精力和人力用在代码功能逻辑的实现上。
可以避免由我们自己写带来的很多 bug。
可以暂时快速的解决掉某一问题，以待以后的进一步解决。
可以避免写技术文档和介绍功能实现给团队成员的问题。
可以极大的缩短开发的周期。
因为成熟的框架本身就是完善的解决方案。一般它们都有自己的生态系统，有众多技术达人参与。这样我们在使用中，不仅有完善的技术文档可以随时查看，遇到问题也有地方问，最重要的一点是不用自己设计、整理、验证技术方案了，你之需要深入了解它的生态系统即可。
避免了 bikeshedding 现象 (它的意思是说：‘总在一些没有意义的问题上争论，而有意忽视哪些真正需要解决的难点 / 痛点问题’) 的出现。
为什么不用
不用的其中一个原因，就是用框架的成本太高。夸张一点说，可能就这一点就就盖过了它所有的优点，但要用一个框架一定要考虑它的成本。
对于一个团队来说，首先需要专门招聘一些精通这个框架的开发人员（前端 / 后端）和维护人员，再加之没有一个框架是万能的，如果下一个项目使用另一个框架是否意味着另招一批开发人员，这样的代价不是所有的企业都能承受；
对个人来说，学习一个框架需要花费大量的时间和精力，你不仅要学习框架本身，你还要了解它的生态系统，关注它的各方面咨询，尤其是版本更新，它往往带有对过去框架存在问题的改进，如果升级版就可以移除自己解决原框架存在问题而写的补丁（这些补丁有大有小，也可能引入了其他依赖），这样就带来另一个问题，项目的迁移问题，像 angular 一样它现在的版本已经到了 9.x，但现在有相当一部分还在用着 1.x，angualr 虽好，但是它也给开发人员带来了巨大麻烦，学习曲线太陡是一方面，要了解的东西太多（知识面的广度）是另一个重要方面。当然一直使用一个框架，并进行深度挖掘的技术团队，受益良多，但这样的团队又有多少。
除了成本，就要考虑项目的规模和复杂度问题。
不能一个就五六个简单页面的项目，你就引入一个框架吧。此外使用一个框加，往往会使用它配套的部件，如：引入 vue，一些用惯了 vue-router，vuex，在项目中自然而然的引入这些东西，这些在简单的仙姑中往往没有必要。这也是开发这些框架的核心团队为什么尽量的缩减核心框架功能的原因，而把一些次要功能或三级功能独立出来。这些由主框架、功能库、主题库、工具库、以及辅助开发的工具库等组成的集合，就是该框架的生态系统。
开发人员要保持理智
国内的一些基层开发人员普遍存在不理智的现象，跟风现象比较严重。应该注意这些：
技术比较火，并不代表技术方案的完美。
好的技术框架我不一定都要会，但要有一个框架我十分精通。
别人会的，我不一定要非得精通，但我会的要保证别人一定要不如我。
学习某一个技术不是一两天或者一两个月的事儿，技术都是积累来的。
不要把大神神话，它们也是从 小白 成长起来的。
要保持对技术的热度，而不是蹭技术的热度。
结束语
其实，不管你是否使用框架，抑或你对框架持有什么样的态度，你都要明白你选择的出发点儿是什么或者说动机是什么。
