WebAssembly 讓瀏覽器編輯變桌機級

這篇拆 Text Control 的 WebAssembly 文件編輯思路，順手給你一份可直接貼進團隊的架構模板。

我做文件編輯器做久了，最怕那種「看起來很順，實際上很卡」的方案。WebSocket 我也玩過一輪，伺服器跑真正的引擎，瀏覽器只負責收發事件。能用，真的能用，但總有一點彆扭：一個字一個字打進去，像是在遠端操控一台機器，不像是在編輯文件。

後來我看了 Text Control 的文章 Beyond WebSockets: A Glimpse into the Future of Document Editing with WebAssembly，作者是 Bjoern Meyer。他們不是要把舊架構整個砍掉，而是把 WebAssembly 當成另一個執行目標，讓文件引擎更靠近瀏覽器端。這件事我一開始還以為只是包裝話術，結果越看越像真的在解一個老問題。

因為文件編輯這東西，從來不是「做個 rich text box」就結束。版面、換行、字型、游標、列印輸出，任何一個地方飄掉，使用者都會直接覺得你在騙他。Text Control 這篇的價值，不在於它講了 Wasm 多潮，而是它把控制權這件事講得很清楚。

他們不是在追求輕量，是在追求控制

Rather than simplifying document editing for the web, we brought the full document processing engine to the server and connected it to the browser via WebSockets.

翻譯一下就是：他們沒有把文件編輯簡化成「網頁版差不多能用」，而是把完整引擎留住，再用瀏覽器去接它。這個思路很老派，但我反而覺得對。因為文件編輯最怕的不是功能少，是規則不一致。

我以前也踩過這種坑。團隊一開始都說要做「Word-like editing」，結果底層卻用 contenteditable 硬撐。前面 demo 看起來沒事，等到真的碰到縮排、頁尾、表格、跨頁，就開始亂。那時候你才會發現，問題不是 UI 不夠漂亮，是整個文件模型根本不穩。

Text Control 的做法很明白：瀏覽器不是 truth source，伺服器才是。瀏覽器只是互動層，真正的文件狀態、版面計算、輸出規則還是要有一個核心掌握住。這種架構很像老司機開車，不花俏，但知道哪裡不能亂改。

實操寫法我會這樣做：

• 先定義你的編輯器到底是「文件系統」還是「富文字輸入框」。兩者不要混。
• 如果你在乎版面一致性，就把文件模型集中管理，不要讓前端自己發明規則。
• 瀏覽器負責互動，伺服器負責真相，這條線先畫清楚。

我看過太多團隊把「前端自治」當成美德，結果渲染規則到處長歪。文件產品不是聊天框，不能靠感覺撐。

WebAssembly 把瀏覽器從 UI 層變成執行環境

WebAssembly 的意思很直白：原生程式和函式庫可以直接在瀏覽器裡跑。Text Control 的說法也很務實，他們把 C++ 程式編譯成緊湊的 binary，讓它在現代瀏覽器裡安全又有效率地執行。

這句話翻成白話就是，瀏覽器不一定只能當「畫面容器」。它也可以承接一些真正吃算力的工作。像文件版面計算、游標移動、局部重繪、即時排版，這些東西如果每一步都丟回伺服器，延遲感會很明顯。

我自己很在意這點，因為文件編輯的卡頓不是那種「等一下就好」的卡頓，是會直接破壞手感的卡頓。你按一個鍵，游標晚半拍；你拖一段文字，畫面跟不上；你改一個段落，整頁重算。使用者不會說「你的 round trip 太多」，他只會說「很難用」。

Wasm 的好處，不是什麼神奇魔法，而是它把一部分決策拉近了使用者。少一點來回，就少一點抖動。尤其在網路品質不穩、VPN 很爛、企業內網很愛抽風的情境，這種差異很真實。

實操寫法我會這樣切：

• 先找出你的熱路徑：鍵入、選取、排版、頁碼、輸出。
• 能在本地即時算的，就不要每次都問伺服器。
• 伺服器留給儲存、權限、審計、協作、重型輸出這些真正該在後端的事。

很多人優化文件編輯都只盯 API latency，結果整個互動模型還是靠遠端回應。那不是優化，是在擦桌子。

他們賭的是一致性，不是新鮮感

Documents should look the same, no matter where they are processed.

這句我覺得才是整篇的核心。其他都是手段，這句才是目的。

翻譯一下就是：Text Control 不想把 WebAssembly 包成一個新潮賣點，他們在意的是同一份文件，不管跑在伺服器還是瀏覽器，結果都要一樣。版面一樣、換行一樣、字型一樣、頁面分割一樣。這才叫文件產品，不然只是會輸入文字的網頁。

我很買單這種思路。因為真正麻煩的從來不是「做出一個看起來像編輯器的東西」，而是「讓它在不同環境下都不走樣」。使用者對這種差異超敏感，哪怕他說不出是哪裡怪，他也知道怪。

我以前做過一個法務文件系統，桌機匯出正常，瀏覽器編輯後的行距卻會偷偷變掉。看起來只差一點點，但對合約模板來說，那一點點就是事故。從那次之後我就很不信任「大概差不多」這種說法。

實操寫法我會這樣做：

• 先定義一份 canonical document model，所有 runtime 都要服從它。
• 同一份文件要在瀏覽器、伺服器、匯出三條路徑都測。
• 不要只看互動速度，還要看輸出一致性。

如果你的產品是 business document software，rendering 只要有一點漂，support ticket 就會像雪球一樣滾。

他們不選 Blazor，是因為層數真的很重要

文章裡有一段在問：為什麼不直接用 Blazor 和 .NET runtime 跑在瀏覽器裡？他們的答案很直接：效能、渲染精準度、還有對編輯體驗的控制。

這句話翻白話就是，他們不想在瀏覽器和文件引擎之間再多塞一層抽象。不是說 Blazor 不好，而是如果你的核心問題是文件 fidelity，那每多一層翻譯，就多一層漂移風險。

我不反對 Blazor，我也不反對任何合理的前端 runtime。問題是工具要對題。你如果是在做一般 UI 組件、後台頁面、表單流程，Blazor 很可以。但如果你在做的是頁面級文件排版，層數越多，越容易把字型、量測、選取、重繪搞歪。

我自己的判斷很簡單：只要產品有「像 Word 一樣」這種需求，我就先懷疑所有會增加轉譯層的東西。不是不能用，是要非常小心。

實操寫法我會這樣判斷：

• 先看你要的是 UI composition，還是 pixel-level fidelity。
• 如果你需要極準的排版，就少一點 runtime 轉譯。
• 不要因為某個框架很熱，就把核心引擎交出去。

這不是框架鄙視鏈，這是工程現實。層數一多，責任就開始散掉。

掌握 rendering pipeline 才是真的在做產品

Text Control 也提到，他們想保留對 rendering pipeline 的掌控，不想把核心交給第三方框架或圖形引擎，像 Skia 這類工具雖然強，但不是每個場景都適合當最終依賴。

翻譯一下就是：他們想知道從文件資料到畫面像素，中間每一步怎麼走。這很無聊，但這就是文件產品的命脈。因為你只要不能完整解釋渲染流程，就很難 debug。

我看過很多團隊一開始都很樂觀，說「先接標準 graphics stack 再說」。半年後開始出現字型 fallback 不一致、瀏覽器差異、測試環境和正式環境排版不一樣。最後大家都在猜，沒人真的能說清楚是哪一層在搞鬼。

Text Control 的路線比較狠：核心引擎自己掌握，編譯到目標平台，規則不要亂。這種做法很 boring，但很值錢。因為 boring 的東西通常比較能活。

實操寫法我會這樣做：

• 把編輯器的 rendering dependency 全列出來，問自己每個是不是你真的能控制。
• 版面計算、字型處理、頁面切分，盡量做成 deterministic，而不是靠黑盒。
• 把 font、pagination、measurement 寫進產品規格，不要只寫在工程筆記裡。

如果你在做商務文件軟體，「大概能看」通常只是你還沒碰到第一個客訴。

企業團隊現在該怎麼看這件事

這篇文章最實際的地方是，它沒有裝作 WebAssembly 會把既有架構全部推倒重來。它其實是在說：WebSocket 模型還是很多部署場景的基礎，但 WebAssembly 讓 browser-first 的執行方式多了一條路。

這個觀點我很認同。因為現實世界不是二選一。很多團隊需要伺服器中心的控制，也需要更靠近使用者的本地執行；有些甚至兩個都要。你不能拿一把錘子去敲所有問題。

所以我現在看文件編輯架構，不會先問「WebSocket 還是 WebAssembly？」我會先問：文件管線裡哪些步驟必須本地化，哪些可以放伺服器，哪些又一定要有中心化控制。這樣問，才比較像在解題，不像在站隊。

實操寫法我會這樣落地：

• 把 edit、render、validate、persist、export、sign 這幾段拆開看。
• 標出哪些步驟需要低延遲，哪些步驟需要合規或審計。
• 先接受混合架構，不要硬逼一個 runtime 做全部。

我喜歡這種框架，因為它逼團隊面對 tradeoff。很多人嘴上說要 modernize editor，其實根本沒講清楚自己要解的是哪個痛點。

可抄的模板

# 文件編輯器架構決策備忘錄

## 問題
我們需要一個瀏覽器文件編輯器，同時保住版面一致性、即時編輯手感、以及跨環境輸出穩定性。

## 我們要優先的東西
- WYSIWYG 一致性
- 低延遲編輯體驗
- 可預測的渲染結果
- 跨平台文件 fidelity
- 清楚的 rendering pipeline 擁有權

## 目前架構
- 瀏覽器 UI 負責互動
- 伺服器持有文件引擎
- 瀏覽器與伺服器透過 WebSocket 溝通
- 伺服器是文件狀態的 source of truth

## 什麼情況適合 WebAssembly
如果編輯器需要以下能力，就評估 Wasm：
- 在瀏覽器端做更多排版與渲染工作
- 降低鍵入、游標移動、選取的 round trip
- 在網路不穩時維持可用性
- 把原生引擎編譯進瀏覽器 runtime
- 對渲染精準度有很高要求

## 什麼情況 WebSocket 還是合理
如果你需要以下條件，就保留伺服器中心模型：
- 文件處理要集中控管
- 既有生產環境已經圍繞伺服器引擎建好
- 需要更容易做權限、審計、合規
- 協作邏輯本來就屬於 backend
- 現有引擎已經能滿足 fidelity 要求

## 決策規則
如果你比起縮小 client 複雜度，更在意 fidelity 和控制權，就把核心邏輯留在你最能掌握的執行環境裡。若瀏覽器真的需要承擔更多本地工作，就把 WebAssembly 當成候選執行目標，而不是行銷口號。

## 實作清單
- [ ] 找出編輯與渲染的 hot path
- [ ] 量測鍵入、選取、排版、頁碼的延遲
- [ ] 定義單一 canonical document model
- [ ] 測試 browser、server、export 三條路徑的一致性
- [ ] 審查 rendering dependency 與字型行為
- [ ] 決定哪些邏輯必須留在 server
- [ ] 針對最吃效能的 client 端操作做 Wasm prototype

## 可直接拿去問團隊的評估題
我們正在評估文件編輯器要維持 WebSocket 為主的伺服器中心架構，還是把核心渲染與編輯邏輯移到 WebAssembly。請從效能、控制權、維護成本、渲染一致性四個面向比較，最後給出一個分階段的架構建議。

這段模板的好處，是它逼你真的做決策，不會只停在「我們應該升級一下」這種空話。你拿去開會，團隊就得回答：到底要解哪個問題？要把哪段 logic 放哪裡？

而且它也保留了現實感。WebAssembly 如果只是幫你把熱路徑拉近瀏覽器，後端還是負責驗證、保存、權限，那就老實寫進去。不要演成一個 runtime 能解所有事，這種劇本通常都很貴，也很容易爛尾。

原始來源是 Text Control 的文章 https://www.textcontrol.com/blog/2026/06/10/beyond-websockets-glimpse-future-document-editing-webassembly/，作者是 Bjoern Meyer。我上面拆的是它的思路，模板和落地問法是我自己整理的。