選擇JavaScript開源庫時，你須要考慮這些問題

選擇JavaScript開源庫時，你須要考慮這些問題

做者｜Sacha Greif
譯者｜無明
對於 2018 年的 JavaScript 狀態調查，我想深刻挖掘一下。我不只想知道人們都在使用哪些工具和庫，還想知道他們爲何選擇它們。通過一番研究，我開發出了一個評分系統，能夠將它做爲技術選型的衡量標準。

12 因素測驗

爲了讓你可以更好地對各類庫打分，我準備了一個快速測驗，將引導你完成 12 個因素的評分，而後給出建議。若是你不肯定要評估什麼，只需選擇你熟悉的庫（如 React、Vue、jQuery 等），看看它們的得分狀況如何。
測驗地址：https://stateofjs.typeform.com/to/hTRAcc。

或者，你能夠繼續往下讀，瞭解每一個因素的詳細信息，並瞭解如何應用這些因素。
這 12 個因素分別是：特性、穩定性、性能、庫生態系統、社區、學習曲線、文檔、工具、歷史、支持團隊、兼容性、發展勢頭。我將解釋每一個因素的重要性，併爲你提供一個評分網格，向你展現如何評估它們。

1. 特性

特性是你在選擇任何一項技術時須要考慮的第一個因素。
關鍵在於要有個度。React 多是目前最流行的前端庫，但人們抱怨它作得還不夠，它將路由和狀態管理等內容留給了第三方庫，如 React-Router 和 Redux。
然而，這些倒是 Vue（React 最大的競爭對手）最吸引人的地方。Vue 爲這些常見用例提供了官方的解決方案，從而得到大量開發者的支持。
但若是作得太過頭了，試圖解決全部的問題，就有可能會獲得一個臃腫又複雜的框架。
有時候，恰到好處就是最好的。像 Lodash 或 Ramda 這樣的庫可讓你用簡潔的函數表達式替換亂糟糟的 for 循環嵌套，這足以讓它們成爲無價的工具。

評分系統

A：作到以前沒法作到的事情。
B：可以讓你以更好的方式作以前一樣的事情。
C：能作的事情比現有解決方案少。

2. 穩定性

你使用的框架可能很優雅，功能很全面，但若是開發人員每兩三分鐘就會犯一次錯誤，那麼整體上並不會給你帶來多少好處。
所以，當前 JavaScript 生態系統中的不少工具都專一於爲技術棧帶來穩定性和安全性。看看 TypeScript 和 Flow 的成功就知道了，甚至是 Reason。
在數據層面，GraphQL 的類型系統也有助於確保一切順利運行。

評分系統

A：更少的錯誤，問題變得更容易調試和解決。
B：採用該技術不會對軟件的穩定性產生影響。
C：採用該技術的直接後果是出現了新的錯誤和問題。

3. 性能

若是你曾經練過武，就會知道速度纔是最重要的，而不是力量。
一樣，若是你的應用程序須要 15 秒才能加載完畢，那麼全部的功能都變得毫無心義，由於沒有耐心的用戶早已關掉了瀏覽器標籤。能夠說，這場仗還沒開始打，你就失敗了！
在 JavaScript 生態系統中，Preact 就是一個很好的關注速度的例子：它的 API 與 React 徹底相同，因此它不會試圖在功能上與 React 展開競爭。可是，與 React 相比，Preact 更輕量，加載速度更快，能夠節省寶貴的毫秒數，並提升 Web 應用程序的性能。

評分系統

A：更輕的捆綁，更快的加載速度或其餘性能改進。
B：採用該技術不會對你的軟件性能產生影響。
C：採用該技術會顯著下降應用程序的速度。

4. 庫生態系統

在採用一項新技術以前，要先看看它的生態系統。
一個充滿活力的庫生態系統不只能夠節省大量時間，由於它可讓你複用其餘人的工做成果，但這也代表這項技術已經達到了必定的成熟度水平。所以，維護活躍度是開發者應該長期採用這項技術的最佳標誌之一。

評分系統

A：生態系統對人們廣泛關注的問題有明確的解決方案，維護積極且文檔齊全。
B：擁有諸多競爭選項的萌芽庫生態系統。
C：沒有庫生態系統可言，須要作大量的手動工做。

5. 社區

另外一個要考慮的因素是社區。在遇到問題時，論壇或 Slack 頻道能夠提供大量的幫助。

Spectrum 是介於聊天室和傳統論壇之間的一種溝通方式
Stack Overflow 也是一個能夠找到不少問題答案的網站。固然，維護良好的 GitHub 問題頁面也是必需的！

評分系統

A：進行平常交流的論壇或聊天室（Slack、Discord 等），一天內能夠獲得解決的 GitHub 問題。不少人回答了 Stack Overflow 的問題。
B：不活躍的論壇或聊天室。
C：除 GitHub 以外沒有其餘社區。

6. 學習曲線

簡單的學習曲線意味着開發人員更有可能嘗試使用你的框架或庫。人們很容易認爲，若是一項技術真正具備顛覆性，他們就會克服一切障礙來學習它，但一般事實並不是如此。
一個密切相關（但有時卻相反）的概念是「採用」曲線。Meteor 在剛出現時，很是易於使用（至少與現有替代品相比），但它要求你必須使用它的整個技術棧，因此要將它應用在已有的項目中很困難。
React 以它的陡峭的學習曲線而聞名：對於習慣了分離 HTML 和 JavaScript 的開發人員來講，不得不使用 JSX。相比之下，Vue 更容易上手，不須要你改變對前端編碼的思考方式。

評分系統

A：能夠在一天內上手。
B：在能夠帶來生產力以前須要大約一週時間。
C：須要一週以上的時間來學習基礎知識。

7. 文檔

簡單的學習曲線意味着它須要提供出色的文檔，但要真正作到這一點並不容易，由於撰寫文檔的人一般是經驗最豐富的人，也就是說他們早也脫離了新開發者的狀態，因此不必定能重新開發者的角度來撰寫文檔。
所以，撰寫好的文檔要求你暫時忘記你所知道的一切，並重新手的角度思考問題。

Vue.js 的文檔通過精心的設計和編寫（https://vuejs.org/v2/guide/）
它還要求你預測常見的問題，瞭解用戶的心理模型，最重要的是在代碼庫發生變化時保持最新狀態！作到這些須要寶貴的時間......
所以，你能夠理解爲何好的文檔實際上是既罕見又有價值的東西！

8. 工具

就像文檔同樣，工具對於一些維護者來講看起來彷佛是次要的，但實際上對於任何一項技術的普及和成功來講都相當重要。

Redux 的 DevTools（https://github.com/zalmoxisus/redux-devtools-extension）
我相信 Redux 取得成功的一個重要緣由是它提供了優秀的 DevTools 瀏覽器擴展，讓你能夠以用戶友好的方式可視化 Redux 存儲和操做。一樣，VS Code 對 TypeScript 強大的支持也爲它的普遍採用創造了奇蹟。

評分系統

A：擁有兩個或多個：瀏覽器擴展、文本編輯器擴展、CLI 實用程序、專門的第三方 SaaS 服務。
B：擁有其中之一：瀏覽器擴展、文本編輯器擴展、CLI 實用程序、專門的第三方 SaaS 服務。
C：沒有外部工具。

9. 歷史

畢竟，即便是最優雅、文檔化最好的庫也會被歷史所遺忘，由於若是它只存在了六個月，也只是曇花一現而已。

Express：即便過了這麼多年，仍然是一個有力的競爭者（https://expressjs.com/）
所以，具備良好歷史記錄的東西難以被戰勝。Express 就是其中的一個例子：它最初於 2010 年發佈，但如今仍然被認爲是首選的 Node.js 服務器框架，儘管 JavaScript 生態系統經歷了快速的發展。

評分系統

A：已經存在四年多，被知名的技術公司採用。
B：已經存在了 1 至 4 年，被早期採用者和小規模技術公司採用。
C：存在不到一年，尚未真正被採用。

10. 支持團隊

並不是全部項目都有悠久的歷史。對於一個全新的庫，你如何判斷它的潛力？一種可靠的方式是看看它背後的支持團隊。
當 React 剛出現時，光是其背後的公司是 Facebook 就能夠做爲嘗試一下的理由。後來 Facebook 繼續發佈了 Relay 和 GraphQL，代表 React 的成功並非僥倖！

谷歌開源：超過 2000 個項目，涵蓋了桌面和移動等平臺的開發（https://opensource.google.com/）
大公司有更多的資源能夠投入：即便發佈了更新的不兼容版本，谷歌也可以繼續維護原有的 Angular.js。
固然，這並表示獨立維護者就沒法創造出重大的創新。Vue.js 的誕生就是在這樣的狀況下誕生的，更不用說其餘 99％的開源軟件了。

評分系統

A：由一家擁有專門開源團隊的大公司維護。
B：由一箇中等規模的工程師團隊維護。
C：獨立維護者。

11. 兼容性

採用尖端庫的好處在於它們一般發展得很是快。惋惜的是，這也多是一個重大的缺點！
快速演進也可能意味着頻繁的重大變動，由於新的最佳實踐取代了舊的模式，早期採用者須要付出重構成本。
當 React Router 決定在版本 3 和版本 4 之間徹底改變 API 時，致使了人們的不少抱怨。而當 Angular 從 Angular.js 切換到新的「Angular」時，也是如此。
當你剛開始一個新項目時，頻繁更新頗有趣，也很使人興奮，但一旦應用程序進入生產環境，你最不但願的事情是每次發佈新版本的庫都須要花費數週的重構和調試時間。

評分系統

A：更新大可能是向後兼容的，若是棄用會發出警告，花兩年或更長時間維護不兼容的舊版本。
B：確實發生了突破性的變動，但提供了很好的文檔，並以漸進的方式推出。
C：頻繁發佈重大更新，須要進行大量重構，並且沒有提供適當的指南。

12. 發展勢頭

最後一個很重要的因素是發展勢頭，換句話說就是炒做。
炒做一般被認爲是一件壞事（「不要成爲炒做的受害者」），但事實並不是老是如此。
有了足夠的炒做動力，一個新的軟件項目才能夠吸引更多的用戶和更多的貢獻者，這意味着能夠更快地找到並修復錯誤，庫生態系統能夠獲得發展，每一個人最終都會變得更好。

JavaScript Rising Stars，繪製了 JavaScript 流行庫的增加狀況（https://risingstars.js.org/2017/en/）
固然，硬幣有另一面：過早進行過多的炒做可能會讓潛在用戶面臨一個充滿問題的不完整版本，而你一般只有一次機會給別人留下良好的第一印象。

評分系統

A：超過 9000 個 Star 的炒做水平：Hacker News 的頭條，成千上萬的 GitHub Star 數，在主要技術大會議上被說起。
B：最初推出時人們有一些興趣，數百個 GitHub Star 數。
C：孤獨的開發者在默默無聞地辛勤勞做，總有一天我會向人們展現一切!

更多因素

有些人提出了一些值得關注的其餘重要因素，或許我須要考慮將它們包含在 2.0 的評分制中！
伸縮性：是否適用於大型項目。採用：目前還有誰在使用該技術？兼容性：該技術與其餘現有技術的兼容性如何？解耦：若是你不想再用它，遷移有多容易？
案例研究：Apollo 客戶端
讓咱們用一個真實的庫來測試這個評分系統：Apollo 客戶端。

Apollo 客戶端（https://www.apollographql.com/client/）
Apollo 是一個 GraphQL 客戶端，換句話說，它是一個庫，查詢 GraphQL 端點並將數據加載到客戶端上。它還負責處理緩存之類的東西，確保數據不會重複，並將數據發送給前端庫。
讓咱們來看看它在評分系統中的表現！
特性：B
Apollo 爲咱們提供了更好的查詢數據的方法，所以它更多地是對現有工具的逐步改進。
穩定性：A
採用 Apollo 和 GraphQL 確實能夠更容易地推斷數據和追蹤問題。
性能：B
Apollo 提供了優化數據加載的工具，但整體上不會對應用程序的性能產生巨大影響。
庫生態系統：A
Apollo 的包系統被稱爲 links，這些 link 提供了額外的功能。
社區：B
Apollo 有一個很是活躍的 Slack 頻道，但根據個人經驗，有時候問題可能沒法獲得回答，很可貴到繁忙的核心團隊成員的回覆。
學習曲線：B
學習 Apollo 的全部細節可能會是一個挑戰，特別是若是你同時在學習如何使用 GraphQL。
文檔：A
爲多個前端框架以及示例代碼庫提供了良好的文檔。
工具：A
提供了瀏覽器擴展和專門的度量指標平臺。
歷史：B
Apollo 自己很年輕，GraphQL 也是如此。
支持團隊：A
資金充足的高競爭力團隊，具備其餘開源項目（Meteor）的開發經驗。
兼容性：B
從 v1 到 v2 帶來了重大變動，但整體上具備良好的穩定性和向後兼容性。
發展勢頭：B
Apollo 可能還不是一個家喻戶曉的項目，但它仍然是利基的主導者，儘管有 Relay 先聲奪人。
整體成績：A
得分 29（滿分 36），可見 Apollo 最終表現得很是好！即便還有須要改進的地方，但咱們也很容易理解爲何那些須要可靠方法來處理 GraphQL 數據的團隊會採用它。

其餘方法

NPMS 已經實現了一個相似的評分系統（https://npms.io/about），能夠查看 GitHub 和 NPM 的數據。這個系統的評分比較客觀，但沒有涵蓋文檔或社區等方面的內容。
在原始數據方面，你還能夠經過 NPM Trends 得到一些很酷的統計數據：

NPM Trends（https://www.npmtrends.com/）
經過 Best of JS 查看當前哪些庫最流行：

Best of Trends（https://bestofjs.org/）
固然，還有去年的 JavaScript 狀態調查：

JavaScript 2017 狀態調查（https://2017.stateofjs.com/）
英文原文
https://medium.freecodecamp.org/the-12-things-you-need-to-consider-when-evaluating-any-new-javascript-library-3908c4ed3f49