2008年9月2日，Chrome浏览器终于公布了，长达2年的机密开发没有徒劳，出道即巅峰：

• 采纳多过程架构，防止某个Tab解体导致整个浏览器解体
• 开发了全新的V8引擎，将JavaScript的执行速度晋升了1个数量级
• 设计了十分简洁的用户界面，十分重视用户体验，比方可拖拽的Tab、反对搜寻的地址栏、默认暗藏书签栏、隐身模式等
  

当年主管Chrome我的项目的Sundar Pichai，在公布Chrome时是这样说的：

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

这种吹牛的话个别没人置信，不过Chrome真的做到了，而Pichai也因为领导Chrome我的项目所展示的杰出的远见和能力，起初出任谷歌CEO，走向人生巅峰。

Chrome不仅市占率第一，并且间接以及间接推动了一系列Web技术的提高：V8、ECMASCript 2015、HTTP/2、HTTP/3、QUIC、HTTPS、WebAssembly、WebGPU。。。

并不夸大地说，理解Chrome的倒退能够帮忙咱们了解整个前端行业的发展趋势，因为浏览器的能力就是前端行业的边界所在，而次要推动浏览器提高的就是Chrome。

那么，2021年，Chrome有哪些值得关注的变动呢？

对于《了不起的Chrome浏览器》

2021年，我开始写《了不起的Chrome浏览器》，这是我写得最长的一个系列博客，一共9篇：

• 了不起的Chrome浏览器（1）：Chrome 89开启Web利用的物联网时代
• 了不起的Chrome浏览器（2）：Chrome 90将默认应用HTTPS，Web更平安了
• 了不起的Chrome浏览器（3）：Chrome 91反对WebAssembly SIMD，减速Web在AI等畛域的利用
• 了不起的Chrome浏览器（4）：Chrome 92新增at和randomUUID办法，Canvas反对Display P3色域
• 了不起的Chrome浏览器（5）：Chrome 93反对Error Cause，我国首个ECMAScript提案能够用了
• 了不起的Chrome浏览器（6）：Chrome 94开始WebGPU试用，Web的图像渲染及机器学能力更强了
• 了不起的Chrome浏览器（7）：Chrome 95终于反对WebAssembly异样解决了
• 了不起的Chrome浏览器（8）：Chrome 96也反对WebAssembly援用类型了！
• 了不起的Chrome浏览器（9）：Chrome 97公布WebTransport，QUIC协定小试牛刀
  

为了写这篇博客，我把《了不起的Chrome浏览器》博客全副浏览了一遍，发现自己真的写了好多知识点：从简略的ECMAScript新个性（Top-level await、Array.prototype.at）、到简单的安全漏洞（NAT Slipstream 2.0、ALPACA、Sweet32）、再到有意思的Web API（Web NFC、Web Serial API、Secure payment confirmation）、以及一些重要的技术创新（WebAssembly SIMD、WebGPU、WebCodecs）。其实，很多常识细节我都有点忘了，再看一遍也挺有播种的。这也是写作的益处之一，能够作为学习笔记，以便须要的时候查阅。

写Chrome博客破费了我大量的业余时间，继续更新其实挺难的。不过，写作原本就是我的趣味，也是最重要的学习形式之一，所以我还是保持下来了。

《了不起的Chrome浏览器》的累计浏览量还不错，均匀每篇博客的全网浏览量在5000以上，每篇博客的具体浏览量如下图所示：

我的长期指标是在2025年出版一本对于Chrome的书，毕竟出书是很多酷爱写作的人最高的谋求。这本书首先要有肯定的技术深度，同时可读性要足够好，并且能讲清楚技术倒退背地的起因，包含技术和商业动机。 所以，写《了不起的Chrome浏览器》博客对我来说，相当于积攒写书的素材和灵感。当然，写技术书其实并不怎么赚钱，我也不是为了赚钱，更加不会为了赚钱去写一些没有价值的内容。

Chrome 2021

2021年，Chrome一共公布了9个版本，从Chrome 88到Chrome96：

我是从Chrome 89开始写《了不起的Chrome浏览器》博客的，所以错过了Chrome 88。另外，Chrome 92切实没有发现什么特地大亮点，大略是其余版本太卷了。。。整体来看，Chrome在2021年的体现相当让人惊艳。

2021年，Flash停服了。Chrome也彻底辞别了Flash，完结了一代人对于Flash游戏、动画、视频的记忆，比方开心农场、QQ空间。据传，此事还导致某地铁路零碎呈现故障，相当难堪。Flash补救了晚期Web能力的有余，然而自身存在重大的平安危险，随着Web技术的迅速提高，Flash早就没那么重要了。Adobe在2017年就给Flash宣判了死刑，这一天还是来了。

图片起源：Goodbye Flash, goodbye FarmVille

2021年，WebAssembly更强了。Chrome相继反对WebAssembly SIMD、WebAssemblyException Handling以及WebAssemblyReference Types，这些都是十分重要的WebAssembly个性。赫赫有名的Photoshop终于迁徙到了Web，是通过将C++编译为WebAssembly来实现的，其中WebAssembly Exception Handling与WebAssembly SIMD施展了重要的作用。

图片起源：Photoshop's journey to the web

2021年，QUIC协定公布了。这将有助于晋升网络通信的性能、安全性以及灵活性。这是计算机网络倒退的革命性里程碑，将来TCP将有可能会逐渐退出历史舞台（这个过程会应该比拟长，甚至像IPv6一样工夫拖很久）。作为发明者，Chrome是最早部署QUIC协定的浏览器，再一次用技术扭转世界。

2021年，WebGPU要来了。Chrome 94开始了WebGPU试用，预计将于2022年上半年正式公布。WebGPU是WebGL的继承者，它们的指标相似，不过WebGPU提供了更加底层的GPU能力。因而，WebGPU的图像渲染能力更强，性能更好，更易用，也更加实用于数据并行计算以及机器学习。

Flash停服了

亨利福特已经说过：

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

在马车时代，人们只会心愿马车能跑得更快一点，而不会想到马车会被汽车取代。

相似的，尽管Flash也曾辉煌过很长一段时间，然而仍然还是被时代摈弃了。

Flash在中国的高光时刻大略是全民偷菜？这个简略的游戏已经让企鹅赚得盆满钵满。

图片起源：2021年1月1日，是Flash的葬礼日

我没玩过偷菜，然而我也曾用过QQ空间（暴雷年龄了）。那些杀马特的QQ空间，当年靠的就是Flash，把页面整的花里胡哨的。

图片起源：2021年1月1日，是Flash的葬礼日

对Flash怨念最深的莫过于乔布斯了，iPhone从一开始就不反对Flash。乔帮主还亲自写了一篇文章Thoughts on Flash鞭挞Flash不平安、BUG多、关闭、费电、对触屏不敌对，有理有据有节。从这篇文章也能看进去，乔帮主绝非不懂技术，反而技术视线还不错，对Flash存在的技术问题剖析得十分到位，切中要点。与乔布斯、盖茨以及马斯克这些美国企业家相比，中国的互联网大佬其实很多都是技术出身，然而都不怎么聊技术，这大略是因为中国互联网过来的倒退次要靠的是应用层以及商业模式的翻新，而不是技术层面的翻新。

那么问题来了，是乔帮主封杀Flash导致Flash衰败，还是Flash本人故障太多导致乔帮主不得不封杀Flash呢？我想更多是后者，人不自救，孰能救之。

当然，苹果并非没有公心，它更心愿将开发者管制在苹果的生态系统中。苹果扯着HTML5的大旗封杀Flash，不过起初对Web技术远不如谷歌来的激情。

晚期，Flash被因为播放视频、制作动画、展现广告等。起初，Web技术的不断进步，比方video标签、Canvas、WebGL、SVG，逐渐代替了Flash的作用，Flash也就失去了市场。

念旧的人们大略会有些伤感，然而事实上，没有Flash之后的Web会更加平安、更加晦涩，这就更加扎心了。。。

WebAssembly更强了

2021年无疑是WebAssembly的小年。

在技术方面，Chrome相继反对了WebAssembly SIMD、WebAssemblyException Handling以及WebAssemblyReference Types这3个重磅个性。

在利用方面，宇宙级图片解决工具Photoshop通过应用WebAssembly迁徙到了Web，另外基于WebAssembly实现的设计工具Figma估值达到惊人的100亿美元，两者都证实了WebAssembly的微小价值。

对WebAssembly感兴趣的同学，欢送浏览我的博客《十年磨一剑，WebAssembly是如何诞生的？》，理解WebAssembly的倒退历史。

WebAssembly SIMD

Chrome 91默认开启了WebAssembly SIMD。

SIMD是Single Instruction Multiple Data的缩写，中文术语为“单指令多数据流”，顾名思义，就是能够应用单条指令同时解决多个数据。

SIMD是一种非凡的CPU指令，它能够实现数据层面的并行处理。如下图，当咱们须要对两个长度为4的数组做加法时，应用一般的指令，则须要执行4次一般加法指令；如果应用SIMD指令的话，则只须要执行1次向量加法即可：

SIMD罕用于视频、音频、图像、加密、动画、游戏、AI等须要解决大量数据的利用场景，能够极大地提高向量类型的数据处理性能。支流的CPU都有SIMD指令，比方x86的SSE、ARM的Neon。

WebAssembly SIMD为WebAssembly新增了一个变量类型v128及其一系列v128的运算符，这些运算符就是SIMD指令。另外，由名字可知v128类型的长度是固定的，为128比特。

SIMD的指令十分多，而且不同CPU的SIMD是不一样的，WebAssembly SIMD只选取了各个CPU都反对的局部最罕用的SIMD指令。因而，能够将WebAssembly SIMD了解为各个CPU的SIMD指令的子集，同时将各个CPU的SIMD指令进行了一层形象和对立，开发者只须要学习WebAssembly SIMD，而不须要理解底层CPU的SIMD。

目前，Emscripten仅反对将WebAssembly SIMD指令编译为x86 SSE/AVX指令以及ARM Neon指令。

在计算机领域，貌似没有什么问题是用分层解决不了的，如果有的话，能够再分一层。

目前，WebAssembly SIMD这个提案曾经进入WebAssembly提案流程的Phase 4（Standardize the Feature），尚未齐全实现，不过离最初实现也只有1个Phase了，能够了解为根本实现了。V8（Chrome、Node.js）、Firefox以及Emscripten都曾经实现了WebAssembly SIMD。

Google Meet借助WebAssembly实现了视频的实时背景虚化以及背景代替，这样能够让加入线上会议的人把注意力集中在人而不是他所在的环境。对视频数据进行实时处理的话，对计算能力的要求十分高，应用WebAssembly SIMD使其性能晋升了至多2倍。

2021年，Photoshop终于迁徙到了Web，是通过将C++编译为WebAssembly来实现的，其中，WebAssembly SIMD施展了重要的作用，将性能均匀晋升了3到4倍，有些场景下甚至达到惊人的80到120倍。

WebAssembly Exception Handling

WebAssembly Exception Handling于Chrome 90开始试用，Chrome 95正式公布，为WebAssemly减少了异样解决语法，具体指令如下表所示：

WebAssembly/exception-handling提案由Google的开发者负责，以后处于WebAssembly提案流程的Phase 3，并且失去了Firefox、Safari以及Edge的反对，因而预计将会成为正式规范。

WebAssembly自诞生以来就没有异样解决语法，这是个挺大的问题。在浏览器环境下，WebAssemly的异样是通过JavaScript的try/catch来"模仿"的，这继承了Asm.js的解决形式。

基于JavaScript的WebAssembly异样解决形式如下图所示：

• 左侧为WebAssembly伪代码，右侧为JavaScript胶水代码；
• 依据右侧的JavaScript函数invoke_vi可知，WebAssembly模块的调用放在了JavaScript的try/catch语句中；
• 依据右侧的JavaScript函数___cxa_throw可知，WebAssmebly的throw语句实际上是应用JavaScript的throw语句来模仿；
• WebAssembly和JavaScript代码相互来回调用，这样生成的代码量减少了很多，同时升高了执行性能；

依据初步的测试后果，基于WebAssembly原生的异样解决形式，代码量升高了30%左右，同时性能晋升了30%左右，这个后果能够说十分现实了，用更少的代码实现了更好的性能。 从原理上来讲，这个后果并不让人意外。不过，因为目前测试数据还非常少，因而WebAssembly Exception Handling的实在成果还有待于进一步验证。

Photoshop移到了Web的过程中，WebAssembly Exception Handling也十分重要，因为C++中的异样解决代码十分场景。因而Photoshop也参加了WebAssembly Exception Handling规范的制订过程。

WebAssembly Reference Types

Chrome 96正式公布了WebAssembly Reference Types，Reference Types即援用类型，用externref关键词示意。

之前，WebAssembly仅反对32位及64位的整数和浮点数，这样使得解决简单数据比方String和Object时十分麻烦。

以字符串为例，如果咱们须要从JavaScript传入一个字符串给WebAssembly函数应用，则须要这样解决：

• 将字符串转换为整数（应用TextEncoder即可）
• 将整数写入WebAssembly的内存空间（WebAssembly的内存空间是一个线性的数组空间）
• 将整数数组的地址传给WebAssembly函数

尽管这些步骤由编译工具比方wasm-bindgen来解决，咱们不须要操心，然而这样做会生成大量胶水代码，损耗了编译和执行性能。

反对Reference Types之后，WebAssembly也能够欢快地解决整数及浮点数之外的数据类型了。

WebAssembly/reference-types提案曾经被纳入WebAssembly规范，Firefox和Safari之前曾经反对了。WebAssembly Reference Types使得其余WebAssembly提案成为可能，例如GC（Garbage collection）、Interface Types以及type Imports等。

WebAssembly/reference-types提案的负责人是Andreas Rossberg，他是Google前员工，参加了WebAssembly最后的设计，当初是WebAssembly外围标准的编辑。除了Reference Types，Andreas Rossberg还负责了WebAssembly的很多其余十分重要的提案，比方GC（Garbage collection）、Type Imports、Tail call等。

QUIC协定公布了

2021年，QUIC协定成为IETF的RFC，它是新一代传输层网络协议，是HTTP/3协定的根底：

由上图可知，QUIC协定相当于同时承当了TCP、TLS以及HTTP/2的职责：

• 提供相似于TCP的牢靠通信，解决丢包、拥塞等网络异常情况；
• 基于TLS/1.3进行加密，保障通信的安全性，同时防止两头节点烦扰导致协定僵化；
• 提供相似于HTTP/2的多路复用能力，在网络传输层减少了流的概念，解决了TCP协定的头部阻塞问题；
  

TCP是一个平凡的网络协议，然而它有很多问题，其最大的问题是TCP协定曾经僵化了，根本没法改了。QUIC最大亮点不在于解决了TCP头部阻塞的问题或者提供1-RTT甚至0-RTT的连贯时长，而是一系列保障可部署性、更快地迭代、防止协定僵化的设计，比方基于UDP、加密、脱离操作系统内核等。

QUIC协定的设计思维有点像React 17，在架构设计上简化将来的更新，保障长期倒退。

对QUIC协定趣味的同学，举荐看看QUIC 101视频以及The QUIC Transport Protocol: Design and Internet-Scale Deployment论文，讲得挺好的，我就赘述了。

总之，QUIC是一个大胆、激进、奇妙的网络协议。正如所有其余扭转世界的技术（比方WWW）一样，QUIC也是站在伟人的肩膀上，汲取了数十年TCP协定的各种教训和教训。

QUIC协定在往年5月成为IETF的RFC，这是计算机网络倒退的革命性里程碑，将来TCP将有可能会逐渐退出历史舞台（这个过程会应该比拟长，甚至像IPv6一样工夫拖很久）。也就是说，面试者们当前就不必理解3次握手和4次挥手了？

QUIC曾经成为正式规范了，那HTTP/3成为正式规范也就不可企及了。

WebGPU要来了

Chrome 94新增了试用个性WebGPU，提供了应用GPU的Web API，能够用于图像渲染（比方3D渲染）以及进行数据并行计算（比方机器学习）。

WebGPU对于Web来说无疑是一个革命性的个性，计算机行业实质上是通过摩尔定律（摩尔为CPU厂商Intlel的创始人之一）以及黄氏定律（黄氏即黄仁勋，GPU厂商英伟达的创始人，别号核弹教父）所推动的，芯片计算能力的晋升为咱们带来历次计算机行业反动：个人电脑、互联网、挪动互联网。当GPU的计算能力越来越强，越来越重要时，Web却不能很好得利用，这显然是不合理的。

WebGPU这个个性所对应的是WebGPU和WebGPU Shading Language这2个提案，由Google、Mozilla以及Apple的工程师负责。WebGPU和WebGPU Shading Language提案都是由W3C的GPU for the Web工作组起草的，该工作组成立于2017，通过4年的致力，WebGPU终于开始试用了，也是不容易啊！WebGPU提案定义了Web中应用GPU的API，WebGPU Shading Language（WGSL）提案定义了GPU代码的编程语言。WebGPU失去了4大浏览器巨头（Safari，Firefox、Edge）的反对，因而WebGPU成为正式的W3C规范只是工夫问题。

WebGPU于Chrome 94开始试用，预计将于Chrome 102正式公布，工夫大略是明年5月份。如此重要的个性，可能大家还没来得及学会怎么应用，只试用8个月工夫就正式公布的话，仿佛有点太仓促了。

WebGPU是WebGL的继承者，它们的指标相似，不过WebGPU提供了更加底层的GPU能力。因而，WebGPU的图像渲染能力更强，性能更好，更易用，也更加实用于数据并行计算以及机器学习。

依据Safari的测试后果，WebGPU的性能在各种设施上都远高于WebGL：

图片起源：WebGPU and WSL in Safari

前端机器学习库TensorFlow.js也测试了一下WebGPU，后果发现WebGPU的性能更好，然而差距与WebGL并不是特地显著，有待进一步钻研：

图片起源：Fast client-side ML with TensorFlow.js

如下图，WebGPU是基于各种GPU API（例如DirectX 12、Metal、Vulkan）实现的。

图片起源：Access modern GPU features with WebGPU

WebGPU提供的是底层API，十分弱小，同时也非常复杂。应用WebGPU实现向量乘法的代码长达200行，目测社区将会呈现第三方库封装WebGPU，提供更简略的应用形式用于不同的利用场景。

依据测试，应用WebGPU进行向量乘法计算时，随着向量长度减少，其性能远优于应用CPU：

图片起源：Get started with GPU Compute on the web

Chrome番外篇

Chrome是前端畛域的外围，但也不是所有。2021年，Chrome之外的前端娱乐圈也相当精彩，还是有很其余值得关注的变动，我这里聊一些我比拟关注的事件。

Chrome外围开发者之一Alex Russell（往年跳槽去Edge了）写了一篇十分详尽的檄文Progress Delayed Is Progress Denied，指摘Safari及其浏览器引擎Webkit重大落后，App Store要求所有浏览器在iOS端必须应用Webkit引擎的政策重大制约了Web技术的倒退，导致大量Web新技术无奈即时利用到iOS端。出于保护App Store的商业利益，Apple不太可能主导放弃对iOS端Web技术的管制，竞争对手只能付诸法律手段。游戏厂商Epic Game正在和Apple打官司，试图绕开App Store，容许第三方领取，这事尽管和Webkit没啥关系，然而也算是在挑战苹果对于iOS端的管制吧。是的，Web技术是否在挪动端失去突破性的倒退，取决于苹果是否放开对iOS端浏览器引擎的限度，这事得靠打官司，代码写得再好也没有，得靠律师的口才。谷歌大概率不会为了Chrome和苹果打官司，因为安卓面临同样的垄断指控，那不是搬起石头砸本人的脚吗？ 所以这事目前是无解的。Chrome有时会不论Safari是否反对就公布一些浏览器个性，也是不得已而为之吧，如果等Safari那黄花菜都凉了。

前端畛域的明星公司Vercel于11月取得1.5亿美元融资，估值25亿美元，前端框架竟然这么值钱了？Vercel的愿景是"make the Web. Faster." 这个愿景还是很赞，设想空间也很大。事实上，它们做的的确也不错，通过应用Rust将构建速度晋升了5倍，让人印象粗浅，值得关注。另一个值得关注的公司是Figma，融资2亿美元，估值100亿美元。Figma不只是把Sketch搬到了Web，而是扭转了设计办法以及设计流程，同时建设了设计师社区。Figma的商业模式还是十分清晰，有对标的巨头Adobe，国内也有对标的公司比方蓝湖、稿定设计、即时设计等，前途无量。随着Web技术的不断进步，大前端的商业价值越来越大，这对于从事这个行业的人无疑是无利的。

Rust在Web生态系统中的利用也值得关注。Rust由Mozilla开发，并且罕用于WebAssembly场景，算是血统十分纯正的"前端语言"。明星我的项目Deno和Next.js都在用Rust，甚至Chrome也在试验用Rust开发。不过，Rust的学习曲线比拟平缓，目前仅利用于前端基础设施的开发，将来大略也会是这样，对这一块感兴趣的同学能够卷起来了！

总结

2021年，我最大的播种之一就是开始写《了不起的Chrome浏览器》博客，学到了很多常识，也加深了本人对整个前端行业的了解。

其实，我在2019年就写过一篇Chrome是如何胜利的？，对Chrome的产品理念印象十分粗浅：Speed、Security、Stability、Simplicity，我也将4个S作为我本人开发产品的一个准则。

通过这一年的察看，我粗浅地领会到Chrome仍然在践行最后的现实：drive the web forward，减少浏览器的能力，进步浏览器的速度，拓展浏览器的利用场景，的确十分了不起！因而，咱们有理由置信，Chrome会越来越好，Web会越来越好。

当然，这个系列的博客，我还是会持续写下去，持续分享本人对于Chrome的思考，欢送关注。

满腹经纶，我所写的内容不免有谬误之处，欢送批评指正，感兴趣的同学能够微信交换：KiwenLau。

欢送关注寒雁Talk公众号，关注《了不起的Chrome浏览器》系列博客！

参考资料

• Chrome是如何胜利的？
• 了不起的Chrome浏览器（1）：Chrome 89开启Web利用的物联网时代
• 了不起的Chrome浏览器（2）：Chrome 90将默认应用HTTPS，Web更平安了
• 了不起的Chrome浏览器（3）：Chrome 91反对WebAssembly SIMD，加Web在AI等畛域的利用
• 了不起的Chrome浏览器（4）：Chrome 92新增at和randomUUID办法，Canvas反对Display P3色域
• 了不起的Chrome浏览器（5）：Chrome 93反对Error Cause，我国首个ECMAScript提案能够用了
• 了不起的Chrome浏览器（6）：Chrome 94开始WebGPU试用，Web的图像渲染及机器学能力更强了
• 了不起的Chrome浏览器（7）：Chrome 95终于反对WebAssembly异样解决了
• 了不起的Chrome浏览器（8）：Chrome 96也反对WebAssembly援用类型了！
• 了不起的Chrome浏览器（9）：Chrome 97公布WebTransport，QUIC协定小试牛刀
• 十年磨一剑，WebAssembly是如何诞生的？
• 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章：挑战者 - Google公司

招聘

阿里巴巴业务平台事业部长期招聘P6及以上前端大佬，参加建设最前沿的阿里前端生态系统，推动行业技术倒退，内推地址：hanyan.lk@alibaba-inc.com

欢送大家关注我的微信公众号寒雁Talk。