精讀《12 個評估 JS 庫你須要關心的事》

1 引言

做者給出了從 12 個角度全面分析 JS 庫的可用性，分別是：

1. 特性。
2. 穩定性。
3. 性能。
4. 包生態。
5. 社區。
6. 學習曲線。
7. 文檔。
8. 工具。
9. 發展歷史。
10. 團隊。
11. 兼容性。
12. 趨勢。

下面總結一下做者的觀點。

2 概述 & 精讀

特性

當你調研一個 JS 庫，功能固然是最重要的，就比如 React 的用於開發 UI 界面很是方便，這是流行起來的一部分因素。

但同時 React 解決的問題很聚焦，因而把例如 Router 和 Store 部分交給社區給解決方案，這就讓 Vue 的官方維護生態模式發展了起來。但這更多取決於你的偏好，像 lodash 這種精簡的庫也會長盛不衰，重要的是這個庫提供的能力是否解決了你的業務問題。

評分：A - 化腐朽爲神奇。B - 更優雅的解決方案。C - 比現有方案差。

穩定性

這個庫若是常常出 BUG，那顯然沒法在生產環境使用。最好通過嚴格的測試，保證這個庫必定不會出錯，這樣咱們就能夠專心排查業務的問題了。

評分：A - BUG 不多，方便調試。B - 不會影響你的穩定性，好比出 BUG 機率和你的業務代碼相近。C - 引入該庫會讓你背線上故障。

性能

若是讓用戶 15 秒才能打開網頁，那一切都是徒勞。

拿 PReact 爲例子，爲何 API 相同的輪子能夠活下來？由於體積小，並且 PReact 把宣傳重點放在性能上。

如何一句話說明白你不是在造無用的輪子？性能更好。

評分：A - 小體積，高性能，支持各類黑科技特性好比 Tree shaking。B - 對性能沒有影響。C - 致使性能下降。

包生態

用過 monaco-editor 嗎？你們都在用 webpack 但它卻走 amd 路線，我不知道你用什麼方法讓它支持 commonjs 的，但這必定耽誤了你很多時間。

包生態包括第三方包的成熟度，包的使用難易度，支持多少種模塊化方案，是否支持 TS，有沒有管理好本身的依賴等等。

開箱即用是最好的，有長期維護組織的更佳。

同時不要有太多相互競爭的社區方案爲佳。好比工具庫用 lodash 這很容易，但 React 數據流方案選擇哪一個？太多的競爭對手不斷寫軟文搶奪用戶（程序員）的注意力，試圖說服他們加班重構。

評分：A - 方案惟一且生態運做良好，維護記錄標準規範且順暢。B - 不少新晉網紅包，且競爭選擇多。C - 沒有人給你作包，想用要本身封裝。

社區

可否快速在 Stack Overflow 搜到問題的答案能反映出社區的活躍度，不管是官方文檔仍是第三方進行的問答。

社區越活躍，幫你提早踩的坑就越多，若是你遇到一個你們都沒有遇到過的問題，並不表明你用得有多深度，而可能你根本就用錯庫了。

評分：A - 各類論壇每日都很活躍，Github issue 問題日清。B - 論壇/聊天室不太活躍。C - 除了做者自吹的文檔，再也找不到任何相關信息了。

學習曲線

不要覺得把庫功能作的強大，就算難用點也會有用戶跪舔，這是幻覺。

Vue 之因此那麼火爆，是由於原生 HTML 的門檻比 JSX 低，而使用 React 的用戶每每都以爲 JSX 比 HTML 門檻低。我也不知道該怎麼描述，從 JS 能夠產生一切的角度，學習 HTML 反而被認爲是高門檻的體現。

因此認清現實，JSX Star 多並非其理論有多先進（理論確實先進），而是不少人以爲總體學習維護成本比 HTML 低。

評分：A - 一天就能成爲這個庫的熟練搬磚工。B - 浪費了一週時間才能投入使用。C - 學了一週才發現以前的理解是錯的，並且認識到這只是個開始。

文檔

寫文檔的人通常都是庫的做者，這種人通常經驗會比較豐富，寫起文檔通常不會考慮初學者的感覺，因此找到一份對初學者友好的文檔仍是挺不容易的。

對於庫的維護者，要站在初學者角度去寫文檔，站在使用者角度，若是文檔開頭就看不懂的話，最好儘早換個文檔或者換個庫。

評分：A - 專門維護文檔站點、視頻、圖片、示例項目，再好一點的話能夠有專門基金會組織編程比賽，經過某三歲孩子能夠一天入門強力影射技術生態的完備性。B - 有最基本的 Readme 和 API 文檔。C - Readme 寫的是 Create react app，其餘的只能查源碼了。

工具

工具能夠從多個維度體現出這個庫的優點，首先是確實帶來了使用方便，其次展現了團隊維護實力的雄厚（精力溢出到能夠作周邊工具了）。

Redux 之因此這麼火，Redux dev tools 功不可沒，筆者讀過一些心理學書籍，也經歷過一些技術選型，看到 Redux dev tools 的圖形化界面後，大腦由於受到視覺衝擊比理性的邏輯思考大太多，潛意識裏給 Redux 加了很多分，致使討論結果都變得不太理性了。

若是你的庫能圖形化表達，或者作一個 PPT 或者輔助工具，那必定會大大加分。（React chrome 插件在打開 react 作的網頁時亮起來真的很酷，這個勳章頗有儀式感，以致於我不想換一個框架）

評分：A - 兩個以上的工具，包括瀏覽器拓展、代碼編輯器拓展、CLI 工具或者 SaaS 服務，實力碾壓的話，會有許多花哨的輔助工具出現。B - 一個工具。C - 沒有工具。

發展歷史

一個 Star 10K 的庫，若是最先提交是十天前，就算不是刷的也最好也不要用，由於不知道哪天做者就再也不維護了。

歷史越悠久的庫使用風險越小，除非它所在的面被淘汰（技術棧、生態、編程語言等等）。

評分：A - 4 年以上歷史，有權威認證。B - 1-4 年曆史，已經有很多人使用過了。C - 做者本身都沒用過就安利你用到線上去。

團隊

看誰是這個庫背後的男人。大公司普遍使用的開源庫，而且有必定國際影響力，並且大廠也有成功開源歷史經驗的話，就會增長說服力。

但 Vue 就是個例外，幾乎憑尤大一人之力打造，對這種狀況，筆者想說的是，一個真心熱愛技術並踐行全職維護的人，也許比一個揹着 KPI 的團隊維護副產品更靠譜。

評分：A - 一線大廠，品質權威認證。B - 中型團隊維護，而且有清晰的分工記錄。C - 工做之餘順便開源出去，就沒打算對這個庫負責。

兼容性

除了瀏覽器兼容性，庫 API 的兼容性也很是重要。當你很容易聯繫到做者，而且改動 API 的建議被很快採納時，你就要當心了。

React Router 3 -> 4 升級帶來的陣痛你們都有體會過，babel7 放棄 stage 0-4 也帶來很多吐槽，Angular1 和 Angular2 的區分直接讓不少人粉轉黑了。雖然許多時候頻繁的更新是爲了增添新功能，但若是帶來 API 兼容問題，反而會招來反感。

假如大家團隊維護的 10 年間，由於某個庫做者很是勤奮的更新致使以時間爲維度，均勻分佈了數十種不一樣的版本，你會發誓下一個項目再也不使用這個庫了。

評分：A - 老是能兼容升級，實在不行就提早警告並告知在某個版本會廢棄，並提供遷移工具，好比 React。B - 有 Break Change 可是文檔把升級改動寫的很清楚。C - 忽然到來的小版本升級讓你不得不重構以前的調用代碼。

趨勢

炒做也好，討論也好，保持你們對這個庫的新鮮關注很是重要，由於這能連帶的讓這個庫作好上面說的不少點。

但注意過度的炒做，可能會下降這個庫的穩定性，畢竟在用戶爆發式增加以前，最好有一部分當小白鼠。

評分：A - 是 HackNews 的明星話題，Star 成千上萬，各類會議以此爲名（Vue conf，React conf）。B - 幾百 Star，有一些討論。C - 別看如今 Star 少，早晚有一天我會超過那啥那啥。

搬家成本

這個是做者補充的比較重要的一天：若是哪天不用這個庫了，換成別的成本有多大？

這方面測試庫作的很好，不少主流測試庫好比 Jest、Ava、Mocha、Jasmine 等之間都有互轉的腳本，業界基本達成了一些共識和規範。

比較坑的是 React、Vue、Angluar，使用以後你基本就被綁定了，至今沒有誰能夠無縫作各大框架的遷移。固然 JS 的年齡還很短，並且說很差將來還會被新語言、技術、容器顛覆而成爲歷史，標準化不是作不到而是須要時間，也許就在十幾年以後，可是今天就是作不到。

3 總結

下次技術選型討論時，能夠拿出規則一條一條比對了！

而後技術選型只是基礎庫，利用這些基礎能夠維護好本身的開源庫，把更多時間用在創造業務價值上。

仔細思考就會發現，程序員開發的工具庫也適合點線面體的概念。一個庫 react-button 就是一個點，而它所在的線 react 若是被人拋棄了，無數個 react-xxx 也會翻船。而 react、vue、angluar 這些線都在 js 引擎這個面上，當能夠用 C# 寫 WebAssembly 時，Reason、Blazor、Dart 就會逐漸成爲瀏覽器的主角，react 之類的庫通通要回爐打造。而當將來人機互聯不須要瀏覽器做爲媒介時，js 引擎這個面依附的體 - 人機交互場景也被打翻了，這一浪又會引發多大的變化。

因此技術選型是爲了解決當下業務問題，仔細考慮好幾個因素，適合解決業務場景就足夠了。

4 更多討論

討論地址是： 精讀《12 個評估 JS 庫你須要關心的事》 · Issue #104 · dt-fe/weekly

若是你想參與討論，請點擊這裏，每週都有新的主題，週末或週一發佈。