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

写在前面

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 机制或者中间件机制，方不方便你在一些关键的节点插入监控脚本来获知当前的性能数据以及达到性能优化的目的，其实这个属于优化的范畴，基本上是在软件工程的中后期才会涉及，有一句话我认为非常有道理，『过早的优化是万恶之源』，其实性能因素并不适合过早的去考虑，它往往是随着工程以及业务的发展逐步引入的，过早的因为考虑性能而降低了你项目的效率其实是不明智的，因为你所考虑的性能问题不一定以后就会出现，但也不能说不考虑性能，你应该为未来优化埋下一些小种子。

以上就是我所考虑的几个技术选型的维度，也希望对于技术选型有自己独特见解的同学跟我交流。