2008年9月2日，Chrome瀏覽器總算發(fā)布了，長(zhǎng)達(dá)2年的隱秘開(kāi)發(fā)沒(méi)有白搭，出道即巔峰：

• 選用多進(jìn)程架構(gòu)，避免某個(gè)Tab崩潰導(dǎo)致整個(gè)瀏覽器崩潰
• 開(kāi)發(fā)了全新的V8引擎，將JavaScript的履行速度提高了1個(gè)數(shù)量級(jí)
• 規(guī)劃了十分簡(jiǎn)潔的用戶界面，十分重視用戶體驗(yàn)，比方可拖拽的Tab、支撐搜索的地址欄、默許隱藏書(shū)簽欄、隱身模式等

當(dāng)年主管Chrome項(xiàng)目的Sundar Pichai，在發(fā)布Chrome時(shí)是這樣說(shuō)的：

We hope to collaborate with the entire community to help drive the web forward.

這種吹牛的話一般沒(méi)人信任，不過(guò)Chrome真的做到了，而Pichai也由于領(lǐng)導(dǎo)Chrome項(xiàng)目所展現(xiàn)的出色的遠(yuǎn)見(jiàn)和才能，后來(lái)出任谷歌CEO，走向人生巔峰。

Chrome不只市占率第一，而且直接以及直接推進(jìn)了一系列Web技能的前進(jìn)：V8、ECMASCript 2015、HTTP/2、HTTP/3、QUIC、HTTPS、WebAssembly、WebGPU。。。

并不夸大地說(shuō)，了解Chrome的開(kāi)展能夠協(xié)助咱們了解整個(gè)前端職業(yè)的開(kāi)展趨勢(shì)，由于瀏覽器的才能便是前端職業(yè)的鴻溝地點(diǎn)，而主要推進(jìn)瀏覽器前進(jìn)的便是Chrome。

那么，2021年，Chrome有哪些值得重視的變化呢？

Chrome 2021

2021年，Chrome一共發(fā)布了9個(gè)版別，從Chrome 88到Chrome96：

我是從Chrome 89開(kāi)端寫(xiě)《了不得的Chrome瀏覽器》博客的，所以錯(cuò)過(guò)了Chrome 88。別的，Chrome 92實(shí)在沒(méi)有發(fā)現(xiàn)什么特別大亮點(diǎn)，大概是其他版別太卷了。。。全體來(lái)看，Chrome在2021年的表現(xiàn)相當(dāng)讓人驚艷。

2021年，F(xiàn)lash停服了。Chrome也徹底告別了Flash，結(jié)束了一代人關(guān)于Flash游戲、動(dòng)畫(huà)、視頻的記憶，比方開(kāi)心農(nóng)場(chǎng)、QQ空間。據(jù)傳，此事還導(dǎo)致某地鐵路系統(tǒng)呈現(xiàn)故障，相當(dāng)為難。Flash彌補(bǔ)了前期Web才能的缺乏，可是自身存在嚴(yán)峻的安全危險(xiǎn)，跟著Web技能的敏捷前進(jìn)，F(xiàn)lash早就沒(méi)那么重要了。Adobe在2017年就給Flash宣判了死刑，這一天仍是來(lái)了。

圖片來(lái)歷：Goodbye Flash, goodbye FarmVille

2021年，WebAssembly更強(qiáng)了。Chrome相繼支撐WebAssembly  SIMD、WebAssemblyException Handling以及WebAssemblyReference  Types，這些都是十分重要的WebAssembly特性。大名鼎鼎的Photoshop總算遷移到了Web，是通過(guò)將C++編譯為WebAssembly來(lái)完成的，其間WebAssembly  Exception Handling與WebAssembly SIMD發(fā)揮了重要的作用。

圖片來(lái)歷：Photoshop's journey to the web

2021年，QUIC協(xié)議發(fā)布了。這將有助于提高網(wǎng)絡(luò)通信的功能、安全性以及靈活性。這是核算機(jī)網(wǎng)絡(luò)開(kāi)展的革命性里程碑，未來(lái)TCP將有可能會(huì)逐漸退出歷史舞臺(tái)（這個(gè)進(jìn)程會(huì)應(yīng)該比較長(zhǎng)，乃至像IPv6相一起間拖很久）。作為發(fā)明者，Chrome是最早部署QUIC協(xié)議的瀏覽器，再一次用技能改動(dòng)世界。

2021年，WebGPU要來(lái)了。Chrome   94開(kāi)端了WebGPU試用，估計(jì)將于2022年上半年正式發(fā)布。WebGPU是WebGL的繼承者，它們的方針相似，不過(guò)WebGPU供給了愈加底層的GPU才能。因而，WebGPU的圖像渲染才能更強(qiáng)，功能更好，更易用，也愈加適用于數(shù)據(jù)并行核算以及機(jī)器學(xué)習(xí)。

Flash 停服了

亨利福特從前說(shuō)過(guò)：

If I had asked people what they wanted, they would have said faster horses.

在馬車時(shí)代，人們只會(huì)希望馬車能跑得更快一點(diǎn)，而不會(huì)想到馬車會(huì)被轎車代替。

相似的，盡管Flash也曾輝煌過(guò)很長(zhǎng)一段時(shí)刻，可是依然仍是被時(shí)代扔掉了，2021年是它的結(jié)尾。

Flash在我國(guó)的高光時(shí)刻大概是全民偷菜？這個(gè)簡(jiǎn)單的游戲從前讓企鵝賺得盆滿缽滿。

圖片來(lái)歷：2021年1月1日，是Flash的葬禮日

我沒(méi)玩過(guò)偷菜，可是我也曾用過(guò)QQ空間（暴雷年紀(jì)了）。那些殺馬特的QQ空間，當(dāng)年靠的便是Flash，把頁(yè)面整的花里胡哨的。

圖片來(lái)歷：2021年1月1日，是Flash的葬禮日

對(duì)Flash怨念最深的莫過(guò)于喬布斯了，iPhone從一開(kāi)端就不支撐Flash。喬幫主還親身寫(xiě)了一篇文章Thoughts  on  Flash抨擊Flash不安全、BUG多、關(guān)閉、費(fèi)電、對(duì)觸屏不友好，有理有據(jù)有節(jié)。從這篇文章也能看出來(lái)，喬幫主絕非不懂技能，反而技能視野還不錯(cuò)，對(duì)Flash存在的技能問(wèn)題分析得十分到位，切中關(guān)鍵。與喬布斯、蓋茨以及馬斯克這些美國(guó)企業(yè)家相比，我國(guó)的互聯(lián)網(wǎng)大佬其實(shí)大多都是技能出身，可是都不怎樣聊技能，這大概是由于我國(guó)互聯(lián)網(wǎng)過(guò)去的開(kāi)展主要靠的是運(yùn)用層以及商業(yè)模式的立異，而不是技能層面的立異。

那么問(wèn)題來(lái)了，是喬幫主封殺Flash導(dǎo)致Flash式微，仍是Flash自己缺點(diǎn)太多導(dǎo)致喬幫主不得不封殺Flash呢？我想更多是后者，人不自救，孰能救之。

當(dāng)然，蘋(píng)果并非沒(méi)有私心，它更希望將開(kāi)發(fā)者操控在蘋(píng)果的生態(tài)系統(tǒng)中。蘋(píng)果扯著HTML5的大旗封殺Flash，不過(guò)后來(lái)對(duì)Web技能遠(yuǎn)不如谷歌來(lái)的熱心。

前期，F(xiàn)lash被用于播放視頻、制造動(dòng)畫(huà)、展現(xiàn)廣告等。后來(lái)，Web技能的不斷前進(jìn)，比方video標(biāo)簽、Canvas、WebGL、SVG，逐漸代替了Flash的作用，F(xiàn)lash也就失去了商場(chǎng)。

懷舊的人們大概會(huì)有些傷感，可是事實(shí)上，沒(méi)有Flash之后的Web會(huì)愈加安全、愈加流通，這就愈加扎心了。。。

WebAssembly 更強(qiáng)了

2021年無(wú)疑是WebAssembly的大年。

在技能方面，Chrome相繼支撐了WebAssembly SIMD、WebAssemblyException Handling以及WebAssemblyReference Types這3個(gè)重磅特性。

在運(yùn)用方面，宇宙級(jí)圖片處理東西Photoshop通過(guò)運(yùn)用WebAssembly遷移到了Web，別的依據(jù)WebAssembly完成的規(guī)劃東西Figma估值到達(dá)驚人的100億美元，兩者都證明了WebAssembly的巨大價(jià)值。

對(duì)WebAssembly感興趣的同學(xué)，歡迎閱覽我的博客《十年磨一劍，WebAssembly是怎樣誕生的？》，了解WebAssembly的開(kāi)展歷史。

WebAssembly SIMD

Chrome 91默許開(kāi)啟了WebAssembly SIMD。

SIMD是Single Instruction Multiple Data的縮寫(xiě)，中文術(shù)語(yǔ)為“單指令多數(shù)據(jù)流”，顧名思義，便是能夠運(yùn)用單條指令一起處理多個(gè)數(shù)據(jù)。

SIMD是一種特殊的CPU指令，它能夠完成數(shù)據(jù)層面的并行處理。如下圖，當(dāng)咱們需求對(duì)兩個(gè)長(zhǎng)度為4的數(shù)組做加法時(shí)，運(yùn)用一般的指令，則需求履行4次一般加法指令；如果運(yùn)用SIMD指令的話，則只需求履行1次向量加法即可：

SIMD常用于視頻、音頻、圖像、加密、動(dòng)畫(huà)、游戲、AI等需求處理很多數(shù)據(jù)的運(yùn)用場(chǎng)景，能夠極大地提高向量類型的數(shù)據(jù)處理功能。主流的CPU都有SIMD指令，比方x86的SSE、ARM的Neon。

WebAssembly SIMD為WebAssembly新增了一個(gè)變量類型v128及其一系列v128的運(yùn)算符，這些運(yùn)算符便是SIMD指令。別的，由名字可知v128類型的長(zhǎng)度是固定的，為128比特。

SIMD的指令十分多，而且不同CPU的SIMD是不相同的，WebAssembly  SIMD只選取了各個(gè)CPU都支撐的部分最常用的SIMD指令。因而，能夠?qū)ebAssembly  SIMD了解為各個(gè)CPU的SIMD指令的子集，一起將各個(gè)CPU的SIMD指令進(jìn)行了一層籠統(tǒng)和統(tǒng)一，開(kāi)發(fā)者只需求學(xué)習(xí)WebAssembly  SIMD，而不需求了解底層CPU的SIMD。

現(xiàn)在，Emscripten僅支撐將WebAssembly SIMD指令編譯為x86 SSE/AVX指令以及ARM Neon指令。

在核算機(jī)范疇，形似沒(méi)有什么問(wèn)題是用分層處理不了的，如果有的話，能夠再分一層。

現(xiàn)在，WebAssembly  SIMD這個(gè)提案現(xiàn)已進(jìn)入WebAssembly提案流程的Phase 4（Standardize the  Feature），尚未徹底完成，不過(guò)離最終完成也只要1個(gè)Phase了，能夠了解為基本完成了。V8（Chrome、Node.js）、Firefox以及Emscripten都現(xiàn)已完成了WebAssembly  SIMD。

Google Meet借助WebAssembly完成了視頻的實(shí)時(shí)背景虛化以及背景代替，這樣能夠讓參加線上會(huì)議的人把注意力集中在人而不是他地點(diǎn)的環(huán)境。對(duì)視頻數(shù)據(jù)進(jìn)行實(shí)時(shí)處理的話，對(duì)核算才能的要求十分高，運(yùn)用WebAssembly SIMD使其功能提高了至少2倍。

2021年，Photoshop總算遷移到了Web，是通過(guò)將C++編譯為WebAssembly來(lái)完成的，其間，WebAssembly SIMD發(fā)揮了重要的作用，將功能均勻提高了3到4倍，有些場(chǎng)景下乃至到達(dá)驚人的80到120倍。

WebAssembly Exception Handling

WebAssembly Exception Handling于Chrome 90開(kāi)端試用，Chrome 95正式發(fā)布，為WebAssemly添加了反常處理語(yǔ)法，具體指令如下表所示：

WebAssembly/exception-handling提案由Google的開(kāi)發(fā)者負(fù)責(zé)，當(dāng)前處于WebAssembly提案流程的Phase 3，而且得到了Firefox、Safari以及Edge的支撐，因而估計(jì)將會(huì)成為正式規(guī)范。

WebAssembly自誕生以來(lái)就沒(méi)有反常處理語(yǔ)法，這是個(gè)挺大的問(wèn)題。在瀏覽器環(huán)境下，WebAssemly的反常是通過(guò)JavaScript的try/catch來(lái)"模仿"的，這繼承了Asm.js的處理方式。

依據(jù)JavaScript的WebAssembly反常處理方式如下圖所示：

• 左側(cè)為WebAssembly偽代碼，右側(cè)為JavaScript膠水代碼；
• 依據(jù)右側(cè)的JavaScript函數(shù)invoke_vi可知，WebAssembly模塊的調(diào)用放在了JavaScript的try/catch句子中；
• 依據(jù)右側(cè)的JavaScript函數(shù)___cxa_throw可知，WebAssmebly的throw句子實(shí)際上是運(yùn)用JavaScript的throw句子來(lái)模仿；
• WebAssembly和JavaScript代碼互相來(lái)回調(diào)用，這樣生成的代碼量添加了很多，一起降低了履行功能；

依據(jù)開(kāi)端的測(cè)驗(yàn)成果，依據(jù)WebAssembly原生的反常處理方式，代碼量降低了30%左右，一起功能提高了30%左右，這個(gè)成果能夠說(shuō)十分理想了，用更少的代碼完成了更好的功能，用更少的代碼完成了更好的功能。從原理上來(lái)講，這個(gè)成果并不讓人意外。不過(guò)，由于現(xiàn)在測(cè)驗(yàn)數(shù)據(jù)還十分少，因而WebAssembly Exception Handling的實(shí)在作用還有待于進(jìn)一步驗(yàn)證。

Photoshop移到了Web的進(jìn)程中，WebAssembly Exception Handling也十分重要，由于C++中的反常處理代碼挺常見(jiàn)的。Photoshop也參與了WebAssembly Exception Handling規(guī)范的擬定進(jìn)程。

WebAssembly Reference Types

Chrome 96正式發(fā)布了WebAssembly Reference Types，Reference Types即引用類型，用externref關(guān)鍵詞表示。

之前，WebAssembly僅支撐32位及64位的整數(shù)和浮點(diǎn)數(shù)，這樣使得處理復(fù)雜數(shù)據(jù)比方String和Object時(shí)十分費(fèi)事。

以字符串為例，如果咱們需求從JavaScript傳入一個(gè)字符串給WebAssembly函數(shù)運(yùn)用，則需求這樣處理：

• 將字符串轉(zhuǎn)換為整數(shù)（運(yùn)用TextEncoder即可）
• 將整數(shù)寫(xiě)入WebAssembly的內(nèi)存空間（WebAssembly的內(nèi)存空間是一個(gè)線性的數(shù)組空間）
• 將整數(shù)數(shù)組的地址傳給WebAssembly函數(shù)

盡管這些步驟由編譯東西比方wasm-bindgen來(lái)處理，咱們不需求操心，可是這樣做會(huì)生成很多膠水代碼，損耗了編譯和履行功能。

支撐Reference Types之后，WebAssembly也能夠愉快地處理整數(shù)及浮點(diǎn)數(shù)之外的數(shù)據(jù)類型了。

WebAssembly/reference-types提案現(xiàn)已被納入WebAssembly規(guī)范，F(xiàn)irefox和Safari之前現(xiàn)已支撐了。WebAssembly  Reference Types使得其他WebAssembly提案成為可能，例如GC（Garbage collection）、Interface  Types以及type Imports等。

WebAssembly/reference-types提案的負(fù)責(zé)人是Andreas   Rossberg，他是Google前職工，參與了WebAssembly開(kāi)端的規(guī)劃，現(xiàn)在是WebAssembly中心規(guī)范的編輯。除了Reference  Types，Andreas Rossberg還負(fù)責(zé)了WebAssembly的很多其他十分重要的提案，比方GC（Garbage  collection）、Type Imports、Tail call等。

QUIC 協(xié)議發(fā)布了

2021年，QUIC協(xié)議成為IETF的RFC，它是新一代傳輸層網(wǎng)絡(luò)協(xié)議，是HTTP/3協(xié)議的根底：

由上圖可知，QUIC協(xié)議相當(dāng)于一起承擔(dān)了TCP、TLS以及HTTP/2的責(zé)任：

• 供給相似于TCP的牢靠通信，處理丟包、擁塞等網(wǎng)絡(luò)反常情況；
• 依據(jù)TLS/1.3進(jìn)行加密，保證通信的安全性，一起避免中心節(jié)點(diǎn)攪擾導(dǎo)致協(xié)議死板；
• 供給相似于HTTP/2的多路復(fù)用才能，在網(wǎng)絡(luò)傳輸層添加了流的概念，處理了TCP協(xié)議的頭部阻塞問(wèn)題；

TCP是一個(gè)巨大的網(wǎng)絡(luò)協(xié)議，可是它有很多問(wèn)題，其最大的問(wèn)題是TCP協(xié)議現(xiàn)已死板了，基本沒(méi)法改了。QUIC最大亮點(diǎn)不在于處理了TCP頭部阻塞的問(wèn)題或者供給1-RTT乃至0-RTT的銜接時(shí)長(zhǎng)，而是一系列保障可部署性、更快地迭代、避免協(xié)議死板的規(guī)劃，比方依據(jù)UDP、加密、脫離操作系統(tǒng)內(nèi)核等。

QUIC協(xié)議的規(guī)劃思維有點(diǎn)像React 17，在架構(gòu)規(guī)劃上簡(jiǎn)化未來(lái)的更新，保障長(zhǎng)時(shí)刻開(kāi)展。

對(duì)QUIC協(xié)議興趣的同學(xué)，推薦看看QUIC 101視頻以及The QUIC Transport Protocol: Design and Internet-Scale Deployment論文，講得挺好的，我就贅述了。

總歸，QUIC是一個(gè)斗膽、激進(jìn)、奇妙的網(wǎng)絡(luò)協(xié)議。正如一切其他改動(dòng)世界的技能（比方WWW）相同，QUIC也是站在偉人的膀子上，吸取了數(shù)十年TCP協(xié)議的各種經(jīng)驗(yàn)和教訓(xùn)。

QUIC協(xié)議在本年5月成為IETF的RFC，這是核算機(jī)網(wǎng)絡(luò)開(kāi)展的革命性里程碑，未來(lái)TCP將有可能會(huì)逐漸退出歷史舞臺(tái)（這個(gè)進(jìn)程會(huì)應(yīng)該比較長(zhǎng)，乃至像IPv6相一起間拖很久）。也便是說(shuō)，面試者們今后就不用了解3次握手和4次揮手了？

QUIC現(xiàn)已成為正式規(guī)范了，那HTTP/3成為正式規(guī)范也就指日可下了。

WebGPU 要來(lái)了

2021年，Chrome 94新增了試用特性WebGPU，供給了運(yùn)用GPU的Web API，能夠用于圖像渲染（比方3D渲染）以及進(jìn)行數(shù)據(jù)并行核算（比方機(jī)器學(xué)習(xí)）。

WebGPU關(guān)于Web來(lái)說(shuō)無(wú)疑是一個(gè)革命性的特性，核算機(jī)職業(yè)本質(zhì)上是通過(guò)摩爾定律（摩爾為CPU廠商Intlel的創(chuàng)始人之一）以及黃氏定律（黃氏即黃仁勛，GPU廠商英偉達(dá)的創(chuàng)始人，別號(hào)核彈教父）所推進(jìn)的，芯片核算才能的提高為咱們帶來(lái)歷次核算機(jī)職業(yè)革命：個(gè)人電腦、互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)。當(dāng)GPU的核算才能越來(lái)越強(qiáng)，越來(lái)越重要時(shí)，Web卻不能很好地運(yùn)用，這顯然是不合理的。

WebGPU這個(gè)特性所對(duì)應(yīng)的是WebGPU和WebGPU  Shading Language這2個(gè)提案，由Google、Mozilla以及Apple的工程師負(fù)責(zé)。WebGPU和WebGPU  Shading Language提案都是由W3C的GPU for the  Web工作組起草的，該工作組成立于2017，通過(guò)4年的盡力，WebGPU總算開(kāi)端試用了，也是不容易??！WebGPU提案定義了Web中運(yùn)用GPU的API，WebGPU  Shading  Language（WGSL）提案定義了GPU代碼的編程言語(yǔ)。WebGPU得到了4大瀏覽器巨子（Safari，F(xiàn)irefox、Edge）的支撐，因而WebGPU成為正式的W3C規(guī)范僅僅時(shí)刻問(wèn)題。

WebGPU于Chrome 94開(kāi)端試用，估計(jì)將于Chrome 102正式發(fā)布，時(shí)刻大概是下一年5月份。如此重要的特性，可能咱們還沒(méi)來(lái)得及學(xué)會(huì)怎樣運(yùn)用，只試用8個(gè)月時(shí)刻就正式發(fā)布的話，似乎有點(diǎn)太倉(cāng)促了。

WebGPU是WebGL的繼承者，它們的方針相似，不過(guò)WebGPU供給了愈加底層的GPU才能。因而，WebGPU的圖像渲染才能更強(qiáng)，功能更好，更易用，也愈加適用于數(shù)據(jù)并行核算以及機(jī)器學(xué)習(xí)。

依據(jù)Safari的測(cè)驗(yàn)成果，WebGPU的功能在各種設(shè)備上都遠(yuǎn)高于WebGL：

圖片來(lái)歷：WebGPU and WSL in Safari

前端機(jī)器學(xué)習(xí)庫(kù)TensorFlow.js也測(cè)驗(yàn)了一下WebGPU，成果發(fā)現(xiàn)WebGPU的功能更好，可是差距與WebGL并不是特別明顯，有待進(jìn)一步研究：

圖片來(lái)歷：Fast client-side ML with TensorFlow.js

如下圖，WebGPU是依據(jù)各種GPU API（例如DirectX 12、Metal、Vulkan）完成的。

圖片來(lái)歷：Access modern GPU features with WebGPU

WebGPU供給的是底層API，十分強(qiáng)大，一起也十分復(fù)雜。運(yùn)用WebGPU完成向量乘法的代碼長(zhǎng)達(dá)200行，目測(cè)社區(qū)將會(huì)呈現(xiàn)第三方庫(kù)封裝WebGPU，供給更簡(jiǎn)單的運(yùn)用方式用于不同的運(yùn)用場(chǎng)景。

依據(jù)測(cè)驗(yàn)，運(yùn)用WebGPU進(jìn)行向量乘法核算時(shí)，跟著向量長(zhǎng)度添加，其功能遠(yuǎn)優(yōu)于運(yùn)用CPU：

圖片來(lái)歷：Get started with GPU Compute on the web

Chrome 番外篇

2021年，Chrome之外的前端娛樂(lè)圈也相當(dāng)精彩，仍是有很其他值得重視的變化，我這里聊一些我比較重視的事情。

Chrome中心開(kāi)發(fā)者之一Alex  Russell（本年換崗去Edge了）寫(xiě)了一篇十分詳盡的檄文Progress Delayed Is Progress  Denied，責(zé)備Safari及其瀏覽器引擎Webkit嚴(yán)峻落后，App  Store要求一切瀏覽器在iOS端必須運(yùn)用Webkit引擎的政策嚴(yán)峻制約了Web技能的開(kāi)展，導(dǎo)致很多Web新技能無(wú)法即時(shí)運(yùn)用到iOS端。出于保護(hù)App  Store的商業(yè)利益，Apple不太可能主導(dǎo)拋棄對(duì)iOS端Web技能的操控，競(jìng)爭(zhēng)對(duì)手只能付諸法律手段。游戲廠商Epic  Game正在和Apple打官司，企圖繞開(kāi)App  Store，允許第三方付出，這事盡管和Webkit沒(méi)啥聯(lián)系，可是也算是在應(yīng)戰(zhàn)蘋(píng)果關(guān)于iOS端的操控吧。是的，Web技能能否在移動(dòng)端得到突破性的開(kāi)展，取決于蘋(píng)果是否放開(kāi)對(duì)iOS端瀏覽器引擎的限制，這事得靠打官司，代碼寫(xiě)得再好也沒(méi)有，得靠律師的口才。谷歌大概率不會(huì)為了Chrome和蘋(píng)果打官司，由于安卓面對(duì)同樣的獨(dú)占指控，那不是搬起石頭砸自己的腳嗎？所以這事現(xiàn)在是無(wú)解的。Chrome有時(shí)會(huì)不管Safari是否支撐就發(fā)布一些瀏覽器特性，也是不得已而為之吧，如果等Safari那黃花菜都涼了。

前端范疇的明星公司Vercel于11月取得1.5億美元融資，估值25億美元，前端結(jié)構(gòu)居然這么值錢(qián)了？Vercel的愿景是"make  the Web. Faster."  這個(gè)愿景仍是很贊，幻想空間也很大。事實(shí)上，它們做的的確也不錯(cuò)，通過(guò)運(yùn)用Rust將構(gòu)建速度提高了5倍，讓人印象深入，值得重視。另一個(gè)值得重視的公司是Figma，融資2億美元，估值100億美元。Figma不僅僅把Sketch搬到了Web，而是改動(dòng)了規(guī)劃辦法以及規(guī)劃流程，一起建立了規(guī)劃師社區(qū)。Figma的商業(yè)模式仍是十分清晰，有對(duì)標(biāo)的巨子Adobe，國(guó)內(nèi)也有對(duì)標(biāo)的公司比方藍(lán)湖、稿定規(guī)劃、即時(shí)規(guī)劃等，前途無(wú)量。跟著Web技能的不斷前進(jìn)，大前端的商業(yè)價(jià)值越來(lái)越大，這關(guān)于從事這個(gè)職業(yè)的人無(wú)疑是有利的。

Rust在Web生態(tài)系統(tǒng)中的運(yùn)用也值得重視。Rust由Mozilla開(kāi)發(fā)，而且常用于WebAssembly場(chǎng)景，算是血統(tǒng)十分純粹的"前端言語(yǔ)"。明星項(xiàng)目Deno和Next.js都在用Rust，乃至Chrome也在試驗(yàn)用Rust開(kāi)發(fā)。不過(guò)，Rust的學(xué)習(xí)曲線比較陡峭，現(xiàn)在僅運(yùn)用于前端根底設(shè)施的開(kāi)發(fā)，未來(lái)大概也會(huì)是這樣，對(duì)這一塊感興趣的同學(xué)能夠卷起來(lái)了！

總結(jié)

通過(guò)這一年的調(diào)查，我深入地體會(huì)到Chrome依然在餞別開(kāi)端的理想：drive the web forward，添加瀏覽器的才能，提高瀏覽器的速度，拓展瀏覽器的運(yùn)用場(chǎng)景，的確十分了不得！因而，咱們有理由信任，Chrome會(huì)越來(lái)越好，Web會(huì)越來(lái)越好。

當(dāng)然，這個(gè)系列的博客，我仍是會(huì)繼續(xù)寫(xiě)下去，繼續(xù)分享自己關(guān)于Chrome的思考，歡迎重視。

才疏學(xué)淺，我所寫(xiě)的內(nèi)容不免有錯(cuò)誤之處，歡迎批評(píng)指正，感興趣的同學(xué)能夠微信溝通：KiwenLau。

參考資料

• 十年磨一劍，WebAssembly是怎樣誕生的？
• Chrome是怎樣成功的？
  
• 從 WebGL 到 WebGPU ，網(wǎng)頁(yè)圖形的全新時(shí)代
  
• Google Chrome announcement
• A fresh take on the browser
• Inside Chrome: The Secret Project to Crush IE and Remake the Web
• Adobe Flash is Dead: Here's What That Means
• 2021年1月1日，是Flash的葬禮日
• Thoughts on Flash
• What makes Flash so insecure and what are the alternatives?
• Fast, parallel applications with WebAssembly SIMD
• Harnessing Your Hardware with SIMD
• Zoom on Web: getting connected with advanced web technology
• Supercharging the TensorFlow.js WebAssembly backend with SIMD and multi-threading
• Background Features in Google Meet, Powered by Web ML
• 15x Faster TypedArrays: Vector Addition in WebAssembly
• WebAssembly Exception Handling: A Toolchain's Perspective
• emscripten：C++ exceptions support
• Strings in WebAssembly (Wasm)
• Making WebAssembly better for Rust & for all languages
• WebAssembly Reference Types in Wasmtime
• WebAssembly Reference Types Implemented in wasmtime, Lets Wasm Modules Handle Complex Types
• Photoshop's journey to the web
• 淺入淺出WebGPU
• Access modern GPU features with WebGPU
• Fast client-side ML with TensorFlow.js
• Get started with GPU Compute on the web
• The QUIC Transport Protocol: Design and Internet-Scale Deployment
• QUIC 101
• QUIC is now RFC 9000
• Rust and C++ interoperability
• 《浪潮之巔（第四版）》第18章：應(yīng)戰(zhàn)者 - Google公司