JAVAScript框架之間的終極性能之戰

我在網上瀏覽時發現，兩年多來我們沒有一個不錯的JavaScript框架性能大賽。因此，在2020年總結之前，讓我們在將這些庫相互抗衡中獲得一些樂趣。

如何采用20個最受歡迎的JavaScript框架，并使用JS Framework Benchmark使其并駕齊驅？

免責聲明：此比較在整個過程中很有趣，也可能具有教育意義。和往常一樣，這里的每個庫對于大多數事情來說都足夠高效。如果有什么要強調的是，性能可以來自多種不同的技術。雖然您可以將其用作參考，但您應該獨立驗證各個用例的性能。您可以在這里找到最新的官方結果。如果您想進一步了解此基準測試的內容，請在此處發布指南。

還值得一提的是，我是Solid Framework的作者。因此，我不能在這里表現出任何偏見。但是我打算讓這些數字在很大程度上說明自己。撇開所有這些，享受比較。

競賽

我已經采用了JS框架基準測試的最新Chrome 87 監控結果。它們在Fedora 33下的Core i7 Razor Blade 15上運行，且緩解措施已關閉。

我過濾掉了所有有問題的實現，然后獲得了Github星級的前20個庫。對于具有多個版本的庫，我沒有使用第三方庫就獲取了它們的最新版本和性能最高的變體。

1. Vue (177k)
2. React (161k)
3. Angular (68.9k)
4. Svelte (40.5k)
5. Preact (27.9k)
6. Ember (21.7k)
7. HyperApp(18.2k)
8. Inferno (14.6k)
9. Riot (14.4k)
10. Yew (14.2k)
11. Mithril (12.5k)
12. Alpine (12.4k)
13. Knockout (9.9k)
14. Marko (9.9k)
15. lit-html (6.9k)
16. Rax (7k)
17. Elm (6.2k)
18. Ractive (5.8k)
19. Solid (4.7k)
20. Imba (4.1k)

注意：我將把LitElement實現用作lit-html示例，因為標準示例已被標記為問題。開銷應該最小，因為它是包裝在單個Web組件中的原始lit-html。

這是當前Web開發生態系統中相當不錯的一部分。盡管Github Stars并不是全部，但在比較中有100多個庫，因此我需要標準來選擇競爭者。

每個庫將在3個類別中進行比較：DOM性能，啟動指標和內存使用情況。此外，我將框架分為4組，以將它們與原始性能同級進行最佳比較。但是，我將在所有三個方面對庫進行排名。

在每個組中，將存在參考Vanilla JavaScript條目。使用所有最佳技術，此實現都經過了最佳化以達到最佳性能。它將作為所有比較的基準。

因此，讓我們開始吧。

第4組-標準性能

這是最大的組，由一些最受歡迎的庫組成。還有許多來自Facebook，google，eBay和Alibaba等公司支持的公司。這些庫要么在性能上較少關注某個方面，要么在某一方面強調性能，而在其他方面則受苦。

> Group 4 Performance

這里有很多紅色和橙色，但請記住，這些庫平均僅比我們在此處使用的痛苦手工制作的命令式Vanilla JavaScript示例慢大約2倍。400ms與200ms有何不同？

在原始性能方面，React是該包的領導者。考慮到架構的差異性，盡管它從未間斷令人驚奇，但React，Marko，Angular和Ember的整體距離有多近。仍然是React，這是React Hooks的實現，在這里是領導者。對于所有指向額外的函數創建并堅持使用類的人來說，性能參數不在您身邊。React Hooks是使用React的最高效的方法。

這里的大多數庫要么簡單的列表排序導致交換行性能確實很差，要么創建成本很高。Ember是這種情況的極端案例，因為它的更新性能比該組中的其他成員要好得多，但在某些最壞的情況下卻是創建過程。

最慢的庫（Knockout，Ractive和Alpine）都是具有類似架構的細粒度反應庫。Knockout和Ractive（也由Svelte的作者Rich Harris撰寫）來自2010年初VDOM庫主導之前。我還懷疑Alpine是否期望使用其JavaScript方法來渲染1萬行。在比較之后，我們將看不到另一個純粹的細粒度反應庫。

接下來，我們將主要根據庫捆綁軟件的大小來比較類別的啟動指標。

> Group 4 Startup

此處訂單變化很大。在Alpine性能最差的地方，我們可以看到它具有最小的捆綁包大小和最快的啟動時間。Marko（來自eBay）緊隨其后，其次是Rax（來自阿里巴巴）。所有這三個庫都是為服務器端渲染而構建的，主要是通過更輕松的客戶端交互來實現的。這就是為什么他們要進入第4組才能獲得出色的表現，但卻領先于這里的原因。

表格的后半部分是我們在基準測試中擁有的最大的捆綁軟件，以Ember結尾，是任何其他實現的兩倍以上。我不知道為什么要花費超過半兆字節才能呈現此表。但這確實會損害啟動性能。

我們要看的最后一類是內存消耗。

> Group 4 Memory

內存往往會反映出我們已經看到的模式，因為它會對性能產生重大影響，而大型庫往往會使用更多模式。Alpine，Marko和React引領潮流。老化的細粒度反應庫使用最多的Ember。Ember是巨大的。僅在頁面上渲染6個按鈕之后，它已經使用了比Vanilla在整個套件中要使用的更多的內存。

第4組結果

通常，該組在GitHub上代表30萬顆星，可能是NPM下載量的最大部分，但Marko和Alpine在此人群中的平均排名最高。在性能方面，React排名第三，僅次于他們。

這是我們擁有鈦白粉比例框架的組，而我們的舊React庫也已經消失了。讓我們繼續樂觀一些。

第3組-性能意識

在這些框架中，您可以知道已經考慮了性能。他們意識到規模，并且在創建和更新成本之間找到了平衡。我們看到了各種各樣的方法。Yew中的一個Web Assembly框架（用Rust編寫），LitElement中的一個Web組件。

事不宜遲，讓我們看看他們的做法。

> Group 3 Performance

分數已經提高了一點，我們看到的差距甚至更大。Preact是該組中性能最高的，僅增加了LitElement。Vue 3和Riot捆綁在一起，這兩個庫都位于中間，它們的歷史都包括反應性和VDOM。Mithril是最早將性能放在首位的VDOM庫之一，Yew是唯一的WASM庫尾部。

在性能方面，所有這些庫都是相似的。在這堆中沒有純的反應庫。它們都使用自頂向下的呈現方式，無論是VDOM還是簡單的Tag Template Literal diff。與上一組相比，它們的對帳清單更智能（請參閱交換行性能）。但是，大多數仍然具有某些最慢的選擇行性能。

Yew是例外，但在其他方面則較慢。讓我們看看其余的測試是否有幫助。

> Group 3 Startup

情況有所改觀，但在啟動指標方面，Preact仍然處于領先地位。Yew是這一堆中唯一真正的大型庫。WASM庫的確偏大。

再次，我們看到一種結果配對。Vue是Yew最大的第二名。Preact和Riot非常緊湊。Mithril和LitElement在中間

Preact是React的4kb替代品，絕對是我們迄今為止所看到的最小的庫。但是最小的庫仍在繼續。盡管如此，這個范圍內的任何庫都不應該太關注它們的包大小。

> Group 3 Memory

Yew這次贏了。在所有經過測試的框架中，它具有最小的內存占用量。WASM庫在這里往往做得很好。其他都非常接近。Mithril和普瑞特Preact是最差的，但不是很多。

這里沒有太多可拉的東西。您可能會認為LitElement示例可能比其他非紅豆杉庫更輕巧，因為它沒有像其余的那樣使用虛擬DOM。但是，正如我們將在以后看到的，VDOM并不意味著更多的內存。

第3組結果

Riot和Preact的平均排名最高，其次是LitElement，排名第三。Riot雖然沒有脫穎而出，但在這個小組中沒有弱點，因此取得了勝利。但是，對于這些框架中的任何一個都很難失望。借助WASM和Web組件，它們代表了許多人認為Web的未來。

但是我們還沒有完成。下一組代表對網絡未來的不同想法。輸入編譯器…

第二組-性能冠軍

這一組是激烈的競爭。我們擁有大多數被稱為編譯語言的庫。每個都有自己的風味。我們擁有不變的結構化Elm，受Ruby啟發的Imba和"消失的" Svelte。

注意：引起我注意的是，并不是每個人都熟悉Svelte以前的"消失的框架"綽號。它描述了從輸出中基本進行自我編譯的能力。我不是在建議Svelte去任何地方。對帶來困惑感到抱歉。

奇怪的是HyperApp，它與其他應用程序完全相反。沒有編譯器。沒有模板。只需h函數和一個最小的Virtual DOM。

猜猜這將如何發展？

> Group 2 Performance

好吧，最小的虛擬DOM勝出。與最近的言論相反，事實證明虛擬DOM不僅是性能不佳的秘訣，而且編譯并沒有使其他庫受益。

在已編譯的庫中，我們實際上看到了3種不同的方法來渲染所有具有大約相同的平均性能。Imba使用DOM協調（更接近我們之前看到的LitElement），Elm使用虛擬DOM，最后一個Svelte使用組件反應系統。

您應該注意，虛擬DOM庫的選擇行最差，因為這是其額外工作所顯示的。但是這些庫還具有更快的初始渲染。如果您仔細觀察到目前為止的結果，您應該注意到Virtual DOM庫與Reactive庫之間的共享特性。但除此之外，性能還很嚴格。

因此，讓我們繼續。我們的編譯器如何調整啟動時間/捆綁大小？

> Group 2 Startup

好吧，正如您所看到的那樣，這個小的虛擬DOM庫不僅性能更高，而且比其他的更小。實際上，HyperApp是我們所有庫中最小的實現。編譯器無法贏得成功。

它和Svelte都比我們的Vanilla JavaScript參考構建小。那怎么可能？以一種更可重用的方式編寫更少的代碼來編寫抽象。Vanilla JS實現針對性能而非大小進行了優化。

Elm在這個群體中仍處于規模競爭中。但是，Imba開始進入某些第4組庫的范圍。

好了，留下記憶。編譯器大放異彩的最后機會。

> Group 2 Memory

內存接近，幾乎是平局，但是Svelte最終為編譯器贏得了勝利。對虛擬DOM的一些甜蜜的報復顯示它比它更小，更快。

老實說，所有這些庫都具有出色的內存配置文件。現在應該很清楚，更少的內存和更好的性能之間的關系。

第2組結果

不相信炒作嗎？

不。更多的事情比表面上看起來復雜。精心設計的系統，無論是運行時還是編譯時，或者無論采用何種技術方法，都可以制成高性能的系統。

HyperApp是該組的明顯贏家，其后是Svelte，其次是Elm和Imba。通過這種對性能的專注，您知道這些庫在大多數情況下都可以提供，并且始終顯示在基準測試的頂部。

那還剩下什么？

如果我告訴您，聲明性JavaScript庫對它們的性能如此有信心，就不用擔心原始WASM，Web Worker或您使用的任何技術，該怎么辦。歡迎來到…

第一組-性能精英

在某一時刻，它可能被稱為"超快"，我相信它曾經是這些庫的口號之一。如果您要跟蹤的話，只剩下2個庫了。實際上，這類庫中有少數幾家不斷推陳出新。但是在流行的中只有2種。它們平均比原始的手工優化Vanilla JS慢20％。

這是要看的東西。在這里，我們有2個庫，如果查看它們的代碼，它們可能被視為同級庫，但使用的方法完全不同。Inferno是世界上性能最高的虛擬DOM庫之一。在最出色的5個執行者中，有3個是虛擬DOM庫。選擇行測試的速度下降可以視為證據。

另一方面，Solid使用細粒度的反應性，例如第4組中最慢的舊庫。重新出現此技術的位置很奇怪，但正如我們所見，Solid解決了它們的弱點。創建時間與更新時間一樣快。與Vanilla JavaScript的5％差距令人難以置信。

奇怪的是，Inferno和Solid的共同點是JSX模板和React受啟發的API。對于所有其他具有經過優化的自定義DSL的庫，也許您不會期望在性能的頂峰找到任何東西。但是，正如HyperApp所示，某些事情對性能的影響比人們想象的要小。

> Group 1 Startup

Solid將HyperApp和Svelte作為第三個庫加入，其庫比Vanilla JS實現小。但是Inferno也不是懈怠。

似乎性能庫較小時，有時添加更多代碼可以提高性能。更好的列表協調算法，更明確的防護措施，更精細的更新。

Inferno可能比前幾組中的某些庫更大，但它仍然是一個10kb以下的庫，并且幾乎在所有性能上均不如預期。

> Group 1 Memory

在那里。除了Yew及其對WASM的使用以外，它們是整個競爭中最低的內存消耗框架。考慮到他們的表現，這并不奇怪。

這種內存消耗數字反映了對對象的非常仔細的考慮，并創建了閉包。其中很多確實來自兩個庫都進行的定制JSX轉換。

內存性能的提高對Solid尤為重要，因為Solid與大多數細粒度的反應式庫一樣，都將CPU開銷換成了內存消耗。在這種比較中，能夠征服內存開銷是Solid如何采用與大多數最慢的庫類似的技術并使之成為最快的方法的很大一部分。

第一組結果

天空是極限。

…或者說Vanilla JavaScript是。但是我們這里的聲明式庫性能如此之差，您永遠都不會知道它們之間的區別。當使用DOM時，我們需要認真考慮，許多不同的技術可以有效地渲染DOM。

我們在這里看到它。Solid在十年前就被認為是古老而緩慢的技術，奪得了性能冠軍，而Inferno再一次證明了虛擬DOM不能高效完成的工作。

結論

在構建JavaScript前端時，我們有很多選擇。這只是快速瀏覽框架帶來的性能開銷。當涉及到應用程序中的實際性能時，用戶代碼具有更大的影響。

但是，我真正想在這里打動的是，測試您的解決方案并了解性能是很重要的。現實總是與營銷不同。虛擬DOM不能保證很慢。不能保證編譯器會產生最小的捆綁包。自定義模板DSL不能保證是最佳的。

最后，我將為您提供完整的表，將所有庫一起顯示。僅僅因為庫快要結束了，并不一定意味著它很慢，但是與這些競爭激烈的競爭對手相比，它的得分更差。

所有框架

單個圖表中的所有框架。

性能

啟動

內存

最終排名

所有結果都添加到一個列表中（第1名獲得20分，最后1名獲得分）。在平局的情況下，性能優先。

1. Solid (57)
2. HyperApp (54)
3. Inferno (51)
4. Svelte (51)
5. Elm (46)
6. Riot (40)
7. Preact (39)
8. Imba (36)
9. lit-html (36)
10. Yew (32)
11. Vue (29)
12. Mithril (29)
13. Marko (28)
14. Alpine (28)
15. React (19)
16. Rax (16)
17. Angular (12)
18. Knockout (11)
19. Ractive (8)
20. Ember (6)

特別提及AJ Meyghani在2018年的比較，這啟發了這篇文章。

(本文由聞數起舞翻譯自Ryan Carniato的文章《JavaScript Frameworks, Performance Comparison 2020》，轉載請注明出處，原文鏈接：https://medium.com/javascript-in-plain-english/javascript-frameworks-performance-comparison-2020-cd881ac21fce)