原文：
The Future Web: Will Canvas Rendering Replace the DOM?
60FPS of the mobile web
注：文末有其他翻译，根据理解加上了一些自己的见解，如有异议欢迎沟通交流。
Canvas渲染会取代DOM吗？
序言
Web1.0 1️⃣
web1.0时代，网页是只读的，用户只能浏览信息，并不能自己创造信息。在web1.0时代网站是不会和用户交互的，用户只能被动的接受这些知识。
这时候的关键技术就是浏览器。比如网景浏览器，文件服务器，黄页，网页搜索引擎。
Web2.0 2️⃣
社交化网络，这时候用户可以与网页进行互动，用户可以自己创建内容。比如微博的出现，用户可以自己在网站填写内容，分享给他人，他人可以阅读以及回复；即时通讯、邮件的出现，人们不仅可以自己创建内容，还可以满足通讯、交友等的各种需求。
Web3.0 3️⃣
【The Semantic Web is an extension of the World Wide Web through standards set by the World Wide Web Consortium. The goal of the Semantic Web is to make Internet data machine-readable.】
语义化网络，所谓的语义化网络，基础支撑技术是人工智能。
语义化是什么意思，比如有这几个句子 ‘我喜欢你’、‘我❤你’、‘我<3你’，这三个句子从句式上讲是不同的，但是表达的情感是相同的，这时候通过人工智能主动学习这些数据，这时候网络就变成了用户的理解者，用户想要什么，计算机都能知道，比如淘宝的千人千面，根据你的个人喜好，给你主动推荐。
Web4.0 4️⃣
ubiquitous，无所不在的；
虽然还不太清楚web4.0具体指什么，但是有一个普遍的认同就是万物互联 - 通过互联网串联智能硬件。同时有一个设备可以控制所有的终端。比如小米的智能家居，通过小米AI可以控制所有的智能家居，而我们的手机又可以控制智能终端，于是手机把所有的设备管理全集于一身。
Gmail📧
2004年4月1日，Google推出了Gmail，这带来了划时代的意义，他改变了电子邮件，也改变了许多事。
Gmail的推出是在大家对邮箱应用已经毫无兴趣的时候，但却让所有人眼前一亮——原来邮箱还可以这么做，大量 Ajax 技术的使用，使得邮件的操作体验一流，Gmail 加速了 Ajax 技术在Web上的应用，以致现在几乎所有邮箱系统都使用了该技术。
在引领技术变革这方面，Google一直走在前面；之前也跟团队的小伙伴讨论过，会不会终有一天DOM我们不再需要，而页面只有一个Canvas，Canvas这个画布承载了所有渲染，比如目前还有什么Canvas做不到，图片、视频、svg、webgl都是通过Canvas这个通道来渲染到页面上，所有复杂渲染都是Canvas来呈现；所以当看到这篇文章中关于Google把Canvas应用到Google Docs上，出于对未来的恐惧(就想躺平，学不动了)，赶紧安利一下；
H5目前的优势✅
1、跨平台，可以运行在安卓、ios和window上；
2、开发成本低，周期短；
3、内容不受限；
4、可以显示大段文字，比如一些新闻 ，还有丰富的格式，比如各式各样的文字；
5、用户可以直接看到最新的版本，用户无需感知就更新；
H5目前的问题❌
1、由于网络技术自身的局限性，h5页面不能直接接触硬件和离线缓存，导致在性能和用户体验上有一个很大的局限性，体验差，页面打开受网络的影响，容易导致白屏，用户体验较；
2、用户粘性不高，单一页面，用户看完即走， 用户的留存率很低。
3、互动性欠缺，虽然页面会有一些互动效果，但是和NA相比还是互动性欠缺。
4、h5的更新迭代很快，页面生命周期短，做不到长期维护。
5、h5同质化严重，页面雷同比较严重。
综述，我们作为软件工程师、程序员、WEB开发工程师、前端体验工程师；除了要踏踏实实走好脚下的路，还要仰望星空，看清楚未来要去哪里。
文章节选📝
🔖节选自 [The Future Web: Will Canvas Rendering Replace the DOM? ]
目前有很多文章关注到Google决定把它的Google Docs 用Canvas渲染的方式来替代Dom。Google的决定并不是空穴来风，很多业界领先的web app以及在这块走的很远了。Google map已经用canvas来渲染了，VScode也用canvas拉渲染它的terminal，Google的flutter也在它提供的默认浏览器里提供了canvas的渲染方式。
Canvas整合其他的Web技术，例如WebAssembly，看来已经把我们带到了一个临界点。下载js代码并且执行它并生成Dom元素，可能只是一个短暂的停留在快速进化的web开发领域。
Canvas的渲染方式将会扩展开来
15年前，Google在作为异步调用的开路先锋(那时候还叫做Ajax)。紧接着这项技术变成了Google Map和Gmail基础设施。现在。Google决定用Canvas渲染UI，可能会带来web 开发的新时代。
目前，用Canvas来渲染还是有一个非常高的门槛的。
最大的挑战就是可访问性。为了遵守可访问性标准，你的应用需要满足某一些必要的条件。
Everything that can be done in JavaScript will be done in JavaScript, even if you need to evolve JavaScript to get there.
任何能用js写的，最终都会用js来写。
语义化WEB已死
Canvas渲染显而易见的是语义化网络的反面。
这对于浏览器来说是一个黑盒，完全拿不到关于这个网页的任何信息。
Canvas 能将应用程序完全的掌控在手中。如果你能控制像素，你就能做任何事情。比如可以绕过一些自动化工具，可以绕过一些广告拦截插件，可以限制一些浏览器搜索引擎和文本复制等。
WEB的未来是WebAssembly 和binary blobs
Webassembly已经被用来运行游戏，解码基因序列，还可以跑.net框架，跑C#语言；而且Webassembly承诺会提供匹配原生应用的性能和体验。
目前WEBGPU和WEBGL都是通过Canvas这个通道来渲染页面。通过这两个，再加上浏览器自身提供的硬件加速，你可以去创建下一代的Web应用。
Immediate mode vs. retained mode
Canvas是一种即时模式的渲染方式，不会存储额外的渲染信息。Canvas 受益于即时模式,允许直接发送绘图命令到 GPU。但若用它来构建用户界面，需要进行一个更高层次的抽象。例如一些简单的处理,比如当绘制一个异步加载的资源到一个元素上时会出现问题,如在图片上绘制文本。在HTML中，由于元素存在顺序，以及 CSS 中存在 z-index，因此是很容易实现的。 Dom渲染是一种保留模式，保留模式是一种声明性API，用于维护绘制到其中的对象的层次结构。保留模式 API 的优点是，对于你的应用程序，他们通常更容易构建复杂的场景，例如 DOM。通常这都会带来性能成本,需要额外的内存来保存场景和更新场景，这可能会很慢。
Canvas带来的变化之我见🔭 🔬
1.对Web开发者
1、【前端框架】：
既然Canvas是一种即时的模式，那么它对于大量的元素的处理是极为擅长的，并且得益于GPU的海量的处理单元，页面将会即时显现；那么我们用的框架 VUE、React等的diff处理是不是不再需要，如果diff不再需要那框架还会保留什么，或者框架会演化成什么样？？
2、【页面控制】：
开发者对页面有完全的控制，Canvas是一个黑盒。任何浏览器的插件都不再有效。
3、【搜索引擎】：
搜索引擎用于爬取页面文本，如果页面是用Canvas来渲染，那么搜索引擎该如何自处？开发者想让页面广而告之又该做哪些工作？
4、【性能优化】：
目前我们为了达到页面如丝般的顺滑，要大量的工作，比如要压缩文件，降低Dom数量，页面各种资源的压缩合并；页面优化大体分为两块，请求优化和渲染优化， 如果请求可以交给未来的http3来解决，渲染交给Canvas，我们是不是更加专注于业务逻辑。
5、【三剑客】：
DOM、JS、CSS；如果DOM不再需要了，JS会做哪些改变？CSS呢？
2.对用户
1、【前端边界|用户边界】：
前端可以做的东西越来越多，用户在一个浏览器里就可以完成所有的事情，比如目前很多游戏都提供了浏览器的实现，VR、AR、以及目前概念大火的元宇宙；如果Canvas提供和原生NA一样的渲染性能，那么用户是不是就不需要下载更多的APP，一个浏览器就可以锁住用户了？
。。。。。。
3.其他
当然了，不可否认，目前的Canvas取代DOM还有很长的路要走，有很多的API需要重新开发，重新来适配，但是技术的发展谁能说的准呢。比如最初JS只是页面的脚本语言，用来校验用户的输入，目前JS已经发展成一个庞大的体系。谁能更准的遇见未来，谁就能更好的把握未来！
欢迎集思广益
写在后面
Are you ready for the next change ?
参考：
若有收获，就点个赞吧
0 人点赞
