??每周跟蹤AI熱點新聞動向和震撼發展 想要探索生成式人工智能的前沿進展嗎？訂閱我們的簡報，深入解析最新的技術突破、實際應用案例和未來的趨勢。與全球數同行一同，從行業內部的深度分析和實用指南中受益。不要錯過這個機會，成為AI領域的領跑者。點擊訂閱，與未來同行！ 訂閱：https://rengongzhineng.io/

瀏覽器的發展正處于一個奇怪的時期。盡管WebAssembly在服務器端取得了顯著成功，但客戶端的體驗在過去十年間幾乎沒有根本改變。

不少技術愛好者認為，通過WASM訪問原生Web API已經不再是難題，只需極少的JavaScript“膠水”代碼即可實現。但關鍵問題并不是“是否可以”訪問DOM，而是“為什么還要”訪問它。如今，DOM似乎成了唯一的選擇，但實際上，是時候讓DOM和它那一系列錯綜復雜的API“退休”了。

“文檔”模型的真實面貌

鮮有人真正意識到DOM有多龐雜。在Chrome中，document.body對象已包含超過350個屬性，這還不包括其style屬性中660個CSS屬性。屬性與方法的邊界模糊不清，有些屬性不過是隱藏的setter方法；一些getter方法甚至會觸發即時的頁面重排。此外，諸如onload、onmouseover等早期事件處理器仍被保留在API中，盡管幾乎無人使用。

DOM并不輕盈，反而愈加臃腫。是否能感知這一點，取決于開發者是在制作網頁，還是在開發Web應用。如今多數開發者已盡量避免直接操作DOM，雖然仍有人將“純DOM”視為優于現代JS組件框架的“正統方式”。而諸如innerHTML這樣的聲明式功能早已無法滿足現代UI開發的需求。DOM存在太多實現方式，卻沒有一種是令人滿意的。

Web Components：錯失良機的原生組件方案

Web Components本應成為Web平臺上原生組件化的標準，但其出場時機過晚，加之API設計生硬，使其難以流行。其中Shadow DOM的引入更是帶來了嵌套與作用域的復雜性，使許多開發者望而卻步。其支持者往往語氣近似辯解。

DOM的根本性問題，在于其源自SGML/XML的遺產，使得一切都變成了“字符串類型”——即所謂“stringly typed”。而React等框架雖然語法上看似XML，實際上并無此限制。如今開發者早已學會，不應把狀態保存在DOM中，因為它無法勝任。

HTML十年如一日的停滯

HTML本身的問題更是根深蒂固。在過去十至十五年中，其結構幾乎未曾改變。除了ARIA（無障礙訪問）之外，鮮有實質性進展。語義化HTML未能兌現其承諾——比如至今沒有 <thread> 或 <comment> 標簽，即使這些已成為常見內容結構。語義化規范內容模糊，令人困惑。

HTML似乎始終執著于紙質出版物的模型，遲遲不愿擁抱超文本的本質，也未能給予用戶清晰且可信的規則。HTML的管理早已從W3C轉移至WHATWG，即各大瀏覽器廠商聯盟，但他們迄今未能提供明確的未來愿景，僅在邊緣上不斷堆砌功能補丁。

CSS：結構混亂的布局系統

CSS的名聲也不甚美好，但大多數人并不能準確說出其問題所在。問題的根源在于心智模型的錯位——許多人將其視為約束求解器（constraint solver），這是誤入歧途。

例如，使用百分比高度時，開發者可能以為設置兩個50%高度的子元素，父容器就會被垂直平分。但由于CSS的布局流程是自內而外的（inside-out），在不知道父元素高度的前提下，這樣的設置往往會被忽略，或者內容溢出。這是由于CSS并不會像某些布局引擎那樣進行回溯或推理，而是“自上而下傳約束，再自下而上傳尺寸”。

在構建應用框架時需要outside-in的布局，而HTML默認偏向inside-out的文檔式布局。這就是為什么垂直對齊在CSS中“很難”。

Flexbox的權衡與代價

使用display: flex確實可以解決上述問題。它允許合理劃分空間、定義彈性增長/收縮。但這也引入了額外復雜度：每個子元素需先測量“自然尺寸”，再根據空間調整布局——這相當于布局過程要執行兩次。對于嵌套結構甚至可能引發遞歸的計算爆炸，雖然在現實中很少出現。

為避免遞歸依賴，開發者需使用如contain: size、will-change等新CSS屬性，以阻斷DOM中流動的全局約束。這類機制透露了CSS中潛在的“分層”特性，但這些設計顯然不是從頭構建的，而更像是補丁堆疊。

DOM和CSS的原罪

在CSS中，繼承（inheritance）僅適用于少數文字樣式，如字體大小，而大多數屬性（如邊框）并不會繼承。這揭示了CSS其實融合了兩種截然不同的系統：一是基于繼承的富文本樣式系統；二是基于嵌套與包含的布局系統。兩者共用一套語法，卻行為不一致。將它們合并，注定是錯誤的。

此外，早期關于相對字體單位（如em）的設計，也已被邏輯像素與設備像素的概念取代，后者更符合用戶直覺。

SVG：強大但笨重的圖形系統

SVG作為可嵌入的矢量圖形語言，提供了強大的圖形功能，如路徑、漸變、遮罩等，甚至支持多邊形命中測試，這些CSS做不到。但SVG并非CSS的子集，也不是其超集。兩者存在許多細節差異，例如變換矩陣的處理邏輯不同。SVG擁有自己的“怪癖”，例如必須將所有坐標序列化為字符串。

SVG與CSS的融合，反而造成了API設計的混亂。在許多情況下，開發者需在HTML、CSS與SVG之間權衡取舍，盡管它們本質上都作用于同一圖形棧。

遺憾的API設計決策

Web平臺中許多功能，都因版本1的設計過于倉促而停滯不前。例如：

• text-ellipsis 僅能處理單行文本，無法應用于段落；

• position: sticky 實用但常常出現詭異行為；

• z-index 缺乏相對層級控制，造成混亂的“+1/-1”戰爭。

這些問題反映出早期API設計中缺乏對長期演進的思考，而后續也未能通過模塊化與可組合的方式解決。

Canvas：一個笨拙的“重繪”出口

近年來出現的“HTML in Canvas”提案，試圖將HTML內容繪制到Canvas中，以獲得完全的視覺控制。然而，這種方式本質上是將DOM強行嵌入Canvas中，為了保留布局與可訪問性，最終反而限制了用途。

例如，若要繪制一個旋轉立方體，開發者需手動綁定命中檢測區域，并響應繪制事件。這種做法無法支持3D交互，僅能提供2D層面點擊檢測。更為關鍵的是：開發者必須接管元素所有交互責任，只為自定義其渲染方式。

這種Canvas方案，看似“可編程”，實則不過是無奈之舉。當開發者想要在UI中實現DOM無法提供的功能（如內容虛擬化、定制交互、特殊視覺效果），卻又不得不借助笨拙的Canvas與DOM組合，這無疑是對系統架構的一種拷問。

真正的出路：向下開放底層能力

Canvas并非無解，但它缺乏對系統字體、文本排版API與UI工具的原生支持。開發者甚至需自行實現斷詞、換行與測量功能，僅為實現“包裹文本”。

真正的解決方案，應是開放底層圖形系統，而非繼續在HTML/CSS/SVG之上堆砌補丁。這種“自上而下”的改造注定難以奏效。取而代之的應是“向下暴露原始能力”，讓用戶空間與底層邏輯一致，這正是良好內核設計的核心原則。

例如，Use.GPU 項目展示了基于WebGPU構建的HTML-like布局渲染系統，其使用Flex模型實現高效而簡潔的UI布局——無DOM、無CSS，僅使用可組合的布局組件與著色器，定位直觀、行為明確，甚至實現了垂直居中這種CSS難題。

這一系統展示了：無需HTML/CSS/SVG的沉重歷史包袱，僅靠簡潔的樹狀視圖與渲染結構，即可完成DOM 90%的任務。

下一步該往哪里走？

從根本上重新設計DOM，去除所有歷史遺留，可以為瀏覽器帶來多線程、多來源、異步友好的全新架構。現代瀏覽器引擎已是多進程架構，但它們的設計仍然受限于1990年代的DOM模式。

另一些實驗性瀏覽器項目，如Servo或Ladybird，也許能提出更清晰的替代方案。它們實現新功能時無需顧及歷史兼容性，因此具備探索新范式的空間。

開發者應開始關注這些新興技術，并對現有HTML/CSS/DOM系統保持警惕。重新思考UI工具鏈與平臺基礎設施，是時候了。因為，舊的DOM不再適應現代Web應用的需求——而新一代的Web，不應再背負它的遺產。