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。