Canvas渲染會(huì)取代DOM嗎？
點(diǎn)擊上方?前端Q，關(guān)注公眾號(hào)
回復(fù)加群，加入前端Q技術(shù)交流群
Google最近決定使用HTML的
從HTML元素切換到Canvas上的像素渲染，Google的這個(gè)決定并非史無前例。很多先進(jìn)的Web早就突破了傳統(tǒng)Web元素的束縛。Google地圖多年前就開始使用Canvas渲染了。VS Code使用canvas來繪制像素級(jí)的終端界面。Google新興的跨平臺(tái)UI框架Flutter在瀏覽器中也會(huì)默認(rèn)使用Canvas。
但這次感覺不一樣。canvas渲染加上WebAssembly等其他技術(shù)，點(diǎn)燃了導(dǎo)火索。似乎我們熟悉的那種模式（下載JavaScript代碼并在HTML文檔中執(zhí)行）只不過是Web開發(fā)進(jìn)化之路上的一個(gè)過客而已。
換一種說法，我們?cè)硭?dāng)然地認(rèn)為，我們可以看到運(yùn)行中的代碼，檢查標(biāo)簽，還可以查看CSS。但是，也許這一切只不過是軟件設(shè)計(jì)長河中的一段小插曲。
那么接下來會(huì)發(fā)生什么？
Canvas渲染方式越來越流行
人們總是對(duì)Google亦步亦趨。
大約15年前，Google是異步JavaScript調(diào)用（后來稱作Ajax）的先驅(qū)。他們主導(dǎo)的這種技術(shù)被用到了Gmail和Google地圖中，后來成了Web開發(fā)的基礎(chǔ)?，F(xiàn)在，Google開始在canvas上畫UI，等于向新一代的Web開發(fā)者宣告了這種做法的合理性。
目前，使用canvas渲染還有著不低的門檻。在Google Docs的構(gòu)建過程中，Google重新發(fā)明了許多人們習(xí)以為常的東西，例如精確定位、文本選擇、拼寫檢查、重畫調(diào)優(yōu)等。今天，只有少數(shù)幾家公司才會(huì)考慮采用canvas渲染來獲得可能的性能提升。
最大的問題是可訪問性。為了遵守可訪問性的法規(guī)（作為像Google這樣的政府供應(yīng)商來說，合規(guī)是必須的，對(duì)于希望盡社會(huì)責(zé)任的企業(yè)來說，可訪問性也非常重要），應(yīng)用程序必須滿足特定的要求?；赾anvas的Google Docs依然需要為屏幕閱讀器、屏幕放大鏡、高對(duì)比度設(shè)置、低敏捷度特性等提供支持。他們的做法之一就是在真正的canvas渲染的內(nèi)容之外，再專門為輔助工具實(shí)現(xiàn)一個(gè)不可見的DOM。當(dāng)然，這兩個(gè)模型之間要保持完美的同步。
目前還沒有現(xiàn)成的標(biāo)準(zhǔn)供開發(fā)者在使用了canvas渲染的應(yīng)用程序中添加可訪問性支持。但是隨著canvas渲染技術(shù)的流行，這種情況也會(huì)改變，而且很難說會(huì)以多快的速度改變。Google越來越多地采用該技術(shù)，會(huì)給該領(lǐng)域帶來大量的關(guān)注、發(fā)展和進(jìn)步。很快就會(huì)出現(xiàn)許多庫，然后就會(huì)出現(xiàn)標(biāo)準(zhǔn)和API。我們可以給阿特伍德定律加一條：
“所有能用JavaScript實(shí)現(xiàn)的最終都會(huì)用JavaScript實(shí)現(xiàn)，哪怕需要改進(jìn)JavaScript。”
語義Web已死
從整體來看，Google的行動(dòng)只不過是漫長旅途中的一小步而已。從Web誕生那一天開始，野心勃勃的開發(fā)者們就在想盡一切辦法沖破頁面模型和HTML抽象的束縛。當(dāng)年有Flash之類的插件。從那時(shí)起，對(duì)于Web的兩種不同觀點(diǎn)就開始了明爭暗斗：Web究竟是結(jié)構(gòu)化文檔容器，還是應(yīng)用程序容器？
這場沖突最激烈的部分莫過于XHTML的死亡。XHTML是一個(gè)異常嚴(yán)格的Web標(biāo)準(zhǔn)，旨在實(shí)施純粹的語義化，而這個(gè)目標(biāo)Web從未實(shí)現(xiàn)。XHTML曾被譽(yù)為“Web的未來”，但突然就被HTML5打敗了。
而HTML5對(duì)于Web的定義是“瀏覽器制造商們一致同意的任何標(biāo)準(zhǔn)”。它包含了一組實(shí)際的JavaScript API集合（地理位置、本地存儲(chǔ)、Web套接字、后臺(tái)worker等），這些API可以像搭積木一樣嵌入到頁面中。當(dāng)然，它也包含幾個(gè)新的語義描述元素，但在嵌入信息方面，唯一的激進(jìn)功能就是microdata，然而這個(gè)功能不久后就被除名了（很大程度上因?yàn)镚oogle和蘋果沒興趣實(shí)現(xiàn)該功能）。
Canvas渲染顯然站在富語義頁面的對(duì)立面。它是一個(gè)黑盒子，其內(nèi)部的情況瀏覽器無從知曉。
Canvas渲染將一切權(quán)力都交給了應(yīng)用程序。通過控制像素秒回，你可以實(shí)現(xiàn)任何事情：可以阻止自動(dòng)化工具，繞過廣告攔截器，限制瀏覽器功能（如搜索、文本復(fù)制等）。它只不過是用JavaScript實(shí)現(xiàn)的Flash或Silverlight，不需要安裝，也沒有兼容性問題而已。
未來屬于WebAssembly和二進(jìn)制塊
可能你認(rèn)為Canvas渲染很重要，但從Web開發(fā)的全局來看，它只不過是小巫見大巫。真正的巨獸毫無疑問是WebAssembly，這是一個(gè)所有現(xiàn)代瀏覽器都能理解的底層二進(jìn)制指令格式。
如今，當(dāng)你訪問一個(gè)由WebAssembly制作的網(wǎng)頁時(shí)，你運(yùn)行的實(shí)際上是預(yù)先編譯好的代碼，這些代碼只不過比匯編語言高級(jí)了一點(diǎn)點(diǎn)，比那些極限壓縮并混淆過的JavaScript還要難懂。WebAssembly被用來運(yùn)行游戲、解碼基因序列，或者用來運(yùn)行更高層的框架，如。NET的Blazor環(huán)境。WebAssembly能夠在不離開瀏覽器沙盒的前提下提供近乎原生應(yīng)用的性能，與之相比，對(duì)于不透明Web應(yīng)用程序的擔(dān)憂是那么蒼白無力。
目前，WebAssembly需要一層復(fù)雜的JavaScript互操作層才能訪問DOM。但下一個(gè)階段是WebGPU，這是已遭廢棄的WebGL項(xiàng)目的繼任者。WebGPU和WebGL都采用了同樣的方法，即為canvas渲染的表面提供優(yōu)化后的訪問。與瀏覽器實(shí)現(xiàn)的硬件加速結(jié)合起來，就可提供一個(gè)底層的繪圖表面，供開發(fā)者構(gòu)建下一代Web應(yīng)用程序，或者構(gòu)建下一代庫和框架，為下一代Web應(yīng)用程序提供動(dòng)力。依照WebAssembly的炒作力度，很難想象未來的Web開發(fā)不會(huì)使用WebAssembly和WebGPU。
為什么不呢？畢竟，如果開發(fā)者要從頭開始開發(fā)Google Docs，他們絕不會(huì)選擇Google Docs一直沿用至今的模型（構(gòu)建在HTML布局引擎上的文檔布局引擎，與一個(gè)JavaScript抽象緊密耦合）。這個(gè)模型之所以存在，只不過是因?yàn)樗苡枚选脑O(shè)計(jì)的角度來看，它是一個(gè)扭曲的奇跡，而不是優(yōu)美的軟件。
即使是未來的Web應(yīng)用程序，傳統(tǒng)Web的觀點(diǎn)也依然會(huì)存在于適合的地方，比如那些以內(nèi)容為主的網(wǎng)站（科技文章網(wǎng)站、亞馬遜產(chǎn)品目錄等）。這些網(wǎng)站沒有理由重新發(fā)明輪子、自定義渲染過程，并重新解決可用性的難題。但在未來，這些網(wǎng)站的行為不再是Web內(nèi)容的標(biāo)準(zhǔn)。
相反，應(yīng)用程序模型會(huì)完全打破今天的HTML/CSS抽象的桎梏。這種變化會(huì)讓開發(fā)者回到一個(gè)完全自由但支離破碎的世界，他們需要從大量的語言和UI模型中做出選擇。如果說過去的歷史有何意義，那就是世界比我們想象得更近。
本文來源于：CSDN
https://blog.csdn.net/csdnnews/article/details/119047436
英文原文：https://medium.com/young-coder/the-future-web-will-canvas-rendering-replace-the-dom-847be872884c
往期推薦
最后
歡迎加我微信，拉你進(jìn)技術(shù)群，長期交流學(xué)習(xí)...
歡迎關(guān)注「前端Q」,認(rèn)真學(xué)前端，做個(gè)專業(yè)的技術(shù)人...
