Vercel 的 Native SDK 很轻，但还没到让 Electron 和 Tauri 退场的时候
这两年桌面应用开发一直在两条路之间摇摆。
一条路是 Electron，生态成熟、前端团队上手快，但大家对它的抱怨也很稳定：包体偏大、内存占用高、冷启动不够利落。另一条路是 Tauri，它把 Chromium 换成系统 WebView，再加上 Rust 后端，明显把体积和资源占用压下来了，但 WebView 本身依然会带来平台差异和能力边界。
现在 Vercel Labs 推出的 Native SDK，想走的是第三条路：不带浏览器，不依赖 WebView，也不靠 JavaScript 运行时，而是直接用自己的原生渲染引擎来画界面。
如果只看第一眼数据，这条路线确实很猛。
- 示例应用体积大约在
3.4 MB到5.7 MB - 常见启动时间在
100 ms左右，官方展示里温启动约71 ms到131 ms - 目标覆盖
macOS、Windows、Linux，同时也在尝试iOS和Android
这组数据足够吸引人，但真正值得关心的不是“它是不是更快更小”，而是：它到底解决了什么问题，又会把新的成本转移到哪里。
它和 Electron、Tauri 到底差在哪
先把三条路线摆平：
| 方案 | UI 技术 | 运行环境 | 最大优点 | 主要代价 |
|---|---|---|---|---|
| Electron | HTML/CSS/JS | Chromium + Node.js | 生态最成熟，前端复用率高 | 包体大，资源占用高 |
| Tauri | HTML/CSS/JS | 系统 WebView + Rust | 明显更轻，前端迁移成本低 | 仍受 WebView 能力和平台差异影响 |
| Native SDK | .native + Zig | 自研原生渲染引擎 | 没有浏览器包袱，启动和体积很激进 | 生态早期，需要接受新语言和新范式 |
Electron 的本质，是把一个 Web 应用和完整 Chromium 一起打包带走。它的好处一直非常清楚：团队已经会写前端，就能很快把桌面端做出来。问题也同样清楚：你获得的是一致性和生态，但要付出包体和资源成本。
Tauri 做的事情更像是“保留 Web 开发体验，同时把运行时换瘦一点”。这对很多已有前端项目来说很实用，因为页面、组件、状态管理、样式体系都还能延续。但这条路并没有绕过 WebView，本质上还是在系统提供的浏览器壳上跑。
Native SDK 这次最激进的地方，是它直接把这个壳拿掉了。
Native SDK 的核心思路，其实就是把 Web 这一层彻底绕开
它的结构大致可以理解成这样：
.native 文件
-> 声明式定义界面
Zig 代码
-> 负责状态管理和业务逻辑
Native SDK 渲染引擎
-> 直接把像素绘制到系统窗口
目标平台
-> macOS / Windows / Linux / iOS / Android
这里最重要的不是语法长什么样，而是它放弃了什么：
- 不需要浏览器内核
- 不需要系统 WebView
- 不需要 JavaScript 引擎
- 不需要传统意义上的解释型运行时
这就解释了为什么它的体积可以压得这么小，启动也能这么快。以前 Electron 和 Tauri 都在想办法“把 Web 这套东西带得更轻一点”，Native SDK 则是直接说：那我不带了。
这条路为什么会让人兴奋
因为桌面应用里确实有一大类产品，对“界面必须是 Web 技术”并没有那么执着。
比如这些场景：
- 文件处理工具
- 小型桌面客户端
- Markdown 编辑器
- 系统监控类工具
- 轻量效率工具
这类产品往往有几个共同点：
- 交互复杂度中等
- 重点是启动快、占用小、分发轻
- 不一定需要完整浏览器生态
- 更在意原生质感和执行效率
在这些场景里，Native SDK 的路线就很有吸引力。因为它不是在做“更省一点的 Web 容器”，而是在尝试把桌面应用重新拉回“更接近原生程序”的交付方式。
但它也没有神奇到可以直接宣布 Electron 和 Tauri 结束了
我反而觉得，这里最需要降温的就是标题党的判断。
Native SDK 今天再亮眼，也还没有到“让 Electron、Tauri 集体让位”的阶段，原因至少有三点。
第一，生态还在非常早期
官方现在明确把它放在 pre-1.0 阶段，这就意味着 API、工具链和最佳实践都还会继续变。一个新框架最难的从来不是做出 demo，而是让团队在真实项目里遇到问题时，能不能找到足够多的文档、案例、第三方库和社区经验。
Electron 在这方面的护城河非常深。Tauri 经过这些年的积累，也已经形成了稳定的开发者心智。Native SDK 目前显然还没有走到那一步。
第二，它要求你接受新的技术栈
Electron 和 Tauri 的一个现实优势，是前端团队可以大量复用既有能力。组件思维、样式体系、前端构建经验、现成 UI 库，这些都能继续发挥价值。
Native SDK 则要求你切换到 .native + Zig 的组合。对一部分工程师来说，这很新鲜；对团队管理来说，这也是明确的学习成本。尤其当业务本来已经有一套成熟 Web 前端时，迁移的摩擦不会小。
第三，不是所有产品都适合脱离浏览器生态
如果你的产品本身就深度依赖 Web 技术世界，比如复杂富文本、成熟图表生态、现成前端组件库、浏览器特性兼容逻辑，甚至已经有一套完整 Web 产品想直接桌面化，那 Electron 和 Tauri 依然有很强的现实优势。
原因很简单：复用已有资产，本身就是最重要的工程效率。
Native SDK 更像是在告诉大家，桌面应用不是只能在 Electron 和 Tauri 两条路里选；但它并不等于所有项目都应该改道。
它最特别的地方，其实还不是体积，而是 AI Agent 集成
这次 Native SDK 里我觉得最有意思的部分，是它把“可被 Agent 操作”直接当成框架能力的一部分来设计。
官方提供的自动化能力里，Agent 可以：
- 读取运行中应用的界面状态
- 执行点击、输入等交互
- 生成 snapshot 和 screenshot
- 等待界面进入某个状态后再继续下一步
对应命令大致是：
native automate wait
native automate snapshot
native automate screenshot
更关键的是，这套自动化能力不是停留在“把 UI 当黑盒截图”。官方给出的方向是：Agent 不只看到界面，还能把问题定位回具体 .native 文件和对应行号，再继续修复。
这件事的意义很大。
因为过去我们谈 UI 自动化，更多是在说测试。现在如果框架本身就为 Agent 提供可观察、可定位、可操作的界面语义，那么它就不只是“方便测试”，而是在为下一代开发流程预留接口。
换句话说，Native SDK 想服务的可能不只是开发者，也包括未来越来越常见的工程 Agent。
现在最适合谁用
如果今天让我给它下判断，我会把人群分成两类。
比较适合尽快试水的：
- 新做的轻量桌面工具
- 很在意启动速度和包体的产品
- 愿意接受 Zig 学习成本的小团队
- 想探索 Agent-first 开发体验的工程团队
暂时不建议直接押生产主线的：
- 已经有复杂 Web 前端资产的大项目
- 强依赖浏览器生态的桌面产品
- 希望框架 API 很稳定的企业级团队
- 计划把 iOS / Android 也一起作为成熟生产端发布的项目
尤其是移动端，官方现在仍然把它放在实验性支持范围里。拿来验证方向可以，但不太适合直接承担稳定交付预期。
我的判断
Native SDK 不是一个“Electron 杀手”那么简单，它更像是在重新提一个问题：桌面应用真的还必须默认建立在浏览器技术栈之上吗？
过去很多人默认答案是“是”，因为前端生态太强，工程效率太高。Native SDK 现在给出的答案是：未必。如果你的目标是极小体积、极快启动、原生渲染和更适合 Agent 参与的开发体验，那么确实可以换一种底层假设。
但从工程现实看，它现在更像一条值得认真跟踪的新路线，而不是马上能替代一切的统一解法。
所以更准确的说法不是“Electron、Tauri 该让位了”，而是：
桌面应用框架这件事，终于又出现了一个值得重估旧答案的新变量。
快速上手
如果只是想本地体验一下，官方 CLI 现在的基本流程是：
npm install -g @native-sdk/cli
native init my_app
cd my_app
native dev
先跑通一个小 demo，比先争论它会不会取代 Electron 更有价值。很多框架的真实判断，最后都不是看宣传页，而是看你把一个真实小工具写出来时，阻力到底大不大。