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