对近期前端圈口水之争的一些思考

写在前面

1.大漠穷秋同窗以略显偏激的ng对比vue一文引发网络上的口诛笔伐，最终以致歉信和辞职信了结
2.知乎上未知姓名同窗回答为何使用React的问题，其中夹杂着一些对vue的我的观点，引来了vue做者的讨伐

以上两点刚好同时出如今了个人视线中，由此我想站在一个作业务开发的前端视角来思考，当咱们在分析一个框架适不适合一个项目时，我须要以怎样的维度来分析？

首先讲点题外给各位，做为吃瓜群众，我是很开心的，由于我所处的前端圈子比较狂躁，起码比没新闻强，说明咱们前端正在蓬勃发展，处在其中会让我有一种兴奋感。其实关于网络上的争吵你们不用太较真，某些人的观点和见解仅仅是商业行为，前端圈也不能说混乱，由于咱们处的大环境就是商业社会，你们都是趋利而已，任何环境都同样，前端也不例外。

很少说了，进入主题。

进行前端技术选型我所思考的几个维度

• 法律风险

• 稳定性

• 上手难度及社区生态

• 开发工具及流程闭环

• 可维护性及可扩展性

• 团队合做并行提效

• 与新标准的融合度

• 方便调优及监控

法律风险

这一个因素可能小公司会忽略，但请千万不要，由于法律上出了问题，每每对你的团队带来的经济损失是超大的，尤为是作企业级的产品，法律风险永远是要考虑的第一要素。前段时间Apache 软件基金会(ASF, Apache Software Foundation)将『BSD+专利许可证』列为 Category-X License，这个意思是说，全部 License 为 『BSD+专利许可证』的软件都会受到影响，大概的意思就是『BSD+专利许可证』不被ASF官方承认，可能会有潜在的法律风险，这一举措对 Facebook 旗下的软件影响巨大，特别是对于前端领域的 React 框架，所以，这个措施引起了一些用 React 的大厂的关注，我厂的法务部也在第一时间介入研究这个举措的影响度，最终的解决方案目前还不清晰，不过React官方仍是表态不会修改 License，ASF 仍旧把 Facebook 这个 License 列为非官方推荐的 License。若是对法律层面不清晰，引起了著做权官司，对于阿里这个航空母舰会面临多少钱的诉讼，即便不会马上引起诉讼，但确定要作技术替换，这须要投入多少成本都是不可估量的。在前公司，设计海报时使用了方正字体也接到过诉讼，这些其实都属于法律层面须要注意的。总而言之，在作技术选型时，我首先考虑的就是所用的框架的 License 是否是存在法律风险。

稳定性

当一个框架已经超过了1.0版，或者说已经fix掉不少bug（从github的issue记录能够查看），这个时候能够理解为这个框架的稳定性是相对较好的。稳定，是一个软件系统的生死线，若是一个系统连基本的稳定都没有，这个软件系统能够说是一击即溃，对于开源框架的技术选型稳定性也是相当重要的一环。

上手难度及社区生态

其实上手的难度是因人而异的，对于我所负责的采购业务团队，外包同窗可能比较多并且离职率也高，为了业务的高效运转，作技术选型时上手难度不得不作为一个因素来考量。好比我在采购平台的前端开发中，引入基本的构建工具和组件库后一直想要引入数据流框架，可是发现Flux的思想以及跟React之间的关系，确实不便于新人去理解，因此我迟迟没有引入数据流，大部分场景仍是鼓励你们手写 fetch + setState，这样迭代了将近1年，发现技术上的咨询确实不多，由于引入的新概念少，新人在理解业务以后可以快速上手。社区生态其实就是看一下 stackoverflow 或者 segmentfalut 上问题的 tag 数，当使用这个技术时可否经过搜索引擎快速查找到解决方案，这个是衡量这个技术是否社区活跃的重要因素，这个也有助于效率。

开发工具及流程闭环

这个因素的意思是，当你选用某一个技术时，是否是配套的工具不少很方便，开发的流程能不可以基于这些工具完成一个健康的闭环，也就是说在使用这个技术以后，它附带的脚手架、构建、压缩、单测等工具能不可以覆盖你一个项目的整个生命周期，从设计、开发、测试、发布、运维等各方面都能覆盖到。好比 vue 和 angular 这方面就比 React 要强一些，React 主要 focus 视图层，而 vue 官方就会直接推荐一整套解决方案，从路由、脚手架等，不过 React 后来也加入了一些官方的东西，好比 create-react-app 这个脚手架的引入。

可维护性及可扩展性

这个概念可能会让人感受到比较虚。举个例子，你使用 jQuery 开发了一个 app，过了两年 React 开始上马大家的业务了，这个使用 jQuery 所写的代码还能不能继续维护甚至基于 React 技术进行扩展。这个因素其实仍是跟人相关，厉害的人写得代码是有设计感在里面的，是有模式的，不管将来更换什么样的框架，但代码的核心思想在那，代码结构就在那，API设计的好，即便你过去是用jQuery写得 dialog，但这个 dialog 必需要支持后续的 React 风格，可能仅仅须要一层简单的封装就能够搞定了，因此技术的维护性和扩展性，在框架那一层是大可能是没有问题的，关键仍是写代码的人，因此你团队代码的API设计、模式分层要把控好。

团队合做并行提效

这个点思考的是这样的场景。好比，某一天你的业务忽然紧急起来，使用这个框架能不可以让你达到投入越多的人，就能在保证质量的前提下更快的完成任务。在这个点我感受 React 作得足够优秀，由于 React 的概念不多，API也精简，你们都是经过组件化的思惟模式来写代码，当业务繁忙的时候，原本是两我的负责20个组件，可能经过简单沟通以后再投入2我的，就是四我的负责20个组件，这样就可以经过加人来达到提高速度的目的，相比较之下 vue 和 angularjs 在这个方面就不如 React。

与新标准的融合度

业务是发展的，技术是面向将来的。你所用的技术是否跟业界新规范有必定的融合这一点比较重要，直接关系着将来你的项目是否可以方便升级而且不会带来不少潜在的bug，好比 React 本来是 createClass，后来就推崇使用 ES6 的继承机制，这就是一个很好的趋势，说明这个框架是面向将来的，其实在前端领域不少框架这一点作得都不错。可是若是作不到这一点，我会以为这个框架前途未卜。

方便调优及监控

其实这个点是比较细的，落地到技术细节来讲就是这个框架在设计的时候有没有考虑一些 hook 机制或者中间件机制，方不方便你在一些关键的节点插入监控脚原本获知当前的性能数据以及达到性能优化的目的，其实这个属于优化的范畴，基本上是在软件工程的中后期才会涉及，有一句话我认为很是有道理，『过早的优化是万恶之源』，其实性能因素并不适合过早的去考虑，它每每是随着工程以及业务的发展逐步引入的，过早的由于考虑性能而下降了你项目的效率实际上是不明智的，由于你所考虑的性能问题不必定之后就会出现，但也不能说不考虑性能，你应该为将来优化埋下一些小种子。

以上就是我所考虑的几个技术选型的维度，也但愿对于技术选型有本身独特看法的同窗跟我交流。