Diff 渲染工程：反向 Sticky 虛擬化、2.4 GB → 1.15 GB 記憶體優化與捲軸錨定
pierre.computer · 2026-05-29
Diff viewer 在 Web 端渲染大型補丁時，面臨三個難題：捲軸時 DOM 更新導致空白閃爍、解析 Linux v6→v7 這樣的大型 patch 記憶體暴增至 2.4 GB、以及虛擬化後捲軸位置漂移。pierre.computer 近日公開一篇技術深度文章，逐一解析這些問題的實際解法。
反向 Sticky 虛擬化
傳統 virtual list 在每個 requestAnimationFrame 更新 DOM 絕對位置，快速捲軸時出現空白閃爍。Inverse Sticky Technique 利用負 sticky offset，讓渲染區域底邊固定在 viewport 底部：
bottom_offset = (contentHeight - viewportHeight) * -1
/* sticky 合成層由瀏覽器原生管理，不依賴 rAF */此方法完全依靠瀏覽器合成層，Chrome/Firefox 性能顯著優於 rAF 方案。Safari 因 sticky 合成性能較弱、rAF 上限 60Hz，是目前主要短板。
記憶體優化：從 2.4 GB 到 1.15 GB
解析後字串會持有原始 patch 輸入的強參考。字串分離（string detachment）強制解析輸出與原始輸入脫鉤，Linux v6→v7 diff 記憶體從 2.4 GB 降至 1.15 GB，節省 52%。
- DOM Pooling：重用 Shadow DOM 容器，避免大量建立/銷毀造成的 GC 暫停
- Shared Options State：每個列表項共享 getter 而非獨立 config 物件，節省 20–30 MB
- Syntax Highlighting：推遲到 Worker LRU 快取，先渲純文字再漸進加高亮
捲軸錨定（Scroll Anchoring）
虛擬化更新 DOM 高度時，瀏覽器原生捲軸錨定常常失效。自訂錨定模型的流程：修改 DOM 前記錄錨點位置 → 重算高度 → 手動調整 scrollTop。行號定位使用二元搜尋，避免超大 hunk 的 O(n) 掃描。
已知未解問題包括水平捲軸虛擬化（minified code 場景）和 Worker 序列化的摩擦成本，文章誠實列出，供後續參考。
AI 是否正在重演前端失落的十年？
mastrojs.github.io · 2026-05-23
Alex Russell 的「前端失落的十年」指大型 JavaScript 框架把瀏覽器當編譯目標，將 HTML、CSS、無障礙等專業知識抽象化，讓通才程式設計師接手前端，卻帶來行動裝置性能退化和無障礙問題。mastro 框架作者認為 AI 生成代碼正在製造第二波結構性技術債。
漏洩抽象的重演
框架隱藏了事件冒泡、CSS specificity、無障礙 ARIA 角色等細節；AI 生成代碼同樣跳過這些細節，直接輸出「能動」的片段。文章以 Shadcn radio button 組件為例說明：框架抽象帶入的無障礙問題在 AI 時代只會更嚴重，因為 AI 並不驗證 ARIA 語意是否正確。
LLM 輸出的不確定性
相比於確定性編譯器（相同輸入必然輸出相同結果），LLM 每次執行同一個 prompt 可能產生不同代碼，這讓「可靠的代碼產生器」的定位本身就有問題。文章把 AI 生成代碼類比為「能動的初級工程師輸出」——需要人工審查，而非信任部署。
- 框架去技能化結果：「前端的前端」（HTML/CSS/a11y）和「框架工程師」兩個族群分化
- AI 去技能化結果：熟練者生產力提升，半熟練者可繞過基礎知識直接交付功能
- 共同結果：「能跑的網站」和「快速、accessible 的網站」之間的差距沒有縮小
原始來源：mastrojs.github.io