Zero-native：重新思考使用 Zig 與 WebView 的桌面應用程式開發

桌面應用程式開發的格局長期以來一直在網頁技術的豐富性與原生二進位檔效能之間拉鋸。多年來，Electron 透過打包完整的 Chromium 實例與 Node.js 執行環境主導了這一領域，為開發者提供了極大的彈性，但也付出了巨大的二進位檔大小與相當的記憶體消耗。

此時 zero-native 登場，這是 Vercel Labs 的新專案，旨在彌合這個差距。透過利用 Zig 程式語言與系統原生 WebView，zero-native 承諾提供如同網頁般的開發體驗，同時表現如原生應用程式。它針對現代桌面框架的「臃腫」問題，提供通往亞兆位元組二進位檔與即時重建的道路。

核心架構：Zig + WebView

zero-native 的核心設計是一個輕量級的外殼。它不會打包沉重的瀏覽器引擎，而是預設使用 system WebView——即作業系統已內建的瀏覽器引擎。這樣的架構選擇使得最終的二進位檔保持極小，因為應用程式不需要自行攜帶渲染引擎。

主要技術優勢

• 極小二進位檔與低記憶體使用量： 透過使用 system WebView，zero-native 應用程式避免了打包執行環境的負擔，與 Electron 相比，磁碟佔用顯著減少，記憶體使用亦降低。
• 彈性網頁引擎： 雖然 system WebView 為輕量應用程式的預設，但 zero-native 允許開發者透過 CEF（Chromium Embedded Framework）打包 Chromium，以滿足跨平台需要像素完美渲染一致性的專案。
• 快速迭代： 框架利用 Zig 快速的編譯速度。開發者可以修改 bridge 指令或系統整合，並在數秒內看到結果，同時前端仍可受惠於標準的網頁熱重載。
• 無縫 C 整合： Zig 的一大特色是能直接呼叫 C 函式庫。zero-native 繼承了這點，使開發者能加入 C 標頭檔並呼叫原生 SDK、音訊編解碼器或機器學習執行環境，無需複雜的綁定產生器或「不安全」的包裝器。

「Bridge」與應用模型

為了讓網頁 UI 能作為桌面應用程式運作，zero-native 實作了 Bridge。它允許在 WebView 中執行的 JavaScript 直接與原生 Zig 程式碼通訊。這種雙向溝通使得網頁開發者能觸發系統層級的操作——例如檔案系統存取或硬體整合——這在一般瀏覽器環境中通常是無法做到的。

框架同時提供內建指令、對話框與系統匣支援，確保「原生」的感受從一開始就融入開發者的工作流程。

社群討論：什麼是「原生」？

和所有系統領域的新工具一樣，zero-native 在開發者社群中，尤其是 Hacker News，引發了熱烈的討論。大部分討論聚焦於「原生應用程式」的定義。

定義衝突

多位批評者認為使用 WebView——不論是系統提供或是自行打包——都不算「原生」。在他們看來，原生應用程式是使用作業系統原始元件（例如 SwiftUI 或 WinForms）來繪製 UI 的程式。

「我不喜歡把依賴 WebView 的應用程式稱為『原生桌面應用程式』。在我看來，原生桌面應用程式是指使用作業系統的原始元件與指令來繪製 UI。」

與 Tauri 的比較

觀察者指出 zero-native 與 Tauri 之間的高度相似性，Tauri 也使用系統 WebView 並以 Rust 為後端。這引發了關於 Zig 與 Rust 取捨的討論。zero-native 強調 Zig 的簡潔性以及缺乏借用檢查器以加速開發，但部分系統程式設計師認為這是一種缺點。

「Tauri，但缺少記憶體安全、資金、治理模式或人力維護者。」

平台特定的顧慮

雖然跨平台基礎的承諾令人向往，但有使用者指出「system WebView」是一個變動的概念。例如在 Linux 上，依賴 WebKitGTK 常被視為相較於基於 Chromium 的替代方案較不理想的體驗。

結語

zero-native 代表了一種更有效率的桌面 Web UI 發佈方式。它以精簡的 Zig 後端與系統提供的渲染器取代沉重的 Node.js/Chromium 打包，為想要擁有網頁敏捷性卻不想承受 Electron 資源負擔的開發者提供了有說服力的替代方案。雖然關於什麼算是「原生」應用程式的哲學討論仍在持續，但技術目標十分明確：降低桌面軟體發佈的成本。