Google最近決定使用HTML的<canvas>來渲染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模型中做出選擇。如果說過去的歷史有何意義，那就是世界比我們想象得更近。
