前言
这是一篇科普娱乐向的文章，将会带大家熟悉前端标准的制定流程，并在2023年的时间点思考前端的发展。
制定
不论前端娱乐圈多么丰富，Vue、React、Angluar、Svlelte 等前端框架如何百花齐放， Webpack、Rollup、Vite、Turbopack 等构建工具层出不穷，他们都离不开前端的三大件：JavaScript、HTML、CSS。我们现在就来看看这三大件的标准是如何产生的。
JavaScript 标准
JavaScript 是 ECMAScript 的实现和扩展，ECMAScript 是由 Ecma 的 TC39 小组通过 ECMA-262 标准化的语言。所以我们常说的 JavaScript 标准，其实严格的来说应该是 ECMAScript 标准。
ECMAScript 标准发展到今天已经经历了 N 个版本，并且在 ECMAScript2015，也就是大家熟知的 ES6 这个版本有了很大的改进。我们现在常用的箭头函数、块级作用域、模版字符串、Promise、Proxy、Reflect 都是在这个时期新增的。也是从这个版本开始，他的命名开始使用 ECMA + 年份的形式，如 ECMA2016，ECMA2017。如果对 JavaScript 语言的演化历程感兴趣，推荐可以看看由 JavaScript 之父 Brendan Eich 与 ES6 规范首席作者 Allen Wirfs-Brock 联合编写的 JavaScript 二十年。
现在 JavaScript 的制定过程包含了从 Stage0 到 Stage4 5个阶段以及一个 Inactive 状态
- Stage0 - Strawperson：开放提交阶段。
- Stage1 - Proposal：产出了一个正式的提案，在这个阶段可以发现一些潜在的问题。
- Stage2 - Draft：草案阶段，原则上后续只会接受增量修改。
- Stage3 - Candidate：一般到这个阶段的标准已经制定完毕，后面要做的是标准的实现并从实现者，用户出收集反馈。由于标准内容除非实现上有问题，已经不太可能更改。对于开发者来说，如果有合适的 polyfill，其实可以在日常开发中使用起来。可以看到我们已经在 Typescript 项目中广泛使用的 Decorator 依然处于这个阶段（五年啦，啥时候才能出头呀）
- Stage4 - Finished：意味着标准制定完毕，进入这个阶段的前提是市面上必须要有两个主流的实现完成。将在每年（通常是6月）新版规范发布的时候正式写入规范文档。在这里我们看见在2023年，会有 Array.findLast() 和 Array.findLastIndex() 的发布。
- Inactive：一些曾经提出但处于某种原因被放弃的规范。
HTML 标准
HTML 标准离不开下面两个标准制定的机构：
- W3C（World Wide Web Constortium，万维网联盟）
- WHATWG（Web Hypertext Application Technology Working Group，网页超文本应用技术工作小组），主要由苹果，谷歌，Mozilla，微软四大浏览器厂商组成
关于 HTML 标准的历史渊源，网上曾经流传这这样的段子
当年 W3C 嫌自己的儿子 HTML 没出息，就拿出去扔在河边了，WHATWG 路过捡回去养。后来 HTML 长大了，出息了，W3C 又找 WHATWG 来要儿子，WHATWG 好歹也养了三年，不是很同意，但是生父终究是生父啊，于是就共同抚养呗。W3C 领 HTML 回去之后，给 HTML 取个新名字 HTML5， 但是抚养过程中，W3C 想要 HTML5 当公务员，找个稳定的金饭碗，WHATWG 想要 HTML 去创业，于是分歧越来越大。曾经 HTML5 精神分裂，一半去给W3C当儿子，一半去给WHATWG当儿子。
幸好的是在 2019 年，WHATWG 和 W3C 签署了谅解备忘录，毕竟相对于 WHATWG 背靠浏览器厂商，对于标准的实现有更多的发言权。后续的方式将是WHATWG 负责维护的 HTML 标准 和 DOM 标准 ，W3C 同时也参与维护。
这里顺便说下 H5 这个名字，他在日常的产品文档，或者大家的交流中很常见了。虽然他只是 W3C 给 HTML 制定的一个大版本，实际上确已经比原本的含义扩展了许多。以至于 HTML 标准都会加上这么一句：the term “HTML5” is widely used as a buzzword to refer to modern web technologies。也就是说，H5 = WEB 前端
CSS 标准
由 W3C CSS Working Group 制定，他的制定流程 follow W3C。
总而言之，分为4个阶段：草案（WD） → 候选(CR) → 提案（PR）→ 标准（REC）。相比于 WHATWG 的流程，可以看出 W3C 的流程是冗长的。
其他相关标准
如果经常翻阅相关文章，我们通常会看到 RFC xxxx 这样的标准，RFC 指带的是 Request for Comments。 这其实是 IETF（The Internet Engineering Task Force）、IRTF（Internet Research Task Force）、IAB（Internet Architechure Board）这样的标准组织书写的记录互联网规范、协议、过程等的标准文件。拿 HTTP 协议举例
- HTTP/1.0 是 IETF 通过 RFC 1945 在1996年制定的。
- HTTP/1.1 是 IETF 通过 RFC 2068 在 1997 年制定的，1999年通过 RFC 2616 写了新版，在2014年又细化拆分为 RFC 7230、RFC 7231、RFC 7233、RFC 7234、RFC 7235 五个 RFC。
- HTTP/2 是 IETF 通过 RFC 7540 在 2015年制定，在 2022年通过 RFC 9113 写了新版。
- HTTP/3 是 IETF 通过 RFC 9114 在 2022年制定完成。
我们可以在 RFC Search 去搜索更多的标准文件。
实现
Javascript
JavaScrpit 标准有着众多的实现，下面列举几个比较常见的：
- V8：现阶段最著名实现，由 Google 开发。他直接被用在了 Chrome 和 Node.js 当中。
- JavaScriptCore：由苹果开发，被用于 Mac 以及 iPhone 的 Safari 或其他 Webkit 内核的 Webview 中。早期的 ReactNatvie 也使用了该引擎
- SpiderMonkey：世界上第一款 Javascript 引擎，曾经被用在已死去的 Netscape 中，现在仍然被用在 Firefox 浏览器中。
- Chakra：作为曾经的 Microsoft Edge 的默认引擎，由于 Microsoft Edge 全面转向 Chromium 内核，后续基本上只会做一些安全性上的升级。
- Hermes：由 Facebook 带来，用于 ReactNative 中，并为其做了特别的优化
渲染引擎
在渲染引擎的实现上，主要有以下几个内核：
- WebKit：Safari 等一系列苹果软件使用的内核。关于该内核的标准实现状态可以看这里。
- Blink：2013 年从 WebKit fork 而出，Chromium 使用的内核，现在新版的 Micrsoft Edge 也使用了该内核。
- Gecko：Firefox 浏览器使用的内核。
- Servo：基于 Rust，曾经是 Mozilla 的实验性项目，主打支持并行渲染。2020年由 Linux 基金会接管。
- Trident：已死去的 Internet Explorer 的内核
对现有各个阶段的标准查阅和浏览器支持可以访问 ECMAScript Next compatibility table。Can I Use 也是一个很好的查阅网站。如果你是 node.js 开发者，相信这个网站可以帮助到你。
浏览器桌面 APP
随着 Electron 的诞生，我们除了可以在常规的浏览器中使用 WEB 技术，也可以使用 WEB 技术来构建一个完整的桌面应用。Electron 在一段时间内十分火爆，包括 VSCode，Postman，Cocos Creator，Notion，Figma 等一众流行的软件都使用了他。
因为每个 Electron 应用的 Chromium 和 V8都是独立打包的当你打开使用 Electron APP 列表 并看到以上的 APP 时，你不得不感叹 Electron 的普及，同时也应该担心自己机器的硬盘空间和内存占用了吧。
针对 Electron 的应用体积和内存占用问题，Tauri 作为替代品不失为可能的解决方案。相比于 Electron 每个应用都打包了单独的 Chromium，Tauri 的 WRY 渲染器直接使用系统自带的浏览器引擎（也就是说在 Windows 系统使用了 WebView2， MacOS，iOS 上使用 WebKit），在上层抹平不同浏览器接口的差异。这带来的结果就是相比动辄100MB 大的 Electron 应用，Tauri 应用通常只有不到 5MB。在内存占用上，由于使用了 rust，也似的他比 Electron 使用的 V8 要好很多。随着各家操作系统内置的浏览器不断进步，这种直接使用内置 Webview 的方式也许可以不像几年前会受到很大的挑战，反而带来的轻量便利会使 Tauri 脱颖而出。
在 2022 年末， Tauri 发布了 Mobile Alpha Release。随着他变得成熟，也许我们在 Hybrid 应用开发上可以有更多的解法
下一代图形 API
随着今年来元宇宙概念的兴起，图形 API 显得越来越重要。长久以来统治 Web 的是 WebGL。基于 OpenGL ES2.0 的 WebGL 1.0 发布于2011年。基于 OpenGL ES3.0 的WebGL 2.0 发布于2017年。
出于匹配现代图形 API 功能和引入 GPU 加速提升科学计算性能的考虑，WebGPU 将成为下一代 3D 图形 API 标准。
在标准制定上，由 GPU for the Web Community Group 负责制定，目前处于 Working Draft 阶段。对比 WebGL 的着色器语言 GLSL，WebGPU 的着色器语言 WGSL 据说更加明晰
在标准实现上，目前3大平台都已有自己的实现
早在 2017年，苹果就提出了 WebGPU 的原型，并将其命名为 WebMetal。
谷歌在这方面的实现被命名为 dawn。Chrome 已经从 113 版本开始支持 WebGPU。
Mozilla 这这方面的实现叫 wgpu。
随着浏览器版本的普及，主流的动效框架也在开始尝试使用 WebGPU，比如 three.js，Cocos Creator。
参考资料
World Wide Web Consortium (W3C)
Web Hypertext Application Technology Working Group (WHATWG)