反應式基本構建塊

mstmahmuda11121

Solid 與 Svelte 的方法不太接近，但它的規模仍然與 React 不同。 除了盡可能最小的應用程式的套件大小之外，我們還需要注意隨著應用程式變大，大小如何縮放： 圖：SolidJS - 指標和基準 指標和基準 該圖向我們顯示了包含 X 個組件的應用程式的總包大小（Y 軸），每個組件都包含一個 Todo 應用程式。在最左邊，我們再次看到 Solid 和 Svelte 以完全不同的起點開始。我們可以根據曲線的斜率看到擴展潛力：隨著元件數量的增加，Svelte 曲線相對急劇上升，而 Solid 和 React 則非常平坦。例如，對於大小在 100kb 左右的應用程序，我們使用 Svelte 還是 React 並不重要。對於兩個框架來說，在此限制下可能的功能範圍實際上是相同的。所以我們看到框架的選擇可以發揮重要作用，特別是對於非常小的應用程式。例如，25 個小型 Solid Todo 應用程式與一個 React Todo 應用程式具有相同的捆綁包大小。 接下來我們就來看看表現吧。


JS框架基準測試使用各種框架來比較各種任務的 100 多種不同實現，並測量互動持續時間、互動時 沙烏地阿拉伯 電話號碼 間和記憶體消耗。我們來看看這裡的互動速度： 圖SolidJS：JS框架基準測試 JS 框架基準測試 在最左邊，我們看到以 VanillaJS 手動優化的實作作為基礎值，即沒有框架。所以我們不能比這個基線走得更快。然而，緊隨其後的是 300 多行 JavaScript 程式碼，只有 81 行長、可讀性更強的 SolidJS 替代方案。因此，我們只損失了 7% 的效能，就獲得了明顯更好的開發人員體驗。 在 JS 框架基準測試涵蓋的所有指標中，SolidJS 要么是流行框架（React、Angular、Vue、Svelte）中最好的，要么幾乎與競爭對手不相上下。因此，如果我們非常重視效能和捆綁包大小，Solid 絕對不是一個錯誤的選擇。



到目前為止我們只討論了SolidJS的突出優點。當然，您還必須在這裡誠實地提到，使用該框架不僅有優勢。 最大的缺點可能是社區支持。由於 SolidJS 還相對年輕因此我們找不到與眾所周知的替代品一樣多的開源套件。在實踐中，例如，如果您需要 Font Awesome 集成或與流行的 GraphQL 客戶端 Apollo 集成，您通常必須自己完成。由於它們與 React 非常相似，實現此類套件相對較快，但npm install @apollo/react肯定更快。 此外，SolidJS 需要一定程度的重新思考。由於 React 的廣泛使用，我們習慣了在 Solid 中必須放棄的一些開發自由，這可能會導致問題，特別是在專案開始時。然而，該項目的 GitHub star 歷史表明該庫正變得越來越受歡迎，因此這個弱點可能很快就不再那麼重要了。 如果您到目前為止所讀到的內容吸引了您，我們強烈建議您嘗試使用框架。最簡單的方法是直接在瀏覽器中使用Solid Playground。我們希望您能享受這個新工具的樂趣，並享受擺脫框架開銷的自由！