Canvas渲染会取代DOM吗?

Canvas渲染会取代DOM吗?
2021年07月23日 16:03 CSDN

作者 | Matthew MacDonald

译者 | 弯月     

出品 | CSDN(ID:CSDNnews)

Google最近决定使用HTML的来渲染Google Docs中的一切,引起了轩然大波。人们的担忧不无道理。曾几何时,Web的目标是分享架构化信息,包含合理的元数据,而且易于开展合作。然而,现在却成了在浏览器的沙盒中运行的半透明模型。 

从HTML元素切换到Canvas上的像素渲染,Google的这个决定并非史无前例。很多先进的Web早就突破了传统Web元素的束缚。Google地图多年前就开始使用Canvas渲染了。VS Code使用canvas来绘制像素级的终端界面。Google新兴的跨平台UI框架Flutter在浏览器中也会默认使用Canvas。 

但这次感觉不一样。canvas渲染加上WebAssembly等其他技术,点燃了导火索。似乎我们熟悉的那种模式(下载JavaScript代码并在HTML文档中执行)只不过是Web开发进化之路上的一个过客而已。 

换一种说法,我们曾理所当然地认为,我们可以看到运行中的代码,检查标签,还可以查看CSS。但是,也许这一切只不过是软件设计长河中的一段小插曲。 

那么接下来会发生什么?

Canvas渲染方式越来越流行

人们总是对Google亦步亦趋。

大约15年前,Google是异步JavaScript调用(后来称作Ajax)的先驱。他们主导的这种技术被用到了Gmail和Google地图中,后来成了Web开发的基础。现在,Google开始在canvas上画UI,等于向新一代的Web开发者宣告了这种做法的合理性。 

目前,使用canvas渲染还有着不低的门槛。在Google Docs的构建过程中,Google重新发明了许多人们习以为常的东西,例如精确定位、文本选择、拼写检查、重画调优等。今天,只有少数几家公司才会考虑采用canvas渲染来获得可能的性能提升。 

最大的问题是可访问性。为了遵守可访问性的法规(作为像Google这样的政府供应商来说,合规是必须的,对于希望尽社会责任的企业来说,可访问性也非常重要),应用程序必须满足特定的要求。基于canvas的Google Docs依然需要为屏幕阅读器、屏幕放大镜、高对比度设置、低敏捷度特性等提供支持。他们的做法之一就是在真正的canvas渲染的内容之外,再专门为辅助工具实现一个不可见的DOM。当然,这两个模型之间要保持完美的同步。 

目前还没有现成的标准供开发者在使用了canvas渲染的应用程序中添加可访问性支持。但是随着canvas渲染技术的流行,这种情况也会改变,而且很难说会以多快的速度改变。Google越来越多地采用该技术,会给该领域带来大量的关注、发展和进步。很快就会出现许多库,然后就会出现标准和API。我们可以给阿特伍德定律加一条: 

“所有能用JavaScript实现的最终都会用JavaScript实现,哪怕需要改进JavaScript。”

语义Web已死

从整体来看,Google的行动只不过是漫长旅途中的一小步而已。从Web诞生那一天开始,野心勃勃的开发者们就在想尽一切办法冲破页面模型和HTML抽象的束缚。当年有Flash之类的插件。从那时起,对于Web的两种不同观点就开始了明争暗斗:Web究竟是结构化文档容器,还是应用程序容器?

这场冲突最激烈的部分莫过于XHTML的死亡。XHTML是一个异常严格的Web标准,旨在实施纯粹的语义化,而这个目标Web从未实现。XHTML曾被誉为“Web的未来”,但突然就被HTML5打败了。 

而HTML5对于Web的定义是“浏览器制造商们一致同意的任何标准”。它包含了一组实际的JavaScript API集合(地理位置、本地存储、Web套接字、后台worker等),这些API可以像搭积木一样嵌入到页面中。当然,它也包含几个新的语义描述元素,但在嵌入信息方面,唯一的激进功能就是microdata,然而这个功能不久后就被除名了(很大程度上因为Google和苹果没兴趣实现该功能)。 

Canvas渲染显然站在富语义页面的对立面。它是一个黑盒子,其内部的情况浏览器无从知晓。 

Canvas渲染将一切权力都交给了应用程序。通过控制像素秒回,你可以实现任何事情:可以阻止自动化工具,绕过广告拦截器,限制浏览器功能(如搜索、文本复制等)。它只不过是用JavaScript实现的Flash或Silverlight,不需要安装,也没有兼容性问题而已。

未来属于WebAssembly和二进制块

可能你认为Canvas渲染很重要,但从Web开发的全局来看,它只不过是小巫见大巫。真正的巨兽毫无疑问是WebAssembly,这是一个所有现代浏览器都能理解的底层二进制指令格式。

如今,当你访问一个由WebAssembly制作的网页时,你运行的实际上是预先编译好的代码,这些代码只不过比汇编语言高级了一点点,比那些极限压缩并混淆过的JavaScript还要难懂。WebAssembly被用来运行游戏、解码基因序列,或者用来运行更高层的框架,如.NET的Blazor环境。WebAssembly能够在不离开浏览器沙盒的前提下提供近乎原生应用的性能,与之相比,对于不透明Web应用程序的担忧是那么苍白无力。

目前,WebAssembly需要一层复杂的JavaScript互操作层才能访问DOM。但下一个阶段是WebGPU,这是已遭废弃的WebGL项目的继任者。WebGPU和WebGL都采用了同样的方法,即为canvas渲染的表面提供优化后的访问。与浏览器实现的硬件加速结合起来,就可提供一个底层的绘图表面,供开发者构建下一代Web应用程序,或者构建下一代库和框架,为下一代Web应用程序提供动力。依照WebAssembly的炒作力度,很难想象未来的Web开发不会使用WebAssembly和WebGPU。

为什么不呢?毕竟,如果开发者要从头开始开发Google Docs,他们绝不会选择Google Docs一直沿用至今的模型(构建在HTML布局引擎上的文档布局引擎,与一个JavaScript抽象紧密耦合)。这个模型之所以存在,只不过是因为它能用而已。从设计的角度来看,它是一个扭曲的奇迹,而不是优美的软件。

即使是未来的Web应用程序,传统Web的观点也依然会存在于适合的地方,比如那些以内容为主的网站(科技文章网站、亚马逊产品目录等)。这些网站没有理由重新发明轮子、自定义渲染过程,并重新解决可用性的难题。但在未来,这些网站的行为不再是Web内容的标准。

相反,应用程序模型会完全打破今天的HTML/CSS抽象的桎梏。这种变化会让开发者回到一个完全自由但支离破碎的世界,他们需要从大量的语言和UI模型中做出选择。如果说过去的历史有何意义,那就是世界比我们想象得更近。

财经自媒体联盟

新浪首页 语音播报 相关新闻 返回顶部