做者爬取了 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包有一個量化的認識,也可以幫助你們進行技術選型。
本文及本文所爬取的數據僅用於學習交流使用。
注: