Vercel 做了一件意料之外又情理之中的事——发布了一款原生桌面应用工具包，名叫 Native SDK。GitHub ⭐6.2k，Apache-2.0 开源，2026 年 5 月上线后迅速爬升至 Trending 前列。

它不是又一个 Electron 或 Tauri。Native SDK 的使用体验介于 SwiftUI 和 Elm 之间，渲染路径上没有浏览器、没有 WebView、没有 JavaScript 运行时——编译产物是单一二进制文件，一个计数器应用只有几 MB。

核心亮点

没有浏览器的原生渲染。 这是 Native SDK 最激进的决策。Electron 打包 Chrome 内核，Tauri 依赖系统 WebView，而 Native SDK 有自己的渲染引擎，直接从 .native 标记文件编译为原生窗口。所有的按钮、面板、列表、输入框都在 Metal（macOS）/ 软件渲染器（Linux）上绘制，字体排印、间距、色彩在编译时就确定了。这也意味着打开一个 Native SDK 应用不需要等待 WebView 初始化，启动时间接近系统原生应用。

TypeScript 写逻辑，Zig 写核心。 视图用 .native 标记语言描述——看起来像 HTML 的简化版，不支持 DOM 操作，只负责声明布局和数据绑定。逻辑层用 TypeScript 或 Zig，编译时直接转为原生代码。架构是经典的 Elm 模式：Model 定义状态 → Msg 定义事件 → update() 纯函数更新状态。Vercel 专门为 Native SDK 定义了一个「核心子集」TypeScript，只允许纯函数、不可变数据、代数数据类型——你在 React 中习惯的 useEffect 和可变 ref 在这里不存在。状态变化是可预测的，甚至可以用 native automate record 录制一次操作，然后用 replay 在无头模式下逐帧回放。

设计令牌系统。 样式不是 CSS，而是通过设计令牌（Design Tokens）定义。颜色、圆角、字体均用名称引用，主题切换时所有令牌重新解析。examples 目录下的 soundboard 和 deck 是同一个音乐播放器，仅通过不同的令牌和 chrome 布局重新换皮，外观差异巨大。内置组件目录包含按钮、标签页、文本框、对话框、图表、虚拟列表等，开箱即用。

在白物集中的结合点

白物集目前的桌面端体验依赖浏览器。如果未来需要一个原生桌面工具——比如离线内容管理工具、Markdown 写作桌面端、或构建产物预览器——Native SDK 是比 Electron 更轻量的选择。

白物集的主栈是 Astro + Express + Supabase。Native SDK 的一个示例 examples/next 展示了如何将原生窗口与 Next.js 前端配对。同样的模式可以用于 Astro：用 Astro 构建 Web 界面，Native SDK 提供原生窗口壳和系统集成（系统菜单、托盘、文件对话框、剪贴板）。Web 前端与原生壳之间通过 IPC 通信，不需要重写现有代码。

Native SDK 对 AI 工作流的设计也值得关注。每个应用内嵌了一个自动化服务器，AI Agent 可以通过 accessibility snapshot 读取界面状态、驱动控件、做断言检查。native check 在编译期检查 accessibility 合规。这与白物集用 Hermes Agent 自动化内容生产的工作流方向一致——工具从第一天就为 AI 操作界面而设计。

与 Electron / Tauri 的对比

这三者在架构上代表了三个代际的桌面开发思路。Electron 打包 Chromium + Node.js，优势是 Web 技术栈全量可用，代价是 150MB+ 的基础内存占用和打包体积。Tauri 用系统 WebView，体积大幅缩小，但仍然依赖浏览器的渲染管线——你在 macOS 上看到的是 Safari 的内核，Windows 上是 WebView2。Native SDK 彻底去掉了浏览器层，用自研引擎直接绘制原生窗口，启动时间接近 Xcode 或原生 SwiftUI 应用。

但代价也存在：Electron 能直接用任何 npm 包，Tauri 可以复用前端框架生态，而 Native SDK 的 .native 标记语言是一个封闭的领域。你不能把现有的 React/Vue 组件直接拖进去——这一点在评估时需要想清楚。

适合什么场景

最佳场景是需要原生桌面体验、又不希望引入 Electron 庞大运行时的小型工具。比如 Markdown 编辑器、API 调试器、系统监控面板、文件管理工具。编译后是单文件二进制，分发非常简单。

适合有 TypeScript 或 Zig 经验的团队。.native 标记语言的学习成本很低——flex 布局、数据绑定、事件派发，半天就能上手。

不适合已有大规模 Web 前端需要迁移的场景。Native SDK 不是 React/Vue 的替代品，它的 UI 层没有 DOM、没有 CSS、没有浏览器 API。如果你需要内嵌复杂 Web 应用、或依赖大量 npm 生态的 UI 组件，Native SDK 的集成方式（examples/webview 展示的 WebView composition 模式）是退路但不够优雅。

不适合需要快速原型验证的产品阶段。Native SDK 仍在 pre-1.0，API 会变动，示例工程中的 app.zon 配置格式在 6 月份的提交中改过。对于稳定生产级产品，建议等 1.0。

快速上手

安装 CLI：

npm install -g @native-sdk/cli

创建一个应用：

native init my_app
cd my_app
native dev

这会打开一个原生窗口，显示一个计数器。整个应用的结构：

• src/app.native — 视图标记文件
• src/core.ts — TypeScript 逻辑层（Model、Msg、update 函数）
• app.zon — 应用配置

用 Zig 写核心：

native init my_app --template zig-core

检查代码：

native check

毫秒级完成，输出 file:line:column 级别的错误信息。

构建发布版本：

native build

产物在 target/release/ 下的单文件二进制。

Native SDK 目前对 macOS 的支持最深（Metal 渲染、原生滚动、系统菜单、托盘），Linux 运行完整展示（软件渲染器，支持 IME 和高 DPI），Windows 在 CI 中经过输入注入测试。iOS 和 Android 的 embed 库处于实验阶段。

---

Native SDK 是否代表了桌面开发的新方向？它能走多远取决于生态系统建设的速度——组件库的丰富度、第三方插件的支持、社区的活跃度。但 Vercel 在前端工具链上的积累（Next.js、Turborepo、Vite 早期贡献）意味着他们有足够的能力推动这件事。目前 6.2k stars 和每天持续提交表明团队在认真投入。

如果你是桌面工具开发者，值得关注。如果你是 Electron 的重度用户，值得对比。如果你只是好奇 Vercel 在做什么——native init 一下，五分钟就看到结果了。