如何選擇評估 JS 庫

12 個評估 JS 庫

• 特性。

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

• 穩定性。

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

• 性能。

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

• 包生態。

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

• 社區。

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

• 學習曲線。

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

• 文檔。

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

• 工具。

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

• 發展歷史。

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

• 團隊。

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

• 兼容性。

評分：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 的年齡還很短，並且說很差將來還會被新語言、技術、容器顛覆而成爲歷史，標準化不是作不到而是須要時間，也許就在十幾年以後，可是今天就是作不到。

總結

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