為什麼 Julia-to-WebAssembly 現在值得認真看待
Julia-to-WebAssembly 已經不是炫技展示，而是對特定類型應用可行的部署路徑；WasmTarget.jl 與 Therapy.jl 證明這條技術棧已經接近可用，團隊現在就該開始用它做真實產品。
Julia-to-WebAssembly 現在值得認真投入，因為它已經從「能不能跑」走到「能不能交付」的階段。
證據很直接：WasmTarget.jl 已經能把 176 個 Julia 函式編譯成正確的端到端 WebAssembly 輸出，涵蓋 Int32、Int64、UInt32、UInt64、Float32、Float64，並且有 2,409 個測試通過；再加上可選的 wasm-opt，二進位體積能縮小約 85% 而不改變行為。Therapy.jl 則把這個編譯能力接到真正的產品形態上，提供 signals、SSR、islands，以及每個 island 各自獨立的 WASM 模組，體積落在 1 KB 到 12 KB。這不是研究室玩具，這是部署路線圖。
第一個論點：編譯器層已經夠穩，足以作為產品基礎
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
Julia-to-Wasm 之所以長期卡關，不是因為想法不對，而是因為編譯器通常只做到「吐出一些東西」。WasmTarget.jl 做得更進一步：它直接從 Julia 的 fully inferred IR 產生 WasmGC bytecode，並把 Vector{T} 和使用者自訂 struct 對應到現代 WasmGC 型別，而不是把一切都塞進線性記憶體。這個差異很關鍵，因為高階語言進 WebAssembly 的老問題一直是妥協太多，不是 runtime 被扭曲，就是輸出根本不能用。
更重要的是，它已經不是單點成功，而是有明確覆蓋範圍。176 個函式裡，127 個走原生路徑，48 個則是針對 GC 內部或 libm 外部呼叫的 overlay 實作。這種邊界很像 CUDA.jl 和 GPUCompiler.jl 的成長方式：先切出一個可控子集，再用有針對性的補丁逐步擴張。真正有用的編譯器，不是宣稱全都支援，而是能穩定支援一個夠大的子集。
第二個論點：框架把編譯能力變成可交付產品
只有編譯器，還只是研究成果；Therapy.jl 把它變成前端交付機制。它採用類似 SolidJS 或 Leptos 的 signals 模型，但寫法是純 Julia 的函式組合，而不是重 macro 的 DSL。這不是風格問題，而是降低門檻：已經熟悉 Julia 的工程師，不必先學一套陌生模板語言，才能做出反應式 UI。語言一致性本身就是生產力。
更值得注意的是 islands 架構。靜態 HTML 負責大部分頁面，只有需要互動的局部才載入 JS 或 WASM；每個 @island 都編成獨立模組，避免「為了 hydrate 一顆按鈕就把整個應用送到瀏覽器」的浪費。若 1 KB 到 12 KB 的模組體積在真實場景中成立，這就是實際的工程優勢：它讓 Julia 參與現代 Web 發佈，而不是逼整個產品退化成全客戶端單頁應用。
第三個論點：dogfooding 和體積數據顯示這是系統工程，不是展示品
最能說服人的細節之一，是兩個 docs site 都用同一套技術棧建出來。dogfooding 不是行銷話術，而是最快暴露編譯器、框架、部署之間整合問題的方法。當文件站本身就能用這套系統渲染、hydrate、維護，代表作者已經先付過大多數實驗性技術棧最常逃避的整合成本。這就是原型和平台的分界線。
85% 的體積縮減也不是小事，因為它透露的是部署哲學，而不是單純的優化技巧。若 wasm-opt 只是把已經接近可交付的輸出再修整一次，代表 codegen 的方向本身是對的。對 Web 交付而言，體積就是延遲、快取效率、邊緣部署友善度，以及頁面到底像不像一個真正可用的互動介面。這套技術棧顯然知道這件事。
反方可能怎麼說
懷疑者的論點也很強，而且值得正面看待。Julia 一向有雄心很大、但最後卡在可攜性、runtime 複雜度或維護成本的歷史；WebAssembly 本身也還在演進，WasmGC 的成熟度不如傳統瀏覽器假設。再加上這些套件是透過 LLM coding agents 逐步建出來的，保守的工程師自然會擔心邊界案例、overlay 是否脆弱，以及長期支援能力。
還有一個產品層面的反對意見：既然 JavaScript 已經主宰瀏覽器，後端又可以直接跑 Julia，為什麼還要多一個執行目標？如果應用只是 CRUD，這條路確實過重；如果團隊沒有編譯器經驗，維護成本也可能吃掉所有收益。
但這些反對意見沒有推翻這條路，只是精準地界定了它的適用範圍。Julia-to-Wasm 不是所有 Web 應用的答案，它只需要成為一類應用的最佳答案：互動式科學工具、計算型儀表板、模擬前端，以及核心邏輯本來就寫在 Julia 裡的領域型 UI。在這個範圍內，直接從 Julia IR 編譯、映射到 WasmGC、再用 islands 發佈，並不是空想，而是可以開始交付的工程方案。
你能做什麼
如果你是工程師，不要再把 Julia-to-Wasm 當成奇觀，應該把它當成一個有條件的部署目標來評估：先做一個 island，量二進位大小，測 hydration 路徑，找出哪些程式碼依賴尚未支援的 runtime 行為；如果你是 PM 或創辦人，只在 Julia 已經是事實來源、而且瀏覽器互動確實是產品需求的地方使用它。正確做法不是把整個前端都改寫成 Julia，而是先把一個高價值、計算密集的切片送進瀏覽器，讓結果決定下一步。