整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
avaScript框架之間的終極性能之戰(zhàn)
我在網(wǎng)上瀏覽時發(fā)現(xiàn)，兩年多來我們沒有一個不錯的JavaScript框架性能大賽。因此，在2020年總結(jié)之前，讓我們在將這些庫相互抗衡中獲得一些樂趣。
如何采用20個最受歡迎的JavaScript框架，并使用JS Framework Benchmark使其并駕齊驅(qū)？
免責(zé)聲明：此比較在整個過程中很有趣，也可能具有教育意義。和往常一樣，這里的每個庫對于大多數(shù)事情來說都足夠高效。如果有什么要強(qiáng)調(diào)的是，性能可以來自多種不同的技術(shù)。雖然您可以將其用作參考，但您應(yīng)該獨(dú)立驗(yàn)證各個用例的性能。您可以在這里找到最新的官方結(jié)果。如果您想進(jìn)一步了解此基準(zhǔn)測試的內(nèi)容，請在此處發(fā)布指南。
還值得一提的是，我是Solid Framework的作者。因此，我不能在這里表現(xiàn)出任何偏見。但是我打算讓這些數(shù)字在很大程度上說明自己。撇開所有這些，享受比較。
我已經(jīng)采用了JS框架基準(zhǔn)測試的最新Chrome 87 監(jiān)控結(jié)果。它們在Fedora 33下的Core i7 Razor Blade 15上運(yùn)行，且緩解措施已關(guān)閉。
我過濾掉了所有有問題的實(shí)現(xiàn)，然后獲得了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實(shí)現(xiàn)用作lit-html示例，因?yàn)闃?biāo)準(zhǔn)示例已被標(biāo)記為問題。開銷應(yīng)該最小，因?yàn)樗前b在單個Web組件中的原始lit-html。
這是當(dāng)前Web開發(fā)生態(tài)系統(tǒng)中相當(dāng)不錯的一部分。盡管Github Stars并不是全部，但在比較中有100多個庫，因此我需要標(biāo)準(zhǔn)來選擇競爭者。
每個庫將在3個類別中進(jìn)行比較：DOM性能，啟動指標(biāo)和內(nèi)存使用情況。此外，我將框架分為4組，以將它們與原始性能同級進(jìn)行最佳比較。但是，我將在所有三個方面對庫進(jìn)行排名。
在每個組中，將存在參考Vanilla JavaScript條目。使用所有最佳技術(shù)，此實(shí)現(xiàn)都經(jīng)過了最佳化以達(dá)到最佳性能。它將作為所有比較的基準(zhǔn)。
因此，讓我們開始吧。
這是最大的組，由一些最受歡迎的庫組成。還有許多來自Facebook，Google，eBay和Alibaba等公司支持的公司。這些庫要么在性能上較少關(guān)注某個方面，要么在某一方面強(qiáng)調(diào)性能，而在其他方面則受苦。
> Group 4 Performance
這里有很多紅色和橙色，但請記住，這些庫平均僅比我們在此處使用的痛苦手工制作的命令式Vanilla JavaScript示例慢大約2倍。400ms與200ms有何不同？
在原始性能方面，React是該包的領(lǐng)導(dǎo)者?？紤]到架構(gòu)的差異性，盡管它從未間斷令人驚奇，但React，Marko，Angular和Ember的整體距離有多近。仍然是React，這是React Hooks的實(shí)現(xiàn)，在這里是領(lǐng)導(dǎo)者。對于所有指向額外的函數(shù)創(chuàng)建并堅持使用類的人來說，性能參數(shù)不在您身邊。React Hooks是使用React的最高效的方法。
這里的大多數(shù)庫要么簡單的列表排序?qū)е陆粨Q行性能確實(shí)很差，要么創(chuàng)建成本很高。Ember是這種情況的極端案例，因?yàn)樗母滦阅鼙仍摻M中的其他成員要好得多，但在某些最壞的情況下卻是創(chuàng)建過程。
最慢的庫（Knockout，Ractive和Alpine）都是具有類似架構(gòu)的細(xì)粒度反應(yīng)庫。Knockout和Ractive（也由Svelte的作者Rich Harris撰寫）來自2010年初VDOM庫主導(dǎo)之前。我還懷疑Alpine是否期望使用其JavaScript方法來渲染1萬行。在比較之后，我們將看不到另一個純粹的細(xì)粒度反應(yīng)庫。
接下來，我們將主要根據(jù)庫捆綁軟件的大小來比較類別的啟動指標(biāo)。
> Group 4 Startup
此處訂單變化很大。在Alpine性能最差的地方，我們可以看到它具有最小的捆綁包大小和最快的啟動時間。Marko（來自eBay）緊隨其后，其次是Rax（來自阿里巴巴）。所有這三個庫都是為服務(wù)器端渲染而構(gòu)建的，主要是通過更輕松的客戶端交互來實(shí)現(xiàn)的。這就是為什么他們要進(jìn)入第4組才能獲得出色的表現(xiàn)，但卻領(lǐng)先于這里的原因。
表格的后半部分是我們在基準(zhǔn)測試中擁有的最大的捆綁軟件，以Ember結(jié)尾，是任何其他實(shí)現(xiàn)的兩倍以上。我不知道為什么要花費(fèi)超過半兆字節(jié)才能呈現(xiàn)此表。但這確實(shí)會損害啟動性能。
我們要看的最后一類是內(nèi)存消耗。
> Group 4 Memory
內(nèi)存往往會反映出我們已經(jīng)看到的模式，因?yàn)樗鼤π阅墚a(chǎn)生重大影響，而大型庫往往會使用更多模式。Alpine，Marko和React引領(lǐng)潮流。老化的細(xì)粒度反應(yīng)庫使用最多的Ember。Ember是巨大的。僅在頁面上渲染6個按鈕之后，它已經(jīng)使用了比Vanilla在整個套件中要使用的更多的內(nèi)存。
通常，該組在GitHub上代表30萬顆星，可能是NPM下載量的最大部分，但Marko和Alpine在此人群中的平均排名最高。在性能方面，React排名第三，僅次于他們。
這是我們擁有鈦白粉比例框架的組，而我們的舊React庫也已經(jīng)消失了。讓我們繼續(xù)樂觀一些。
在這些框架中，您可以知道已經(jīng)考慮了性能。他們意識到規(guī)模，并且在創(chuàng)建和更新成本之間找到了平衡。我們看到了各種各樣的方法。Yew中的一個Web Assembly框架（用Rust編寫），LitElement中的一個Web組件。
事不宜遲，讓我們看看他們的做法。
> Group 3 Performance
分?jǐn)?shù)已經(jīng)提高了一點(diǎn)，我們看到的差距甚至更大。Preact是該組中性能最高的，僅增加了LitElement。Vue 3和Riot捆綁在一起，這兩個庫都位于中間，它們的歷史都包括反應(yīng)性和VDOM。Mithril是最早將性能放在首位的VDOM庫之一，Yew是唯一的WASM庫尾部。
在性能方面，所有這些庫都是相似的。在這堆中沒有純的反應(yīng)庫。它們都使用自頂向下的呈現(xiàn)方式，無論是VDOM還是簡單的Tag Template Literal diff。與上一組相比，它們的對帳清單更智能（請參閱交換行性能）。但是，大多數(shù)仍然具有某些最慢的選擇行性能。
Yew是例外，但在其他方面則較慢。讓我們看看其余的測試是否有幫助。
> Group 3 Startup
情況有所改觀，但在啟動指標(biāo)方面，Preact仍然處于領(lǐng)先地位。Yew是這一堆中唯一真正的大型庫。WASM庫的確偏大。
再次，我們看到一種結(jié)果配對。Vue是Yew最大的第二名。Preact和Riot非常緊湊。Mithril和LitElement在中間
Preact是React的4kb替代品，絕對是我們迄今為止所看到的最小的庫。但是最小的庫仍在繼續(xù)。盡管如此，這個范圍內(nèi)的任何庫都不應(yīng)該太關(guān)注它們的包大小。
> Group 3 Memory
Yew這次贏了。在所有經(jīng)過測試的框架中，它具有最小的內(nèi)存占用量。WASM庫在這里往往做得很好。其他都非常接近。Mithril和普瑞特Preact是最差的，但不是很多。
這里沒有太多可拉的東西。您可能會認(rèn)為LitElement示例可能比其他非紅豆杉庫更輕巧，因?yàn)樗鼪]有像其余的那樣使用虛擬DOM。但是，正如我們將在以后看到的，VDOM并不意味著更多的內(nèi)存。
Riot和Preact的平均排名最高，其次是LitElement，排名第三。Riot雖然沒有脫穎而出，但在這個小組中沒有弱點(diǎn)，因此取得了勝利。但是，對于這些框架中的任何一個都很難失望。借助WASM和Web組件，它們代表了許多人認(rèn)為Web的未來。
但是我們還沒有完成。下一組代表對網(wǎng)絡(luò)未來的不同想法。輸入編譯器…
這一組是激烈的競爭。我們擁有大多數(shù)被稱為編譯語言的庫。每個都有自己的風(fēng)味。我們擁有不變的結(jié)構(gòu)化Elm，受Ruby啟發(fā)的Imba和"消失的" Svelte。
注意：引起我注意的是，并不是每個人都熟悉Svelte以前的"消失的框架"綽號。它描述了從輸出中基本進(jìn)行自我編譯的能力。我不是在建議Svelte去任何地方。對帶來困惑感到抱歉。
奇怪的是HyperApp，它與其他應(yīng)用程序完全相反。沒有編譯器。沒有模板。只需h函數(shù)和一個最小的Virtual DOM。
猜猜這將如何發(fā)展？
> Group 2 Performance
好吧，最小的虛擬DOM勝出。與最近的言論相反，事實(shí)證明虛擬DOM不僅是性能不佳的秘訣，而且編譯并沒有使其他庫受益。
在已編譯的庫中，我們實(shí)際上看到了3種不同的方法來渲染所有具有大約相同的平均性能。Imba使用DOM協(xié)調(diào)（更接近我們之前看到的LitElement），Elm使用虛擬DOM，最后一個Svelte使用組件反應(yīng)系統(tǒng)。
您應(yīng)該注意，虛擬DOM庫的選擇行最差，因?yàn)檫@是其額外工作所顯示的。但是這些庫還具有更快的初始渲染。如果您仔細(xì)觀察到目前為止的結(jié)果，您應(yīng)該注意到Virtual DOM庫與Reactive庫之間的共享特性。但除此之外，性能還很嚴(yán)格。
因此，讓我們繼續(xù)。我們的編譯器如何調(diào)整啟動時間/捆綁大?。?/p>
> Group 2 Startup
好吧，正如您所看到的那樣，這個小的虛擬DOM庫不僅性能更高，而且比其他的更小。實(shí)際上，HyperApp是我們所有庫中最小的實(shí)現(xiàn)。編譯器無法贏得成功。
它和Svelte都比我們的Vanilla JavaScript參考構(gòu)建小。那怎么可能？以一種更可重用的方式編寫更少的代碼來編寫抽象。Vanilla JS實(shí)現(xiàn)針對性能而非大小進(jìn)行了優(yōu)化。
Elm在這個群體中仍處于規(guī)模競爭中。但是，Imba開始進(jìn)入某些第4組庫的范圍。
好了，留下記憶。編譯器大放異彩的最后機(jī)會。
> Group 2 Memory
內(nèi)存接近，幾乎是平局，但是Svelte最終為編譯器贏得了勝利。對虛擬DOM的一些甜蜜的報復(fù)顯示它比它更小，更快。
老實(shí)說，所有這些庫都具有出色的內(nèi)存配置文件?，F(xiàn)在應(yīng)該很清楚，更少的內(nèi)存和更好的性能之間的關(guān)系。
不相信炒作嗎？
不。更多的事情比表面上看起來復(fù)雜。精心設(shè)計的系統(tǒng)，無論是運(yùn)行時還是編譯時，或者無論采用何種技術(shù)方法，都可以制成高性能的系統(tǒng)。
HyperApp是該組的明顯贏家，其后是Svelte，其次是Elm和Imba。通過這種對性能的專注，您知道這些庫在大多數(shù)情況下都可以提供，并且始終顯示在基準(zhǔn)測試的頂部。
那還剩下什么？
如果我告訴您，聲明性JavaScript庫對它們的性能如此有信心，就不用擔(dān)心原始WASM，Web Worker或您使用的任何技術(shù)，該怎么辦。歡迎來到…
在某一時刻，它可能被稱為"超快"，我相信它曾經(jīng)是這些庫的口號之一。如果您要跟蹤的話，只剩下2個庫了。實(shí)際上，這類庫中有少數(shù)幾家不斷推陳出新。但是在流行的中只有2種。它們平均比原始的手工優(yōu)化Vanilla JS慢20％。
這是要看的東西。在這里，我們有2個庫，如果查看它們的代碼，它們可能被視為同級庫，但使用的方法完全不同。Inferno是世界上性能最高的虛擬DOM庫之一。在最出色的5個執(zhí)行者中，有3個是虛擬DOM庫。選擇行測試的速度下降可以視為證據(jù)。
另一方面，Solid使用細(xì)粒度的反應(yīng)性，例如第4組中最慢的舊庫。重新出現(xiàn)此技術(shù)的位置很奇怪，但正如我們所見，Solid解決了它們的弱點(diǎn)。創(chuàng)建時間與更新時間一樣快。與Vanilla JavaScript的5％差距令人難以置信。
奇怪的是，Inferno和Solid的共同點(diǎn)是JSX模板和React受啟發(fā)的API。對于所有其他具有經(jīng)過優(yōu)化的自定義DSL的庫，也許您不會期望在性能的頂峰找到任何東西。但是，正如HyperApp所示，某些事情對性能的影響比人們想象的要小。
> Group 1 Startup
Solid將HyperApp和Svelte作為第三個庫加入，其庫比Vanilla JS實(shí)現(xiàn)小。但是Inferno也不是懈怠。
似乎性能庫較小時，有時添加更多代碼可以提高性能。更好的列表協(xié)調(diào)算法，更明確的防護(hù)措施，更精細(xì)的更新。
Inferno可能比前幾組中的某些庫更大，但它仍然是一個10kb以下的庫，并且?guī)缀踉谒行阅苌暇蝗珙A(yù)期。
> Group 1 Memory
在那里。除了Yew及其對WASM的使用以外，它們是整個競爭中最低的內(nèi)存消耗框架?？紤]到他們的表現(xiàn)，這并不奇怪。
這種內(nèi)存消耗數(shù)字反映了對對象的非常仔細(xì)的考慮，并創(chuàng)建了閉包。其中很多確實(shí)來自兩個庫都進(jìn)行的定制JSX轉(zhuǎn)換。
內(nèi)存性能的提高對Solid尤為重要，因?yàn)镾olid與大多數(shù)細(xì)粒度的反應(yīng)式庫一樣，都將CPU開銷換成了內(nèi)存消耗。在這種比較中，能夠征服內(nèi)存開銷是Solid如何采用與大多數(shù)最慢的庫類似的技術(shù)并使之成為最快的方法的很大一部分。
天空是極限。
…或者說Vanilla JavaScript是。但是我們這里的聲明式庫性能如此之差，您永遠(yuǎn)都不會知道它們之間的區(qū)別。當(dāng)使用DOM時，我們需要認(rèn)真考慮，許多不同的技術(shù)可以有效地渲染DOM。
我們在這里看到它。Solid在十年前就被認(rèn)為是古老而緩慢的技術(shù)，奪得了性能冠軍，而Inferno再一次證明了虛擬DOM不能高效完成的工作。
在構(gòu)建JavaScript前端時，我們有很多選擇。這只是快速瀏覽框架帶來的性能開銷。當(dāng)涉及到應(yīng)用程序中的實(shí)際性能時，用戶代碼具有更大的影響。
但是，我真正想在這里打動的是，測試您的解決方案并了解性能是很重要的?，F(xiàn)實(shí)總是與營銷不同。虛擬DOM不能保證很慢。不能保證編譯器會產(chǎn)生最小的捆綁包。自定義模板DSL不能保證是最佳的。
最后，我將為您提供完整的表，將所有庫一起顯示。僅僅因?yàn)閹炜煲Y(jié)束了，并不一定意味著它很慢，但是與這些競爭激烈的競爭對手相比，它的得分更差。
單個圖表中的所有框架。
所有結(jié)果都添加到一個列表中（第1名獲得20分，最后1名獲得分）。在平局的情況下，性能優(yōu)先。
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年的比較，這啟發(fā)了這篇文章。
(本文由聞數(shù)起舞翻譯自Ryan Carniato的文章《JavaScript Frameworks, Performance Comparison 2020》，轉(zhuǎn)載請注明出處，原文鏈接：https://medium.com/javascript-in-plain-english/javascript-frameworks-performance-comparison-2020-cd881ac21fce)
例
設(shè)置輪廓的寬度：
p{outline-style:dotted; outline-width:5px;}
屬性定義及使用說明
outline（輪廓）是繪制于元素周圍的一條線，位于邊框邊緣的外圍。
outline-width指定輪廓的寬度。
注意： 請始終在outline-width屬性之前聲明outline-style屬性。元素只有獲得輪廓以后才能改變其輪廓的寬度。
| 默認(rèn)值： | medium |
|---|---|
| 繼承： | no |
| 版本： | CSS2 |
| JavaScript 語法： | object.style.outlineWidth="thin" |
瀏覽器支持
表格中的數(shù)字表示支持該屬性的第一個瀏覽器版本號。
| 屬性 | |||||
|---|---|---|---|---|---|
| outline-width | 1.0 | 8.0 | 1.5 | 1.2 | 7.0 |
提示和注釋
outline是圍繞元素。它是圍繞元素的邊距。但是，它是來自不同的邊框?qū)傩浴?/p>
outline不是元素尺寸的一部分，因此元素的寬度和高度屬性不包含輪廓的寬度。
屬性值
| 值 | 描述 |
|---|---|
| thin | 規(guī)定細(xì)輪廓。 |
| medium | 默認(rèn)。規(guī)定中等的輪廓。 |
| thick | 規(guī)定粗的輪廓。 |
| length | 允許您規(guī)定輪廓粗細(xì)的值。 |
| inherit | 規(guī)定應(yīng)該從父元素繼承輪廓寬度的設(shè)置。 |
如您還有不明白的可以在下面與我留言或是與我探討QQ群308855039，我們一起飛！
程語言正在不斷演化，但預(yù)測 5 年后會如何則很有難度，作者給出了一個答案。
作者 | Timothy Mugayi
譯者 | 明明如月，責(zé)編 | 唐小引
封圖 | CSDN 付費(fèi)下載自 VCG
出品 | CSDN（ID：CSDNnews）
在這篇文章中，我們將看到一個我自己手動排行的編程語言和框架的列表，我相信這些語言和框架在未來 5 到 10 年內(nèi)仍然堅挺。我不希望這個編程語言列表帶有太多偏見。確定這個名單非常困難，因?yàn)槊總€人都會有些許偏見。當(dāng)我草草記下我的想法時，我在思考隨著時間推移編程的范式和創(chuàng)新是否符合演變。2020 年后，更快，更易用，更實(shí)用，更抽象的抽象技術(shù)變得流行。在此精選列表是基于我對技術(shù)的趨勢、工作機(jī)會、使用情況、范例、基于流行性的統(tǒng)計以及未來的技術(shù)創(chuàng)新來預(yù)測的。
在科技界一年就像一生，因此在未來 5 年內(nèi)可能會發(fā)生很多變化，但我相信這份精心策劃的清單仍然很重要。如果您剛開始學(xué)習(xí)如何編程，不知道該選擇哪種語言或框架，那么這份精選清單則可以幫到你。
回顧
當(dāng)我們踏入 2020 年，回顧過去 5 年，很多事情都發(fā)生了改變。如區(qū)塊鏈、深度學(xué)習(xí)、量子計算等新技術(shù)開始出現(xiàn)。對于那些剛剛開始學(xué)習(xí)編程甚至是經(jīng)驗(yàn)豐富的開發(fā)人員來說，為了在這個不斷變化的領(lǐng)域中保持與時俱進(jìn)，思考自己在目前的發(fā)展?fàn)顩r大有裨益。現(xiàn)在就是學(xué)習(xí)新技術(shù)的最好時機(jī)。
為什么確保你選擇和學(xué)習(xí)正確的語言或框架很重要？
學(xué)習(xí)一門新的語言和框架對你來說是一種投資，你花的金錢和時間有去無回。 技術(shù)總是在不斷變化，隨著年齡的增長，保持與時俱進(jìn)的需求變得越來越重要。選擇正確的語言和框架可能會改變你的一生，可能會徹底改變你做工作的方式和發(fā)展軌跡。因此你肯定想選擇一個近幾年不會過時的編程語言。
Rust
Rust 是一種系統(tǒng)編程語言，旨在取代 C 和 C++ 開發(fā)。Rust 提供了和 C 和 C++ 匹敵的性能，但是使用起來更加友好。對于那些已經(jīng)在 c / C++ 中編寫了很長時間的程序的人來說，他們非常喜歡聽到這樣的話。
已經(jīng)有相當(dāng)多的新開發(fā)者涉足這個領(lǐng)域。Rust 擁有不斷增長的用戶群。有數(shù)百家公司使用 Rust 進(jìn)行開發(fā)，比如 Dropbox、 Yelp 和 Cloudflare。亞馬遜最近宣布的虛擬化技術(shù) Firecracker 這種產(chǎn)品也使用的是 Rust 的。在 StackOverflow 的 2016 年開發(fā)者調(diào)查中，Rust 也被評為“最受歡迎”的技術(shù) （這意味著更多的用戶會堅持使用 Rust）。
盡管與那些已經(jīng)問世幾十年的其他編程語言相比，它還是相對比較年輕，但它擁有大量可用的庫，可以用來加速開發(fā)。你可以在 crates.io 或 GitHub 上找到你需要大多數(shù)的東西。
Rust 的主要特征
Rust 的主要特征是運(yùn)行速度快和內(nèi)存利用率高。它沒有運(yùn)行時或垃圾收集器，它適合用在對性能要求高的關(guān)鍵的服務(wù)，它可以在嵌入式設(shè)備上運(yùn)行，并且很容易與其他語言集成。在接下來的 5 年和 10 年里，隨著我們遇到硬件編程語言的限制，這些語言的速度更快，占用的內(nèi)存更少，提高了速度和響應(yīng)能力，使我們能夠更省力的編寫代碼，這類語言將變得更加重要。
可靠性：Rust 豐富的類型系統(tǒng)和所有權(quán)模型保證了內(nèi)存和線程的安全，并能夠在編譯時消除許多錯誤。
生產(chǎn)力：Rust 有很好的文檔，提供了一個非常友好的編譯器，錯誤信息提示非常友好。C，C++ 代碼的編譯器提示消息則是出了名的難以理解。Rust 的編譯器則更好。如果你想學(xué)習(xí)系統(tǒng)編程，使用“ rustc”編譯器做可以讓你不用擔(dān)心內(nèi)存安全而能夠?qū)Ｗ⑵渌氖虑椤?/p>
正如一位著名的程序員曾經(jīng)說過：Pascal 就像穿著緊身衣，C 就像在玩刀，而 C++ 就像在玩弄燃燒的電鋸。在這個比喻中，Rust 就像是穿著保護(hù)裝備懸掛在繩子上做跑酷運(yùn)動。是的，這看起來有點(diǎn)可笑，但是你可以用它做各種很酷的動作而不傷害自己。
Python
在過去的幾年里，Python 的流行度一直在穩(wěn)步上升，尤其是在過去的 10 年里，最終邁進(jìn)了 TIOBE 指數(shù)的前 5 名。
Python 非常實(shí)用。對于初學(xué)者來說，它是一個腳本語言，這意味著入門非?？?，不像 java 還需要編譯。它的本質(zhì)是面向?qū)ο蟮恼Z言。在大學(xué)的許多學(xué)術(shù)課程中，Python 已經(jīng)取代 Java 成為默認(rèn)的首選編程語言。對于初學(xué)者來說，安裝 Python 解釋器并運(yùn)行非常容易。
$ print (‘hello world this is my. First program’)如上述代碼所示，你的第一個程序就這樣用 Python 寫完了。
Python 正在為未來鋪平道路。它在未來 5 年乃至更長的時間段內(nèi)都將具有較大影響力。Python 已經(jīng)讓機(jī)器學(xué)習(xí)、深度學(xué)習(xí)、人工智能、大數(shù)據(jù)等所有流行的數(shù)據(jù)科學(xué)流行語等新的技術(shù)范式成為可能?；ヂ?lián)網(wǎng)上有大量成熟的庫，如 TensorFlow、 Scikit-Learn、 Dask for distributed Data Science 大規(guī)?？蓴U(kuò)展計算， Python 也可以用于量子計算。雖然我們離量子計算還相對較遠(yuǎn)，但是 Python 是一個可以確保你作為一個量子程序員的地位的語言。
Python 在企業(yè)和初創(chuàng)企業(yè)中都很受歡迎。在過去 5 年中已經(jīng)取得了巨大的進(jìn)展。現(xiàn)在一些使用廣泛的平臺，比如 Reddit和許多 Google 庫都是建立在 python 之上的。
我個人使用 Python 編寫腳本并快速自動化許多任務(wù)。它一直是一種讓自由職業(yè)者快速完成項(xiàng)目的不可多得的語言。
Python 提供了可以訪問網(wǎng)絡(luò)框架，比如 Django 框架，它是構(gòu)建前端和后端網(wǎng)絡(luò)應(yīng)用的最好的 Python 框架之一。堅持 DRY 原則快速構(gòu)建應(yīng)用程序的哲學(xué)，需要很少的代碼量和需要很少的編程經(jīng)驗(yàn)。
Ruby
Ruby 是另一個功能強(qiáng)大的高級語言，它可以讓你輕松地構(gòu)建應(yīng)用程序。作為面向?qū)ο蟪绦蛟O(shè)計語言，對于那些有 Python 開發(fā)經(jīng)驗(yàn)的人來說，Ruby 語法看起來與 Python 非常相似。該語言還配備了構(gòu)建復(fù)雜應(yīng)用程序所需的所有工具。
許多硅谷的初創(chuàng)公司都是建立在 Ruby 之上的，比如 Airbnb、 Twitch、 GitHub 和 Twitter。Ruby on Rails 是一個運(yùn)行 Ruby 的全堆棧 Web 應(yīng)用程序框架，這讓 Ruby 更加流行。
Ruby 的一些關(guān)鍵特性：
提供了一個健壯的高質(zhì)量庫。
語法簡單，有助于快速開發(fā)原型。
學(xué)習(xí)門檻低，新程序員很容易上手。
是一種面向?qū)ο蟪绦蛟O(shè)計語言，所以你可以擁有一切面向?qū)ο笳Z言的優(yōu)勢。
由于 Rust 的內(nèi)存占用很小，可用于構(gòu)建分布式在線服務(wù)或網(wǎng)絡(luò)服務(wù)。
Golang
Go（Golang）是 Google 開發(fā)的一種相對較新的編程語言。它最近越來越受歡迎。 提供了極好的多線程支持，因此，許多嚴(yán)重依賴分布式系統(tǒng)的公司都正在使用它。它是為解決谷歌面臨的一些棘手問題而設(shè)計的。谷歌還將 Go 作為新項(xiàng)目的主要語言，并用 Go 取代其他語言。因?yàn)楣雀枧c我們的日常生活息息相關(guān)，所以我們不可能忽視它，認(rèn)為它在可預(yù)見的未來將繼續(xù)保持活躍。
我必須承認(rèn)，它是一門非常優(yōu)雅的編程語言，語法很簡潔。它在動態(tài)類型語言、解釋性語言的易用性和類型安全、內(nèi)存安全之間取得了平衡。
主要功能：
由于有內(nèi)在并發(fā)支持，它可以有效提高 CPU 利用率。擅長云系統(tǒng)開發(fā)，分布式系統(tǒng)，微服務(wù)。
輕量級、執(zhí)行速度快和開發(fā)效率高。
內(nèi)存占用和二進(jìn)制文件較小。
自動垃圾收集。
無異常，它自己處理錯誤， 等。是的，你沒看錯。這對你來說意味著什么？您必須準(zhǔn)確地知道如何自己處理這些錯誤，而不是拋出一堆 try-catch 異常。仔細(xì)想想是不是這樣？
有趣的事實(shí)：
全球 Go 語言開發(fā)人員平均年薪: 109,483 美元。在美國，這種頂級編程語言的平均年薪為13.6 萬美元。
在 2019 年 Stack Overflow 開發(fā)者調(diào)查中，Go 是全球排名第三的高薪語言。
GitHub 上第四活躍的編程語言。
GraphQL
與今天相比，以前的 Web API 設(shè)計相對簡單，有用于從服務(wù)器檢索數(shù)據(jù)的 REST 表示狀態(tài)轉(zhuǎn)移標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)是基于URL來訪問數(shù)據(jù)的。
然而，需求增長超過了標(biāo)準(zhǔn)。數(shù)據(jù)不再是之前靜態(tài)的樣子了，它更加動態(tài)，因此 GraphQL 應(yīng)運(yùn)而生。GraphQL 是 REST 架構(gòu)的替代方案，旨在克服REST的缺點(diǎn)。與 REST 不同，GraphQL 允許脫離固定數(shù)據(jù)結(jié)構(gòu)方式來請求客戶機(jī)需要的特定數(shù)據(jù)。在后端，GraphQL 向 API 指定如何向客戶端顯示數(shù)據(jù)。GraphQL 通過 API 重新定義了開發(fā)人員的工作，這些 API 為市場提供了更多的靈活性和速度；它改善了客戶機(jī)與服務(wù)器之間的交互，使前者能夠進(jìn)行精確的數(shù)據(jù)請求，準(zhǔn)確的獲得他們所需要的東西。
最初由 Facebook 在 2012 年創(chuàng)建，GraphQL 內(nèi)部用在他們的移動應(yīng)用程序，通過其特定的數(shù)據(jù)獲取功能來減少網(wǎng)絡(luò)使用。從那時起，GraphQL 規(guī)范開源了?，F(xiàn)在主要的編程語言如 Python，Java，c # ，Node.js 等都支持它。
由于其生態(tài)系統(tǒng)的快速擴(kuò)張，這使得它成為在可預(yù)見的未來繼續(xù)堅挺的技術(shù)之一。它有豐富的擴(kuò)展庫和功能強(qiáng)大的工具，如 Apollo、 GraphiQL 和 GraphQL Explorer。
GraphQL 的一些關(guān)鍵特性：
查詢速度更快，選擇查詢的字段減少請求。
非常適合復(fù)雜系統(tǒng)和微服務(wù)。通過其 API 集成多個系統(tǒng)。
GraphQL 可以將來自多個地方的數(shù)據(jù)聚合成單個 API。
不存在過多或過少抓取的問題。眾所周知，REST 響應(yīng)要么包含過多的數(shù)據(jù)，要么包含的數(shù)據(jù)不夠。
驗(yàn)證和開箱即用的類型檢查。
自動生成 API 文檔可取代 Swagger，并且在 GitHub 問題中可以找到使用規(guī)范。
無版本的 API 演進(jìn)，這是 REST 的一個常見問題隨著 API 演進(jìn)，你不得不創(chuàng)建一個新的 API 或者在 URL 前面加上版本，并且有無可挑剔的文檔。通過使用 GraphQL，你可以得到一個單一的、不斷發(fā)展的版本，這使你的應(yīng)用程序可以不斷地訪問新特性，并且鼓勵編寫更簡潔、更易維護(hù)的服務(wù)器代碼。
GraphQL 并不是試圖取代 REST，它們是解決不同類型問題的兩個不同的東西。隨著我們邁向大數(shù)據(jù)，投入一些時間學(xué)習(xí) Graphql 就非常有必要。
Angular
Angular 由 Google 開發(fā)的，一種用于軟件開發(fā)的成熟的 TypeScript 框架。它是構(gòu)建 web 和移動應(yīng)用程序的主要開源框架之一。Angular 是一個完全基于 AngularJS 改寫的。從 AngularJS 開始，它在剛開始的時候就具有一定的影響力，現(xiàn)在 Angular 經(jīng)過多年的發(fā)展，它已經(jīng)發(fā)展成為一個全面的開發(fā)框架，其中包括了構(gòu)建網(wǎng)絡(luò)和移動應(yīng)用所需的所有工具和組件。這個框架的美妙之處在于它遵循著一個清晰的路線圖，每六個月發(fā)布一個新的 Angular 主版本，如果你想長期使用 Angular 的話，這點(diǎn)很重要。
Angular 的主要特征：
下面只討論 Angular 9 中提到的特性，這些特性可能會解決性能問題。
Google 為這個框架提供了長期的支持，并不斷地改進(jìn)它。定期改進(jìn)非常受追捧，這表明這個框架有一個充滿活力。因此，鑒于谷歌正在支持它并對其進(jìn)行投資，表明該框架在可預(yù)見的未來仍將具有相關(guān)性。
Angular 9 的另一個關(guān)鍵特性是通過 Ivy Compiler 減少了大包文件，從而占用了很小的空間 —— 試圖通過減少 JavaScript 包的大小，Ivy 加快應(yīng)用程序啟動。
為需要支持多種語言的應(yīng)用程序提供更好的國際化支持。
JavaScript
我斗膽說一句：JavaScript 是一個不可替代的語言，毫無疑問它將在未來的幾年里繼續(xù)存在。因此，投資學(xué)習(xí)這門語言非常劃算。它不僅僅是一個客戶端的開發(fā)腳本語言，通過像 Node JS，Angular 和 React 這樣的框架和庫，你還可以在服務(wù)器端使用 JavaScript 來開發(fā)用戶界面。
JavaScript 是所有大型科技公司的核心，比如 Netflix，F(xiàn)acebook，Google 等等。因此，JavaScript 作為一種語言和其他編程語言一樣都具有合法地位。2020 年是開始投資的一年。把你的空閑時間投入到學(xué)習(xí) JavaScript 上來吧。
現(xiàn)在想一想，幾乎所有的網(wǎng)站都在某種程度上使用了 JavaScript。
榮譽(yù)獎
Webassembly ( 縮寫為 Wasm) 應(yīng)該獲取榮譽(yù)獎，但不能成為前 7 名，因?yàn)樗炔皇强蚣芤膊皇蔷幊陶Z言。
Wasm 被設(shè)計為編程語言的編譯目標(biāo)和二進(jìn)制格式，其目標(biāo)是為 web 應(yīng)用程序提供接近本機(jī)的性能。這意味著什么？把它想象成一個公共的中央平臺，開發(fā)人員可以將各種編程語言編譯成 web 匯編，然后在這個平臺上運(yùn)行它們。另一個類比是它是所有編程語言的 Java 虛擬機(jī)。
從本質(zhì)上講，每當(dāng)您在 Internet上通過 Web 瀏覽器運(yùn)行應(yīng)用程序時，Wasm 都將目標(biāo)定為 Web 應(yīng)用程序的近乎本機(jī)的性能，在接下來的 5 年中，大多數(shù)情況都需要用到 Wasm。想想那些需要完美表現(xiàn)的網(wǎng)絡(luò)游戲吧。通過點(diǎn)擊一個按鈕，你就可以從服務(wù)器下載應(yīng)用程序代碼，并將其加載到運(yùn)行 Wasm 的瀏覽器虛擬機(jī)中。Wasm 得到了如 Mozilla，微軟，谷歌和蘋果等大企業(yè)的支持。
這種 Web 匯編的廣泛應(yīng)用鼓勵去中心化計算，例如 Ethereum 正在著手開發(fā) ether 2.0，在本文撰寫之時，Ethereum 將利用其新提出的重新設(shè)計智能合同執(zhí)行層的建議，使用 WebAssembly 的確定性子集。在這個巨大的數(shù)字化空間里，學(xué)習(xí)模型正逐漸成為軟件開發(fā)人員構(gòu)建、人與應(yīng)用交互的技術(shù)支柱。
Web 匯編可以讓 JavaScript 做它擅長的事情，并將它不能做的部分委托給其他語言?？梢园阉胂蟪上乱淮?Web Ajax。Ajax 使客戶端應(yīng)用程序成為可能。Web 匯編允許您超越僅僅使用 JavaScript 進(jìn)行節(jié)點(diǎn)或 JavaScript 可能不擅長的復(fù)雜的低級計算。因此，web 匯編的未來看起來是前途一片光明。
總結(jié)
如果你仔細(xì)想想，所有的編程語言和框架都有能力構(gòu)建復(fù)雜而強(qiáng)大的功能， 都可以構(gòu)建解決現(xiàn)實(shí)世界中緊迫問題的應(yīng)用程序。沒有放之四海而皆準(zhǔn)法則，因?yàn)槊糠N語言和框架都有其優(yōu)勢和不足，以及有意義或無意義的地方。對語言的需求是由用例、市場需求或使用該專業(yè)知識的資源庫驅(qū)動的。
永遠(yuǎn)記住，任何編程語言或框架的目標(biāo)都是完成任務(wù)，要選擇最適合你的技術(shù)。
真正的敏捷適應(yīng)性和迭代學(xué)習(xí)才能真正讓你在未來幾十年保持與時俱進(jìn)。就我個人而言，作為一個通曉多種語言的開發(fā)者，這為我敞開了大門
如果你喜歡這篇文章，那么請與你的朋友和同事分享，如果你認(rèn)為這些語言在未來 5 年內(nèi)將不再適用，那么請評論，我也很樂意聽到你的聲音。
英文：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。技術(shù)傳播者，講師，多語言開發(fā)者，熱愛技術(shù)創(chuàng)新
譯者：明明如月，知名互聯(lián)網(wǎng)公司 Java 高級開發(fā)工程師，CSDN 博客專家。
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
