在使用新的JavaScript庫時須要考慮的12件事

您如何知道一項新技術是否值得投入時間？

對於今年的JavaScript狀態調查，我想深刻挖掘一下，不只知道人們正在使用哪些工具和庫，還要爲何他們選擇使用它們。

這意味着我必須找到一種方法將我的偏好轉化爲冷酷的數據。通過一些研究，我提出了12分制，涵蓋了挑選和使用任何技術的主要方面。

在此邀請你參加測試 ➡️ Take the 12-Factor Quiz
若是您不肯定要評估什麼，只需在您熟悉的庫（React，Vue，jQuery ......）上進行評！
也能夠在http://stateofjs.com/ 上面查看一下往年的結果
若是您想貢獻並幫助肯定JavaScript生態系統的最新趨勢，參加調查！

如今回到12分制。

因素

這裏有一張列表：

• 🕹️ 特徵
• 🐞 穩定性
• ⚡ 性能
• 🎁 Package 生態系統
• 🌎 社區
• 👶 學習曲線
• 📖 文檔
• 🔧 外部輔助工具
• 🏛️ 跟蹤記錄
• 👫 團隊
• ⚖️ 兼容性
• 📈討論度

我將解釋每一個因素的重要性，併爲您提供一個評分網格，向您展現如何評估它。咱們來看看清單吧！

🕹️ 特徵

你選擇任何技術的第一個緣由多是它的做用。

但這裏的關鍵問題是你到底是須要這個庫的什麼。React多是目前最流行的前端庫，但仍是有人以爲它作的不夠好，由於它將路由和狀態管理等內容留給第三方方庫，如React-Router和Redux。

事實上，這是React最大競爭對手Vue的吸引力的一個重要部分。經過爲這些常見用例提供官方軟件包，它能夠提供更全面的解決方案並得到大量支持。

因此有時候，最簡單的方法就是弄清楚咱們究竟須要什麼。像Lodash或Ramda這樣的庫讓你能夠用簡潔的函數表達式替換亂糟糟的嵌套for循環，這足以使它們成爲無價的工具。

一樣，這一切都是爲了尋找合適的！

評分系統

• A: 是否能作到之前作不到的事。
• B: 讓你作與之前相同的事情，但以更好的方式。
• C:是否優於當前的解決方案。

🐞 穩定性

您能夠擁有最優雅，功能全面的框架，但若是開發人員每兩分鐘發生一次錯誤，卻也一樣讓人感到崩潰。

所以，當前JavaScript生態系統中的許多工具都專一於爲堆棧添加穩定性和安全性。看TypeScript和Flow的成功，甚至是Reason等語言。

在數據層方面，GraphQL的類型系統也有助於確保一切順利運行。

評分系統

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

⚡ 性能

若是你曾經訓練過武術，你就會知道你能夠擁有的最好的屬性之一是speed，而不是力量。

一樣，若是您的應用須要15秒才能加載，那麼世界上的全部功能都無濟於事。到那個時候，用戶已經關閉了標籤，你甚至在它開始以前就已經失去了戰鬥！

在JavaScript生態系統中，只需看看Preact就能夠看到關注速度的一個例子：它的API與React徹底相同，因此它並不試圖在功能強度上展開競爭。可是，與React相比，它重量更輕，加載速度更快，能夠節省寶貴的毫秒數並提升webapp的性能。

評分系統

• A: 更小的體積，更快的加載時間或其餘性能改進。
• B: 採用該技術不會對您的軟件性能產生影響。
• C: 採用該技術能夠顯着下降您的應用程序速度。

🎁 Package 生態系統

在投資任何新技術以前，重要的是要看看圍繞它開發的生態系統。

一個充滿活力的軟件包生態系統不只能夠節省大量時間，這也代表該技術已經達到了必定的成熟度水平。出於這個緣由，維護良好的第三方軟件包是開發人員長期採用技術的最佳標誌之一。

評分系統

• A: 生態系統對共同關注的問題有明確的解決方案;第三方軟件包維護良好且文檔齊全。
• B: 具備許多競爭新選擇的萌芽package生態系統。
• C: 沒有package生態系統可言，須要大量的手工工做。

🌎 社區

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

查找Stack Overflow現有的存儲庫也頗有幫助。固然，維護良好的GitHub問題頁面是必須的！

評分系統

• A: 論壇和/或聊天室（Slack / Discord / etc。）平常活動，GitHub問題在一天內獲得解決。許多人回答了Stack Overflow問題。
• B: 論壇和/或聊天室，不常常活動。
• C: 除了GitHub以外沒有社區。

👶 學習曲線

簡單的學習曲線使開發人員更有可能爲您的框架或庫提供一個機會。人們很容易認爲，若是一項技術真正具備破壞性，人們就會克服任何障礙，但這一般都不是真的。

一個密切相關（但有時相反）的概念是「採用」曲線。首次推出時，[Meteor]（http://meteor.com/）很是易於使用（至少與現有替代方案相比），但它要求您當即採用整個堆棧，所以很難實現現有項目。

React也以其粗略的學習曲線而聞名：對於用於分離HTML和JavaScript的開發人員來講，不得不使用JSX可能很難。另外一方面，Vue變得更容易，而沒必要從新思考您對前端編碼的思考方式。

評分系統

• A: 能夠在一天內開始。
• B: 在提升工做效率以前須要大約一週
• C: 超過一週須要學習基礎知識。

📖 文檔

簡單學習曲線的一個重要部分就是擁有出色的文檔。這比聽起來更難實現，由於撰寫文檔的人一般是經驗最豐富的人。

所以，編寫好的文檔須要忘記你原有的技術知識，並讓本身置身於發現你的技術之中。

它還須要預測常見問題，瞭解用戶的心理模型，最重要的是在代碼庫發生變化時保持最新狀態！全部這些都須要寶貴的時間......

鑑於全部這些因素，您能夠理解爲何好的文檔是一種罕見且有價值的東西！

評分系統

• A: 專用文檔站點，截屏視頻，示例項目，教程，API文檔和評論良好的代碼。
• B: 基本自述文件和API文檔。
• C: 很是簡潔自述，瞭解如何使用庫的惟一方法是查看其代碼。

🔧 外部輔助工具

就像文檔同樣，工具是這些事情中的一個，對於某些維護者來講可能看起來像是次要的，但實際上對於任何技術的普及和成功都相當重要。

我相信Redux成功背後的一個重要緣由是其使人驚歎的Devtools瀏覽器擴展，它容許您以很是用戶友好的方式可視化Redux存儲和操做。一樣，VS Code的強大TypeScript支持也爲它的採用創造了奇蹟。

評分系統

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

🏛️ 跟蹤記錄

由於若是一個庫只存在了六個月，那就不過是曇花一現了。

咱們均可以講述採用「下一件大事」的故事，只是回到好老的Rails / PHP / 在這裏插入嘗試真實的技術 當事情開始惡化時。

出於這個緣由，沒有什麼能夠打破堅實的記錄。Express是其中一個例子：它最初是在2010年發佈的，但仍然被認爲是默認的Node.js服務器框架，儘管JavaScript生態系統的發展速度很快。

評分系統

• A: 已經有4年多的時間，經過了主要公司和知名的技術諮詢公司。
• B: 已經存在了1 - 4年，被早期採用者和較小規模的諮詢公司使用。
• C: 已經存在不到一年，尚未真正的採用。

👫 團隊

並不是全部項目都有可跟蹤的記錄。當package是全新的，你如何判斷它的潛力？一種可靠的方式來看看它背後的人。

當React第一次出現時，因爲其背後的團隊是Facebook，因此給人一種至少要嘗試一下的感受。而後Facebook繼續發佈Relay和GraphQL，代表React的成功不是僥倖！

更大的公司也有更多的投資資源：即便發佈了更新的，不兼容的版本，谷歌也可以繼續保持原有的Angular.js。

固然，這並不意味着單獨的維護者就沒法創造重大創新。畢竟有Vue.js這樣的例子存在，更不用說99％的開源軟件了。

評分系統

• A: 由一家擁有專門的開源團隊的大公司維護。
• B: 由中型工程師團隊維護，擁有堅實的我的記錄。
• C: 孤獨的維護者獨立工做。

⚖️ 兼容性

採用尖端庫的好處在於它們一般發展得很是快。可悲的是，這也多是一個重大的缺點！

快速改進率也意味着頻繁的突破性變化，由於新的最佳實踐取代了舊的模式，使早期採用者付出了重構成本。

React Router當他們決定在版本3和版本4之間徹底改變他們的API時，產生了不少抱怨。Angular當他們從Angular.js切換到新的「只是Angular」時，也是如此。

當你剛開始一個新項目時，常常更新會很使人興奮，可是一旦你的應用程序啓動並在生產中運行，你並不會想要每次都由於庫的更新而其改動線上的代碼。

評分系統

• A: 更新大可能是向後兼容的，棄用是經過警告處理的，不兼容的舊版本維護兩年或更長時間。
• B: 確實發生了重大變革，但有很好的文件記錄，並逐步推出。
• C: 沒有適當的指導，常常須要進行重大更新。

📈 討論度

最後但一樣重要的是，勢頭。換句話說，炒做。

炒做一般被認爲是一件壞事（「不要成爲炒做的犧牲品」），做爲風格超過實質的指標。但並不是老是如此。

有了足夠的動力，一個新的軟件項目能夠吸引更多的用戶和更多的貢獻者，這意味着能夠更快地找到和修復錯誤，一個包生態系統能夠開發，每一個人最終都會變得更好。

可是，是的，還有硬幣的另外一面：過早炒做太多可能會讓潛在用戶面臨一個充滿問題的未完成版本，並將其完全解決。就像他們說的那樣，你只有一次機會給人留下第一印象。

評分系統

• A: 炒做超過9000：黑客新聞的頂部，成千上萬的GitHub star，在主要會議上進行會談。
• B: 最初推出的一些興趣，數百名GitHub明星。
• C: 孤獨的開發和辛苦工做。

更新：更多因素

大家中的一些人提出了一些更重要的因素。要考慮潛在版本2.0的規模！

• 可擴展性：該技術對大型項目的效果如何？
• 採用：目前還有誰在使用該技術？
• 兼容性：該技術與其餘現有技術的合做程度如何？
• 解耦：若是你想中止使用它，從技術遷移出來有多容易？