前端開發桌面應用，一直都在做一道選擇題。
想要開發簡單、生態成熟，選 Electron。代價是應用裡直接塞進一套 Chromium + Node.js，安裝包、記憶體和啟動速度都很難真正輕下來。
想要體積更小、效能更好，選 Tauri。它不再捆綁完整的 Chromium，改用系統自帶的 WebView，但本質上依然是：
HTML + CSS + JavaScript
↓
系統 WebView
↓
Rust 原生能力
現在，Vercel Labs 又給出了第三個答案。
專案叫 Native SDK。
它直接繞開瀏覽器、WebView 和 JavaScript 引擎，用一套類似前端模板的 .native 語法寫介面，再用 Zig 處理狀態和業務邏輯，最終由自研渲染引擎，把像素直接畫進系統視窗。
官方給出的數據也很誇張：
完整應用：小於 6 MB
啟動到首幀：約 100 ms
內建瀏覽器：0
JavaScript 引擎：0
執行時直譯器：0
Vercel Labs 這次，真把桌面應用的桌子掀了。
Electron 為什麼越來越重？
Electron 最大的優勢，前端開發者都懂。
Vue、React、Svelte 隨便選，HTML、CSS、JavaScript 直接寫。瀏覽器裡能跑的東西，基本都能搬進桌面應用。
它的架構也非常直接：
前端頁面
↓
Chromium
↓
Node.js
↓
Windows / macOS / Linux
這也是 VS Code、Discord、Slack 選擇它的原因：
開發效率高、平臺差異小、Web 生態完整。
但問題同樣來自這套架構。
每個應用都要帶上一套瀏覽器執行環境。即使你只是做一個簡單的 Markdown 編輯器、檔案工具或者狀態列應用，也需要背著 Chromium 和 Node.js 一起啟動。
應用越來越大，記憶體佔用越來越高，啟動速度也很難真正做到原生等級。
簡單來說，Electron 最大的優勢是瀏覽器，最大的負擔同樣也是瀏覽器。
Tauri 已經很輕，但還沒有離開 WebView
Tauri 的思路聰明很多。
它沒有把完整的 Chromium 打進安裝包，而是直接呼叫作業系統提供的 WebView：
Vue / React / Svelte
↓
HTML + CSS + JavaScript
↓
系統 WebView
↓
Rust
所以，Tauri 應用通常比 Electron 小很多，後端能力也可以交給 Rust，安全性與效能都有明顯提升。
對於現有前端專案來說，遷移成本也比較低。只要最終能夠編譯成 HTML、CSS 和 JavaScript，基本都可以塞進 Tauri。
但它依然繞不開 WebView。
Windows 主要使用 WebView2，底層基於 Edge Chromium；macOS 使用 WKWebView；Linux 則依賴 WebKitGTK。
不同平臺的瀏覽器版本、渲染結果與能力支援，仍然可能存在差異。
所以，Tauri 解決了捆綁完整瀏覽器太重的問題，卻沒有徹底離開瀏覽器渲染。
Native SDK 更激進。
Native SDK：介面直接編譯進應用
Native SDK 預設使用兩種檔案：
src/app.native
src/main.zig
.native 負責介面：
<column gap="12" padding="16">
<row gap="8" main="center" cross="center" grow="1">
<button variant="secondary" on-press="decrement">-</button>
<text>{count}</text>
<button variant="primary" on-press="increment">+</button>
</row>
<status-bar>count: {count}</status-bar>
</column>
看起來是不是很熟悉？
有元件、有屬性、有事件、有資料綁定，整體寫法非常接近 HTML 和現代前端框架的模板語法。
但它不會生成 DOM，也不會交給瀏覽器執行。
建置時，.native 介面會直接編譯進可執行檔，由 Native SDK 自己的引擎完成佈局、繪製和事件處理。
發佈後的應用不需要攜帶：
・瀏覽器
・WebView
・模板解析器
・腳本直譯器
・JavaScript 引擎
業務邏輯則寫在 Zig 中：
pub const Msg = union(enum) {
increment,
decrement,
reset,
};
pub const Model = struct {
count: i64 = 0,
};
pub fn update(model: *Model, msg: Msg) void {
switch (msg) {
.increment => model.count += 1,
.decrement => model.count -= 1,
.reset => model.count = 0,
}
}
整個狀態模型很簡單：
使用者操作
↓
發送 Msg
↓
update 修改 Model
↓
重新計算介面
熟悉 Redux、Elm、Pinia 或者單向資料流的前端開發者，基本一眼就能理解。
介面只能讀取狀態和發送訊息，不能在不同元件裡隨意修改資料。所有狀態變化都集中在 update 中，偵錯、測試和 AI 生成都會更加穩定。
6MB、100ms，優勢有多明顯？
Native SDK 官方展示的多個完整應用，發佈二進位檔都沒有超過 6 MB：
Calculator：3.6 MB
Markdown Viewer：3.5 MB
Notes：3.5 MB
Soundboard：5.7 MB
System Monitor：3.7 MB
在 macOS ARM64 環境下，這些範例從行程啟動到第一幀顯示，溫啟動時間約為 71–131 ms。
一個完整的 Markdown 編輯器範例，二進位檔只有 3.4 MB。
原因很直接：
沒有 Chromium
沒有 Node.js
沒有系統 WebView
沒有 JavaScript 引擎
沒有執行時模板直譯器
發佈產物主要就是：
你的業務邏輯
+
Native SDK 渲染引擎
+
系統原生框架
對於檔案工具、桌面用戶端、效率工具、Markdown 編輯器、資料庫管理工具、系統監控、內部工作臺這類應用，這種體積和啟動速度確實很有吸引力。
當然，這些數據來自專案方在指定設備和範例應用上的測試，不能直接得出「比 Electron 快幾十倍」的結論。
兩者提供的執行環境、瀏覽器能力和生態規模，本身就不在同一個量級。
但有一點可以確定：
當應用不再攜帶瀏覽器執行時，體積和啟動速度自然會輕很多。
Electron、Tauri、Native SDK 怎麼選？
三套方案的技術路線已經非常清楚：
方案：Electron｜UI 技術：HTML / CSS / JS｜執行環境：Chromium + Node.js｜最大優勢：生態成熟，相容性強｜主要代價：包體和資源佔用較高
方案：Tauri｜UI 技術：HTML / CSS / JS｜執行環境：系統 WebView + Rust｜最大優勢：體積小，可複用前端專案｜主要代價：仍受 WebView 和平臺差異影響
方案：Native SDK｜UI 技術：.native + Zig｜執行環境：自研原生渲染引擎｜最大優勢：無瀏覽器、體積小、啟動快｜主要代價：生態早期，需要學習 Zig
Electron 依然適合複雜 Web 產品遷移，以及高度依賴瀏覽器生態的應用。
Tauri 適合希望繼續使用 Vue、React，同時降低安裝包和資源佔用的團隊。
Native SDK 瞄準的是另一類專案：
既想保留宣告式 UI 的開發效率，又想真正擺脫瀏覽器執行時。
它沒有要求開發者回到繁瑣的 AppKit、Win32 或 GTK，也沒有繼續把介面塞進 WebView，而是在兩者之間重新造了一層。
前端開發者怎麼快速上手？
安裝非常簡單，直接使用 npm：
npm install -g @native-sdk/cli
建立專案：
native init my_app
cd my_app
native dev
執行完成後，一個真實的系統視窗就會打開。
專案預設結構也很乾淨：
src/app.native # 介面、佈局、綁定、事件
src/main.zig # 狀態和業務邏輯
src/tests.zig # UI 測試
app.zon # 應用配置、權限、視窗、打包資訊
assets/icon.png # 應用圖示
開發過程中修改 src/app.native，視窗會自動更新，並盡量保留目前狀態。
程式碼寫錯時，舊介面不會直接崩潰，還會回傳具體的檔案、行號和列號。
檢查專案：
native check
執行測試：
native test
建置發佈版本：
native build
封裝應用：
native package --target macos
native package --target windows
native package --target linux
CLI 還會處理 SDK 路徑和匹配版本的 Zig 工具鏈。
開發者不需要上來就維護複雜的 build.zig。專案真的需要自訂建置時，再透過 native eject 接管完整建置檔案。
對於前端開發者來說，這套體驗非常熟悉：
安裝 CLI
↓
初始化專案
↓
啟動開發伺服器
↓
修改介面
↓
自動更新
↓
建置封裝
只是這一次，最終跑起來的已經不是網頁。
五個平臺，一套執行模型
Native SDK 目前已經覆蓋：
macOS
Windows
Linux
iOS
Android
桌面端是目前最成熟的部分。
macOS
macOS 是目前支援最完整的平臺，使用 Metal 呈現畫面，同時接入系統捲動效果、選單、托盤、彈出視窗和輸入法。
Windows 和 Linux 已經可以執行、測試和封裝完整應用，不過目前主要使用 CPU 軟體渲染，GPU 渲染後端仍在完善。
其中，Linux 暫時沒有系統托盤支援，Windows 和 Linux 的部分系統能力也沒有 macOS 完整。
行動端同樣已經打通建置鏈路：
native dev --target ios
native dev --target android
native package --target ios
native package --target android
iOS 可以生成完整的 Xcode 專案，Android 可以生成完整宿主專案和偵錯 APK。
開發者不需要在專案裡額外維護 Swift、Kotlin 或 Java 宿主程式碼。
但需要注意，iOS 和 Android 目前仍是實驗性支援，主要在模擬器環境中驗證，工具鏈、API、GPU 渲染和真機工作流程都還在繼續完善。
所以，現在用它做桌面工具已經很有討論價值，直接拿去替換成熟的 Flutter 或 React Native，還太早。
它甚至是給 AI Agent 準備的
Native SDK 最特別的地方，可能還不是 6 MB。
它直接把 AI 自動化能力做進了執行時。
Agent 可以讀取正在執行的應用介面，檢視無障礙樹，尋找按鈕，輸入文字，點擊元件，驗證狀態，錄製操作，並生成確定性的截圖。
native automate wait
native automate snapshot
native automate screenshot
專案還提供官方 Agent Skills：
npx skills add vercel-labs/native
安裝之後，Claude Code、Codex 等 Agent 可以獲得與目前 Native SDK 版本匹配的開發說明。
Agent 寫完介面後，還能直接啟動應用、操作視窗、驗證結果，再回頭修改程式碼。
這套閉環很關鍵：
AI 生成介面
↓
編譯執行
↓
讀取真實視窗
↓
點擊和測試
↓
發現問題
↓
自動修改
以前，AI 寫桌面應用，往往只能保證程式碼「看起來能跑」。
Native SDK 想讓 Agent 真正看到自己做出來的應用。
它甚至可以透過元件來源資訊，定位某個按鈕來自哪個 .native 檔案、哪一行程式碼，再自動完成修改。
這才是真正面向 AI Agent 的應用開發鏈路。
前端桌面開發，終於出現了第三條路
過去做桌面應用，前端開發者的選擇並不多。
要麼接受 Electron 的體積和資源佔用，換取成熟生態與極低的上手成本；要麼使用 Tauri，保留 Web 技術棧，再透過系統 WebView 和 Rust 換取更輕的應用。
Native SDK 選擇了一條更激進的路線：
保留宣告式 UI
保留元件化開發
保留資料綁定
保留熱更新
保留前端熟悉的開發體驗
然後，刪掉瀏覽器。
它目前仍處於 pre-1.0，API 會繼續變化，生態也遠遠無法和 Electron、Tauri 相比。
Windows、Linux 和行動端的渲染能力，同樣需要繼續完善。
但這個方向已經足夠有意思。
一個不到 6 MB、約 100 ms 啟動、支援五個平臺，還能讓 AI Agent 直接操作和測試的原生應用框架。
這一次，Electron 和 Tauri 的對手，真的來了。
Native SDK 官網：https://native-sdk.dev/