如何进行前端选型？

1 写在开始

技术迭代是在任何团队都是老生常谈的话题，尤其是在前端技术发展迅速的这些年。无论是一帮久经沙场的老油条，还是刚毕业满怀冲劲儿和憧憬的新兵蛋子，都希望自己能学到一些跑在生态第一梯队的技术，但企业的技术并不是求新，而需要多个维度去判断是否合适。如何更好的选择更适合团队的前端库，成为了一个值得探讨的话题。

本文旨在分享运行时相关库的主观看法，工程化相关不在此处提及。

请注意：

1、本文中的”库“是统称，泛指可以通过npm仓库管理的可复用的前端运行时插件，可能指UI组件库、单页框架、CSS库等等。

这里顺便多嘴一句，库是library，不单指某一类特定代码的集合，而是开源项目的可复用产出物的统称。而框架一般指具有约定的针对某一领域的解决方案。

2、本文所有的内容都为作者基于自己知识体系的主观表述，如有不同意见，一定是你对，欢迎交流指正。

3、本文以作者本人在19年4月整理的angular生态进行UI组件库选型为例，进行流程和指标的解释，案例时间久远，只帮助内容理解，不做选型推荐。

2 流程简介

干货开始，分享一下我的选型流程：

选型步骤.png

流程简介：

圈定范围：根据环境因素（团队和行业的情况）进行组件生态的初步筛选
确定指标：确定你所关心的分析指标及对应权重
数据采样：根据指标对选型范围内的每个“参选者”进行数据收集
汇总分析：根据收集的指标数据进行横向比较，进行整体分析
选择结果且进行兼容性检查

接下来的内容会根据上述流程结合案例分享。

3 流程详述

3.1 圈定范围

选型的本质是比较和筛选，那么前提是先确定一个相对较小的选型范围，便于减少后续分析的工作量。

那么如何圈定选型范围？

3.1.1 信息查找的渠道

我们查找比较新的库通常会去github或掘金等技术社区或者搜索引擎直接搜索，接下来简单列举几个我常用的组件库查询途径：

awesome topic：如我要找angular相关的组件库 awesome-angular-components: Catalog of Angular 2+ Components
技术社区/公众号相关文章：如CSDN的跨端开发框架深度横评之2020版
官方文档：如vue官方帮助你打消你选型疑虑的对比其他框架 — Vue.js
搜索引擎：建议使用google、DuckDuckGo，如果翻不过去就Bing

3.1.2 初步筛选需要考虑的因素

环境因素.png

3.1.2.1 团队环境

人员平均技术能力：在人员平均能力不是特别强的情况下，过于复杂的库会增加项目开发和学习的成本。
人员学习能力：如果你选择的库的复杂度远远超出于你团队人员的学习的能力，会需要你进行二次研发或封装，增加研发成本。
团队原有的框架积累：不要轻易放弃团队原有的技术方向上的积累，同方向的技术迭代会让你事半功倍。

3.1.2.2 生态环境

为什么要考虑生态的流行度？

你选择的库的流行度决定你招人的难易程度，如果你选了一个小众的框架，大概率需要付出新招的开发人员的全部学习成本。

库的流行度也一定程度上说明了相关生态的完善和健康度，用的人多功能就会相对完善，bug解决的时效性也会更好。

3.1.2.3 行业线环境

契合度：举个例子，我的行业线使用的是比较复杂且要求高效的业务系统，那么有功能强大的table组件所在组件库就是更适合我行业线的。
运行时要求：有些行业线因为软件更新要求严格，所以浏览器版本落后，可能需要兼容老版本的浏览器。如我19年在组件库选型时，支持IE11是必要条件。

3.1.3 我的案例

以下是我根据当时（19年）社区的流行度和环境因素圈定的选型范围：

选型范围.png

3.2 确定指标

3.2.1 指标结构

基于自己对生态的理解，整理了一份指标（累死我了，手动狗头），还有很多不完善的地方，仅供参考：

指标.png

量化方式因为太多了，会在第三节进行概括行的分享，接下来会一一介绍指标：

3.2.1.1 基础指标

*生命周期阶段：简单看一下即可，无需量化数据，重点在于判断库是否处于不稳定或无人维护的状态。
- 是否有release版本：判断该库是否处于不稳定状态，通常我们会通过避免使用一个太”新”的库来规避技术风险。
- 官方是否仍有升级计划：判断该库官方是否还持续投入
- 最近一次feat或fix的更新时间：或是否声明即将停止维护，判断该库是否处于停止维护状态
*社区活跃度：是最重要的考量标准之一。和买车一样，销量高的无论是维修还是保养都便宜，出小毛病还能容易找到解决方案。
- google trend的搜索指数：最好从整体和区域两个维度分析，库可能存在地域性，比如下图：vue在中国的搜索指数远远高度其他国家。
  
  vue世界热度分布.png
- github的star数量：一定程度上能说明受欢迎的程度
- github的issue应答率和应答速度：是判断一个库是否活跃的重要因素
- github的Pull requests close比例：是判断一个库是否活跃且稳定的重要因素，某些库在生命的末期或者不活跃后，可能存在缺乏人员维护的情况，如ant Design的mobile版本、element ui都出现过类似的问题。
- npm下载数量和趋势：能够很大程度上反应一个库的用户数量
- code的Contributions图：是判断一个库是否活跃的重要因素
安全可控
- 是否开源：需要识别一下源码是否完整
- 是否有大公司（团队）主导：大多数成功的开源项目都是有一个稳定的团队维护，这样能更好的保证框架的稳定和生命力
*功能完善度：是最重要的考量标准之一。
- 特性覆盖率：量化方式可参考3.1.2

3.2.1.2 环境指标

*业务（行业线）契合度：是最重要的考量标准之一，可与“功能完善度”一同分析。
- 重点特性完善度
运行时版本要求
- 要求的最低支持的浏览器/Node版本：量化方式可参考3.1.1
生态流行度
- 同基础指标的社区活跃度

3.2.1.3 研发成本

工程化完善程度
- 编译产出物是否支持多方式引入
- 源码组织方式（mono-repo还是multi-repo）
代码是否有良好的设计：大型的库基本可以放心，良好的设计会让代码拥有更好的可读性，方便维护和升级。
- 是否渐进式提供：一个库优秀的public API设计能力的前提是源码的清晰的构造层次，这也是代码拥有更好可读性的前提。
- 库结构的抽象程度：是代码是否好修改的考量因素之一。
研发文档完善度
- 是否有贡献指南
- 是否有二次开发文档
- 源码工程中是否有研发demo：有一个闭环可验证的demo是提升研发效率和研发质量的前提。
- 源码工程中是否有完善的测试用例

3.2.1.4 开发/学习成本

也就是使用成本。

API简洁程度
- API面积（个数）：无论是考虑开发成本还是学习成本，单个库的大面积的API都是灾难。
*文档完善度：好的文档是一个好的开始，也是能节省推广成本和降低推广阻力的途径之一。
- 可读性
- 是否有源码示例
- 是否有可交互DEMO
- 国际化程度（是否有中文）
- 是否有历史文档
- 文档美观度

3.2.1.5 用户体验

一般UI组件库才需要的衡量指标，这块的知识体系需要一些设计知识，如果有时间，会单独写一篇详细展开。

3.3 数据采样

仅举例部分指标的量化方式，本节重点展示采样对比的效果。

3.1 如何量化指标（有时间再整理）

3.1.1运行时版本要求：

最直接的就是查阅github主页上的 Browser Support /Environment Support
去官方文档中查阅
ISSUE查找

3.1.2 特性覆盖率：

目标库的特性（功能/组件）数量/需求的特性（功能/组件）数量

3.2 我的案例

3.2.1 搜索指数

趋势对比

一年内的趋势.png
流行区域

流行区域.png

3.2.2 项目背景

项目背景.png

3.2.3 社区活跃度

社区支持

社区支持.png

贡献

Contributions.png

3.2.4 功能完善度

功能完善度1.png

功能完善度2.png

3.2.5 重点特性完善度

重点特性完善度.png

3.2.6 二次研发分析

以material2为例：

material2.png

3.4 汇总分析

3.4.1 客观分析

客观分析.png

3.4.2 主观结论

主观结论.png

3.5 选择结果且进行兼容性检查

选型后，记得检查和你使用其他库的预依赖。

4 写在最后

本文主要是对过去知识体系的梳理和完善，将选型思路根据自己的知识体系分享出来，希望能给更多的人提供思路。

无论是流程还是量化的指标，都是和我的知识体系紧密联系的，所以并不是适合任何情况的选型分析，仅作为选型分析和库本身分析的参考。