我們將 Rust WASM 解析器改用 TypeScript 重寫後，速度提升了 3 倍

背景

OpenUI 團隊分享了他們將原本以 Rust 編寫並編譯為 WASM 的解析器，改用 TypeScript 重寫後效能大幅提升三倍的經驗。該解析器主要用於處理大型語言模型串流輸出的自定義 DSL 並轉換為 React 組件，開發團隊發現效能瓶頸並非源於 Rust 的運算速度，而是頻繁跨越 WASM 與 JavaScript 邊界所產生的序列化與記憶體複製成本。

社群觀點

針對這篇技術分享，Hacker News 的討論主要聚焦於「語言選擇」與「演算法優化」之間的權衡。許多評論者指出，標題雖然強調 TypeScript 勝過 Rust，但實際上最大的效能躍進來自於開發團隊在重寫過程中，將原本 O(N²) 的串流解析邏輯改為具備快取機制的 O(N) 增量解析。社群普遍認為這是一個典型的「第二次重寫紅利」，開發者在第二次實作時往往能修正初版的架構缺陷並套用更優的演算法，這種進步往往與程式語言本身的特性無關。

部分資深開發者對測試方法提出了質疑，認為在瀏覽器環境中使用中位數進行微秒級的基準測試可能不夠精確，因為 JavaScript 引擎內建的計時攻擊防禦機制會影響精準度。此外，關於 WASM 邊界成本的討論也相當熱烈。有留言指出，使用 JSON 字串作為傳輸媒介在 V8 引擎中已經過高度優化，其效率往往高於透過工具逐一將 Rust 結構體轉換為 JavaScript 物件。這反映出一個技術共識：除非是計算密集型且鮮少需要與 JavaScript 堆疊互動的任務，否則 WASM 的通訊開銷很容易抵銷掉原生代碼的執行優勢。

另一派觀點則為 Rust 辯護，認為這並非 Rust 的失敗，而是架構設計的問題。如果能利用共享緩衝區而非序列化來處理數據，或許能保留 Rust 的效能優勢。然而，也有人反駁這正是 TypeScript 的優勢所在，因為它與 V8 引擎原生整合，能避免所有跨語言邊界的數據轉換。討論中亦有開發者幽默地提到，或許一年後當 TypeScript 版本出現維護瓶頸時，又會有第三方開發者宣稱用 Rust 重寫能再獲得三倍效能，這反映了軟體開發中不斷重構與優化的循環本質。

延伸閱讀

在討論串中，有開發者分享了針對 Rust WASM 到 JavaScript 序列化效能的深入研究，探討了如何改進現有工具的轉換效率。另外，也有留言提到 OpenUI 這個名稱與 W3C 的標準化社群重名，建議讀者關注負責 HTML 彈出視窗與自定義選擇框標準化的 Open UI 官方網站。對於文件系統感興趣的讀者，則推薦了基於 Fumadocs 構建的現代化文件設計。