做者爬取了 www.npmjs.com 上全部公开仓库的数据。从这些数据中分析了过去一年下载量最大的npm包排名;常见前端框架热、构建工具下载热度对比;以及各类常见框架的生态现状。这些数据帮助咱们了解Npm现有生态,也帮助咱们进行前端技术选型。css
NPM这个东西你们天天都在使用。前端
咱们天天都在考虑使用哪一个包,不使用哪一个包。vue
咱们回想一下,之前作出这些决策的依据,无非是:react
可是咱们历来没有从统计的层面去获取数据,而后作决策。从个人眼里,这是有失偏颇的。webpack
咱们历来没有量化地去作包的下载决策。git
这个包每月下载量有10,算多吗?程序员
这个包每月下载有10w,算多吗?github
咱们在npmjs面前,始终是一叶障目。web
因此我决定对npmjs.com进行数据爬取并统计。但愿从上帝的角度,去看npm包的生态现状。vuex
我经过获取NPM包中的Keyword进行词频统计,并画出词云,得到了如下的词云图:
在词云中,React的出现次数最高,达到了66w次。出现,另外,Plugin、Component、Node、API、JavaScript、Angular、Generator、CSS、Cordova、Cli、Vue 等都是很是高频的词汇。
这其实能够看出前端工程师平常在干什么了。每天用React写Component,每天在Node上写API,每天写JavaScript……
这些也是目前前端社区讨论最为火热的话题。
我对数据作了整理,根据下载量作了月份的筛选,由于爬取的时间跨度一周,因此直接去除了爬取数据的当前月份与最后一个月份。
画出了以下图表:
从总体状况来看,今年10月份,下载总量为293亿。这是一个很可怕的数字,平均下来,每秒钟就有100多个npm包被下载。在去年11月,这个数字为81亿左右。在房价涨工资不涨的年代,不多数字这么好看了,至少整个NPM的生态,是很是繁荣并且在发展的。
我根据下载量作了统计,结果以下:
事实上,NPMJS上年下载量最大的包,是debug,是九亿屡次。用处很简单,是打log。
下载量第二的包,是Debug的好兄弟,supports-color,他的用处很简单,检查终端是否支持彩色显示。
我之前觉得我喜欢五彩缤纷的log的颜色,是我比较奇葩。
如今看来,你们都喜欢五彩缤纷的颜色……
第三个是readable-stream,功能大概是Node流的实现,由于在早期版本中Node的流写得很烂,因此使用这个包来避免Node环境不一样的差别。下载量如此大的缘由,我想是被babel全家桶dependencies的缘故。
第四个是source-map你们都耳熟能详了,几乎咱们全部的项目都在使用source-map。
第五个是kind-of,主要用来解决到底实例属不属于某一个类的问题。你们写程序的时候确定遇到我想知道这个实例到底属不属于这个类的哲学问题,解决办法无非是使用kind-of,或者本身造一个kind-of的轮子。
剩下的譬如glob,qs,async,等等等等,其实都是写程序的工具包,咱们写一个程序,几乎以上的东西都是必须的,或者说咱们所依赖的包已经集成了这些东西,因此这也是以上的包如此热门的缘由,由于这些包解决了全部前端工程师都会遇到的问题,而且解决得很好。被不少热门的包所引用,于是下载量很是大。
但其实从Github上来看,这些包并不会是Star很是多的包,debug的Star数量是7k,其实还好,但supports-color就只有可怜的138 Star,readable-stream也只有971 Star,相对于它们在npmjs上的受欢迎程度,这个数字少得可怜。
在这个报告的后面,咱们会发现更多的高下载量少Star,或者是高Star可是下载量不多的现象。
高下载量意味着更多的项目在实际状况下使用这个包,高Star意味着这个项目受更多人关注。
可是多人用的包,不必定不少人关注;不少人关注的包,也不必定就不少人用……
在总下载量的排行里里,咱们并无看到任何眼熟的前端框架、后端框架、构建工具的样子。那么,这些包究竟生态如何呢?
很早你们就都在说React、Angular、Vue三分前端框架的天下。
React占据了超过61%的下载量,Angular份额是28%,Vue以10%的下载量在最后。
能够看到,React的受欢迎程度,一直是凌驾于Angular和Vue之上的。
前阵子Vue刚庆祝Github上的Star数量刚刚超过React,可是从这里来看,Vue还有很长一段的路要走。
不太熟悉Angular,就不评价了。
我以总下载量为主要纬度衡量,筛选Keywords中带有React字样的模块,过滤掉基础工具类包,筛选出最靠前的20个Package。
第一个是prop-types,你们都很熟悉了,下一个。
第二个是hoist-non-react-static,这个用于解决包装高阶React组件的时候,组件包装后获取不到包装前的静态函数的问题。
第三个是react-dom,很熟悉的朋友了,也不讲了。
第四个是warning,是react和react生态的其余组件常用的一个东西,譬如说你map一个东西的时候没有key,浏览器提示你的时候,用的就是这个warning。
第四个是warning,是react和react生态的其余组件常用的一个东西,譬如说你map一个东西的时候没有key,浏览器提示你的时候,用的就是这个warning。
第五个是ESLint-plugin-React,是专门用于React的Eslint工具。
这里你们应该看到了不少老朋友了,譬如说classnames、react-redux、react-router、react-transition-group等等。
话说几年前,react-motion刚出来的时候,你们都说 RIP react-transition-group,可是数据狠狠打脸啊,react-transition-group的下载量远超react-motion。到底是react-motion学习成本过高,仍是react-transition-group官方背书太厉害?
React全家桶不是吹的。
此处的筛选方法包括了Description包含Vue的包,并无作工具类的筛选。
Vue在Angular和React以后集众家之长成长,吸纳了双方的优点并造成了本身的特点。
虽说下载量并不如React大,可是Vue的优点也是很明显的,其中一个很明显的地方就是学习成本很低,针对国内开发者来说,原生的中文文档让你们都很舒服。
另外,从上述表中,你们看到的基本都是工具相关的包。
为何?
由于像以上的vue-template-compiler、vue-style-loader、vue-hot-reload-api等等都是vue-loader所依赖的东西,而后vue-cli又依赖了vue-loader,因此开发者一旦用上vue全家桶,那么上述的包下载量就会连环增长。开发者再按需加加点Lint工具,视项目数据流的复杂度上个vuex、若是是中后台产物就上个element-ui,完事。
其实Vue这种思路很不错,对于于入门的程序员来说,不用跳入babel、webpack配置的深坑,对于老司机来讲,新项目也能更快进入开发状态。
Angular生态就不讲了,由于我不怎么熟悉。
我拉取了比较主流的KOA、Express,Sails以及同构渲染那一波火起来的Next.js框架、国外比较流行的Meteor.js进行对比。
这个对比的结果有点震撼人心。
Express稳坐Node后端框架一哥无人能撼动。
Koa对于Express的优点,是无回调地狱,更少的绑定,更多的可定制化功能。
可是这个优点开发者们真的买帐吗?
首先是回调地狱问题,express也有相似于@awaitjs/express这样的async解决方案。其实也不是非koa不可。 更少的绑定,难道Express就不少吗.
你们装完了koa后都喜欢装koa-compose、koa-router、koa-bodyparser、koa-static,koa,那和Express有什么区别呢?
那我还不如直接装express好了,一步到位。
也许咱们在建站的时候,确实应该更多地考虑使用Express,毕竟下载量的生态摆在那,相关的middleware支持也会更为丰富。而想要进行Web框架进行二次开发的时候,能够考虑基于Koa进行二级开发(譬如egg.js、midway等等~)。
第一的是path-to-regexp,是集成在Express的一个路由工具。
第二个是代理转发的工具,用于browser-sync等工具,基于http-proxy的一个包装的组件。
第三个morgan是打log用的,没错,他的dependencies里面有debug。
第四个是killabe ,这个是用来清空全部socket的工具,为何这个下载量这么高,是由于webpack的server用的是他;webpack的server用的是express吗,不是,用的是koa,可是为何会在这里出现?由于他的keyword里有express。
后面的也有不少熟悉的包啦,譬如webpack-hot-middleware、cors、multer、passport、csurf、helmet、x-ss-protection、hsts等等。
我拖取了rollup、parcel、Grunt、Gulp、Webpack等构建打包工具的下载量统计。
首先最惨的是parcel,下载量几乎成为一条直线,这和它在github上有2w多个star差距有点大,可能你们都只是关注,但并无太多人真正把parcel放到本身的项目中去使用。
在过去的半年里,用户使用量已经有了指数级的上升了。Parcel已经很努力了好吗?没有对比就没有伤害。
再上面是rollup,通常来讲咱们用来打包library的时候使用,而打包web app的时候,咱们使用webpack。
再上就是grunt和gulp,taskrunner,可是热度仍是webpack比较高,也许和React、Vue框架流行程度有关系,老的项目在用Grunt/Gulp,新的项目基本只用Webpack了。
因为Webpack的Loader和Plugins都有对应的pattern,全部的loader都以-loader结尾,全部的Plugin都以-plugin结尾,那么筛选起来就方便了,结果以下:
首先咱们看到的是uglifyjs-webpack-plugin,你们用webpack的基础配置基本都是代码压缩,这个没毛病。
第二个是style-loader,很是经常使用的loader,主要功能是在HTML中注入<style>标签,通常配合第三的css-loader使用,css-loader分析文件中的import/require,而后对其进行处理。
第五个是file-loader,反正咱们有什么资源文件,不知道用什么loader,用它就对了。
后面也有不少熟悉的身影,譬如babel-loader,postcss-loader,url-loader,sass-loader、eslint-loader等等,都是老相识了。
好了,至此,这篇报告从总体、前端、后端、构建工具的角度分别讲述了npm生态的现状。
但愿这篇文章能给你们对于npm包有一个量化的认识,也可以帮助你们进行技术选型。
本文及本文所爬取的数据仅用于学习交流使用。
注: