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

我在網上瀏覽時發現，兩年多來我們沒有一個不錯的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等公司支持的公司。這些庫要么在性能上較少關注某個方面，要么在某一方面強調性能，而在其他方面則受苦。

這里有很多紅色和橙色，但請記住，這些庫平均僅比我們在此處使用的痛苦手工制作的命令式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萬行。在比較之后，我們將看不到另一個純粹的細粒度反應庫。

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

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

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

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

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

第4組結果

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

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

第3組-性能意識

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

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

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

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

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

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

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

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

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。

猜猜這將如何發展？

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

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

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

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

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

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

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

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

內存接近，幾乎是平局，但是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所示，某些事情對性能的影響比人們想象的要小。

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

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

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

在那里。除了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)

程語言正在不斷演化，但預測 5 年后會如何則很有難度，作者給出了一個答案。

作者 | Timothy Mugayi

譯者 | 明明如月，責編 | 唐小引

封圖 | CSDN 付費下載自 VCG

出品 | CSDN（ID：CSDNnews）

在這篇文章中，我們將看到一個我自己手動排行的編程語言和框架的列表，我相信這些語言和框架在未來 5 到 10 年內仍然堅挺。我不希望這個編程語言列表帶有太多偏見。確定這個名單非常困難，因為每個人都會有些許偏見。當我草草記下我的想法時，我在思考隨著時間推移編程的范式和創新是否符合演變。2020 年后，更快，更易用，更實用，更抽象的抽象技術變得流行。在此精選列表是基于我對技術的趨勢、工作機會、使用情況、范例、基于流行性的統計以及未來的技術創新來預測的。

在科技界一年就像一生，因此在未來 5 年內可能會發生很多變化，但我相信這份精心策劃的清單仍然很重要。如果您剛開始學習如何編程，不知道該選擇哪種語言或框架，那么這份精選清單則可以幫到你。

回顧

當我們踏入 2020 年，回顧過去 5 年，很多事情都發生了改變。如區塊鏈、深度學習、量子計算等新技術開始出現。對于那些剛剛開始學習編程甚至是經驗豐富的開發人員來說，為了在這個不斷變化的領域中保持與時俱進，思考自己在目前的發展狀況大有裨益。現在就是學習新技術的最好時機。

為什么確保你選擇和學習正確的語言或框架很重要？

學習一門新的語言和框架對你來說是一種投資，你花的金錢和時間有去無回。 技術總是在不斷變化，隨著年齡的增長，保持與時俱進的需求變得越來越重要。選擇正確的語言和框架可能會改變你的一生，可能會徹底改變你做工作的方式和發展軌跡。因此你肯定想選擇一個近幾年不會過時的編程語言。

Rust

Rust 是一種系統編程語言，旨在取代 C 和 C++ 開發。Rust 提供了和 C 和 C++ 匹敵的性能，但是使用起來更加友好。對于那些已經在 c / C++ 中編寫了很長時間的程序的人來說，他們非常喜歡聽到這樣的話。

已經有相當多的新開發者涉足這個領域。Rust 擁有不斷增長的用戶群。有數百家公司使用 Rust 進行開發，比如 Dropbox、 Yelp 和 Cloudflare。亞馬遜最近宣布的虛擬化技術 Firecracker 這種產品也使用的是 Rust 的。在 StackOverflow 的 2016 年開發者調查中，Rust 也被評為“最受歡迎”的技術 （這意味著更多的用戶會堅持使用 Rust）。

盡管與那些已經問世幾十年的其他編程語言相比，它還是相對比較年輕，但它擁有大量可用的庫，可以用來加速開發。你可以在 crates.io 或 GitHub 上找到你需要大多數的東西。

Rust 的主要特征

Rust 的主要特征是運行速度快和內存利用率高。它沒有運行時或垃圾收集器，它適合用在對性能要求高的關鍵的服務，它可以在嵌入式設備上運行，并且很容易與其他語言集成。在接下來的 5 年和 10 年里，隨著我們遇到硬件編程語言的限制，這些語言的速度更快，占用的內存更少，提高了速度和響應能力，使我們能夠更省力的編寫代碼，這類語言將變得更加重要。

• 可靠性：Rust 豐富的類型系統和所有權模型保證了內存和線程的安全，并能夠在編譯時消除許多錯誤。

• 生產力：Rust 有很好的文檔，提供了一個非常友好的編譯器，錯誤信息提示非常友好。C，C++ 代碼的編譯器提示消息則是出了名的難以理解。Rust 的編譯器則更好。如果你想學習系統編程，使用“ rustc”編譯器做可以讓你不用擔心內存安全而能夠專注其他的事情。

正如一位著名的程序員曾經說過：Pascal 就像穿著緊身衣，C 就像在玩刀，而 C++ 就像在玩弄燃燒的電鋸。在這個比喻中，Rust 就像是穿著保護裝備懸掛在繩子上做跑酷運動。是的，這看起來有點可笑，但是你可以用它做各種很酷的動作而不傷害自己。

Python

在過去的幾年里，Python 的流行度一直在穩步上升，尤其是在過去的 10 年里，最終邁進了 TIOBE 指數的前 5 名。

Python 非常實用。對于初學者來說，它是一個腳本語言，這意味著入門非常快，不像 java 還需要編譯。它的本質是面向對象的語言。在大學的許多學術課程中，Python 已經取代 Java 成為默認的首選編程語言。對于初學者來說，安裝 Python 解釋器并運行非常容易。

$ print (‘hello world this is my. First program’)

如上述代碼所示，你的第一個程序就這樣用 Python 寫完了。

Python 正在為未來鋪平道路。它在未來 5 年乃至更長的時間段內都將具有較大影響力。Python 已經讓機器學習、深度學習、人工智能、大數據等所有流行的數據科學流行語等新的技術范式成為可能。互聯網上有大量成熟的庫，如 TensorFlow、 Scikit-Learn、 Dask for distributed Data Science 大規模可擴展計算， Python 也可以用于量子計算。雖然我們離量子計算還相對較遠，但是 Python 是一個可以確保你作為一個量子程序員的地位的語言。

Python 在企業和初創企業中都很受歡迎。在過去 5 年中已經取得了巨大的進展。現在一些使用廣泛的平臺，比如 Reddit和許多 Google 庫都是建立在 python 之上的。

我個人使用 Python 編寫腳本并快速自動化許多任務。它一直是一種讓自由職業者快速完成項目的不可多得的語言。

Python 提供了可以訪問網絡框架，比如 Django 框架，它是構建前端和后端網絡應用的最好的 Python 框架之一。堅持 DRY 原則快速構建應用程序的哲學，需要很少的代碼量和需要很少的編程經驗。

Ruby

Ruby 是另一個功能強大的高級語言，它可以讓你輕松地構建應用程序。作為面向對象程序設計語言，對于那些有 Python 開發經驗的人來說，Ruby 語法看起來與 Python 非常相似。該語言還配備了構建復雜應用程序所需的所有工具。

許多硅谷的初創公司都是建立在 Ruby 之上的，比如 Airbnb、 Twitch、 GitHub 和 Twitter。Ruby on Rails 是一個運行 Ruby 的全堆棧 Web 應用程序框架，這讓 Ruby 更加流行。

Ruby 的一些關鍵特性：

• 提供了一個健壯的高質量庫。

• 語法簡單，有助于快速開發原型。

• 學習門檻低，新程序員很容易上手。

• 是一種面向對象程序設計語言，所以你可以擁有一切面向對象語言的優勢。

• 由于 Rust 的內存占用很小，可用于構建分布式在線服務或網絡服務。

Golang

Go（Golang）是 Google 開發的一種相對較新的編程語言。它最近越來越受歡迎。 提供了極好的多線程支持，因此，許多嚴重依賴分布式系統的公司都正在使用它。它是為解決谷歌面臨的一些棘手問題而設計的。谷歌還將 Go 作為新項目的主要語言，并用 Go 取代其他語言。因為谷歌與我們的日常生活息息相關，所以我們不可能忽視它，認為它在可預見的未來將繼續保持活躍。

我必須承認，它是一門非常優雅的編程語言，語法很簡潔。它在動態類型語言、解釋性語言的易用性和類型安全、內存安全之間取得了平衡。

主要功能：

• 由于有內在并發支持，它可以有效提高 CPU 利用率。擅長云系統開發，分布式系統，微服務。

• 輕量級、執行速度快和開發效率高。

• 內存占用和二進制文件較小。

• 自動垃圾收集。

• 無異常，它自己處理錯誤， 等。是的，你沒看錯。這對你來說意味著什么？您必須準確地知道如何自己處理這些錯誤，而不是拋出一堆 try-catch 異常。仔細想想是不是這樣？

有趣的事實：

• 全球 Go 語言開發人員平均年薪: 109,483 美元。在美國，這種頂級編程語言的平均年薪為13.6 萬美元。

• 在 2019 年 Stack Overflow 開發者調查中，Go 是全球排名第三的高薪語言。

• GitHub 上第四活躍的編程語言。

GraphQL

與今天相比，以前的 Web API 設計相對簡單，有用于從服務器檢索數據的 REST 表示狀態轉移標準，該標準是基于URL來訪問數據的。

然而，需求增長超過了標準。數據不再是之前靜態的樣子了，它更加動態，因此 GraphQL 應運而生。GraphQL 是 REST 架構的替代方案，旨在克服REST的缺點。與 REST 不同，GraphQL 允許脫離固定數據結構方式來請求客戶機需要的特定數據。在后端，GraphQL 向 API 指定如何向客戶端顯示數據。GraphQL 通過 API 重新定義了開發人員的工作，這些 API 為市場提供了更多的靈活性和速度；它改善了客戶機與服務器之間的交互，使前者能夠進行精確的數據請求，準確的獲得他們所需要的東西。

最初由 Facebook 在 2012 年創建，GraphQL 內部用在他們的移動應用程序，通過其特定的數據獲取功能來減少網絡使用。從那時起，GraphQL 規范開源了。現在主要的編程語言如 Python，Java，c # ，Node.js 等都支持它。

由于其生態系統的快速擴張，這使得它成為在可預見的未來繼續堅挺的技術之一。它有豐富的擴展庫和功能強大的工具，如 Apollo、 GraphiQL 和 GraphQL Explorer。

GraphQL 的一些關鍵特性：

• 查詢速度更快，選擇查詢的字段減少請求。

• 非常適合復雜系統和微服務。通過其 API 集成多個系統。

• GraphQL 可以將來自多個地方的數據聚合成單個 API。

• 不存在過多或過少抓取的問題。眾所周知，REST 響應要么包含過多的數據，要么包含的數據不夠。

• 驗證和開箱即用的類型檢查。

• 自動生成 API 文檔可取代 Swagger，并且在 GitHub 問題中可以找到使用規范。

• 無版本的 API 演進，這是 REST 的一個常見問題隨著 API 演進，你不得不創建一個新的 API 或者在 URL 前面加上版本，并且有無可挑剔的文檔。通過使用 GraphQL，你可以得到一個單一的、不斷發展的版本，這使你的應用程序可以不斷地訪問新特性，并且鼓勵編寫更簡潔、更易維護的服務器代碼。

GraphQL 并不是試圖取代 REST，它們是解決不同類型問題的兩個不同的東西。隨著我們邁向大數據，投入一些時間學習 Graphql 就非常有必要。

Angular

Angular 由 Google 開發的，一種用于軟件開發的成熟的 TypeScript 框架。它是構建 web 和移動應用程序的主要開源框架之一。Angular 是一個完全基于 AngularJS 改寫的。從 AngularJS 開始，它在剛開始的時候就具有一定的影響力，現在 Angular 經過多年的發展，它已經發展成為一個全面的開發框架，其中包括了構建網絡和移動應用所需的所有工具和組件。這個框架的美妙之處在于它遵循著一個清晰的路線圖，每六個月發布一個新的 Angular 主版本，如果你想長期使用 Angular 的話，這點很重要。

Angular 的主要特征：

下面只討論 Angular 9 中提到的特性，這些特性可能會解決性能問題。

• Google 為這個框架提供了長期的支持，并不斷地改進它。定期改進非常受追捧，這表明這個框架有一個充滿活力。因此，鑒于谷歌正在支持它并對其進行投資，表明該框架在可預見的未來仍將具有相關性。

• Angular 9 的另一個關鍵特性是通過 Ivy Compiler 減少了大包文件，從而占用了很小的空間 —— 試圖通過減少 JavaScript 包的大小，Ivy 加快應用程序啟動。

• 為需要支持多種語言的應用程序提供更好的國際化支持。

JavaScript

我斗膽說一句：JavaScript 是一個不可替代的語言，毫無疑問它將在未來的幾年里繼續存在。因此，投資學習這門語言非常劃算。它不僅僅是一個客戶端的開發腳本語言，通過像 Node JS，Angular 和 React 這樣的框架和庫，你還可以在服務器端使用 JavaScript 來開發用戶界面。

JavaScript 是所有大型科技公司的核心，比如 Netflix，Facebook，Google 等等。因此，JavaScript 作為一種語言和其他編程語言一樣都具有合法地位。2020 年是開始投資的一年。把你的空閑時間投入到學習 JavaScript 上來吧。

現在想一想，幾乎所有的網站都在某種程度上使用了 JavaScript。

榮譽獎

Webassembly ( 縮寫為 Wasm) 應該獲取榮譽獎，但不能成為前 7 名，因為它既不是框架也不是編程語言。

Wasm 被設計為編程語言的編譯目標和二進制格式，其目標是為 web 應用程序提供接近本機的性能。這意味著什么？把它想象成一個公共的中央平臺，開發人員可以將各種編程語言編譯成 web 匯編，然后在這個平臺上運行它們。另一個類比是它是所有編程語言的 Java 虛擬機。

從本質上講，每當您在 Internet上通過 Web 瀏覽器運行應用程序時，Wasm 都將目標定為 Web 應用程序的近乎本機的性能，在接下來的 5 年中，大多數情況都需要用到 Wasm。想想那些需要完美表現的網絡游戲吧。通過點擊一個按鈕，你就可以從服務器下載應用程序代碼，并將其加載到運行 Wasm 的瀏覽器虛擬機中。Wasm 得到了如 Mozilla，微軟，谷歌和蘋果等大企業的支持。

這種 Web 匯編的廣泛應用鼓勵去中心化計算，例如 Ethereum 正在著手開發 ether 2.0，在本文撰寫之時，Ethereum 將利用其新提出的重新設計智能合同執行層的建議，使用 WebAssembly 的確定性子集。在這個巨大的數字化空間里，學習模型正逐漸成為軟件開發人員構建、人與應用交互的技術支柱。

Web 匯編可以讓 JavaScript 做它擅長的事情，并將它不能做的部分委托給其他語言。可以把它想象成下一代 Web Ajax。Ajax 使客戶端應用程序成為可能。Web 匯編允許您超越僅僅使用 JavaScript 進行節點或 JavaScript 可能不擅長的復雜的低級計算。因此，web 匯編的未來看起來是前途一片光明。

總結

如果你仔細想想，所有的編程語言和框架都有能力構建復雜而強大的功能， 都可以構建解決現實世界中緊迫問題的應用程序。沒有放之四海而皆準法則，因為每種語言和框架都有其優勢和不足，以及有意義或無意義的地方。對語言的需求是由用例、市場需求或使用該專業知識的資源庫驅動的。

永遠記住，任何編程語言或框架的目標都是完成任務，要選擇最適合你的技術。

真正的敏捷適應性和迭代學習才能真正讓你在未來幾十年保持與時俱進。就我個人而言，作為一個通曉多種語言的開發者，這為我敞開了大門

如果你喜歡這篇文章，那么請與你的朋友和同事分享，如果你認為這些語言在未來 5 年內將不再適用，那么請評論，我也很樂意聽到你的聲音。

英文：Top 7 Programming Languages & Frameworks To Learn in 2020 That will Still be Relevant In 5+ Years

鏈接：https://medium.com/swlh/top-7-programming-languages-frameworks-to-learn-in-2020-that-will-still-be-relevant-in-5-years-11245d7e2d56

作者簡介：Timothy Mugayi。技術傳播者，講師，多語言開發者，熱愛技術創新

譯者：明明如月，知名互聯網公司 Java 高級開發工程師，CSDN 博客專家。