Front-end developers building desktop applications have always faced a fundamental choice.
If you want simple development and a mature ecosystem, you pick Electron. The trade-off is that a full Chromium + Node.js stack is bundled directly into the app, making it hard to truly slim down the installer size, memory usage, and startup speed.
If you want a smaller bundle and better performance, you pick Tauri. It no longer bundles a full Chromium, and instead uses the system's built-in WebView, but at its core it is still:
HTML + CSS + JavaScript
↓
System WebView
↓
Rust native capabilities
Now, Vercel Labs has offered a third answer.
The project is called Native SDK.
It bypasses the browser, WebView, and JavaScript engine entirely. You write the interface using a .native syntax that resembles front-end templates, then use Zig to handle state and business logic. Finally, a custom rendering engine draws pixels directly into the system window.
The official numbers are equally striking:
Complete app: under 6 MB
Time to first frame: about 100 ms
Bundled browser: 0
JavaScript engine: 0
Runtime interpreter: 0
This time, Vercel Labs has truly turned the desktop app world upside down.
Why Is Electron Getting Heavier and Heavier?
Electron’s biggest advantage is something every front-end developer understands.
You can freely choose Vue, React, or Svelte, and write directly in HTML, CSS, and JavaScript. Basically, anything that runs in a browser can be moved into a desktop application.
Its architecture is also very straightforward:
Front-end page
↓
Chromium
↓
Node.js
↓
Windows / macOS / Linux
This is why VS Code, Discord, and Slack chose it:
High development efficiency, minimal platform differences, and a complete web ecosystem.
But the problems also come from this architecture.
Every app has to carry a full browser runtime environment. Even if you are just building a simple Markdown editor, file utility, or status-bar app, you still need to launch it with Chromium and Node.js in tow.
Apps get bigger, memory usage climbs, and startup speed can hardly reach true native levels.
In short, Electron’s greatest advantage is the browser, and its greatest burden is also the browser.
Tauri Is Already Lightweight, but It Hasn't Left WebView Behind
Tauri’s approach is much smarter.
It does not package a full Chromium into the installer. Instead, it directly calls the WebView provided by the operating system:
Vue / React / Svelte
↓
HTML + CSS + JavaScript
↓
System WebView
↓
Rust
As a result, Tauri apps are usually much smaller than Electron apps. Backend capabilities can be handed to Rust, leading to clear improvements in security and performance.
For existing front-end projects, the migration cost is relatively low. As long as the project can ultimately be compiled into HTML, CSS, and JavaScript, it can basically be wrapped into Tauri.
But it still cannot get around WebView.
Windows mainly uses WebView2, which is based on Edge Chromium under the hood; macOS uses WKWebView; and Linux relies on WebKitGTK.
Differences may still exist across platforms in terms of browser versions, rendering results, and supported capabilities.
So Tauri solves the problem of bundling a full browser being too heavy, but it has not completely left browser rendering behind.
Native SDK is even more radical.
Native SDK: The Interface Is Compiled Directly into the App
Native SDK uses two types of files by default:
src/app.native
src/main.zig
The .native file handles the interface:
<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>
Doesn’t that look familiar?
It has components, attributes, events, and data binding. The overall syntax is very close to HTML and the template syntax of modern front-end frameworks.
But it does not generate a DOM, nor is it handed to a browser to execute.
At build time, the .native interface is compiled directly into the executable file, and Native SDK’s own engine handles layout, drawing, and event processing.
The released app does not need to carry:
– Browser
– WebView
– Template parser
– Script interpreter
– JavaScript engine
Business logic is written in 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,
}
}
The entire state model is very simple:
User action
↓
Send Msg
↓
update modifies Model
↓
Recalculate interface
Front-end developers familiar with Redux, Elm, Pinia, or unidirectional data flow will basically understand it at a glance.
The interface can only read state and send messages; it cannot freely modify data in different components. All state changes are centralized in update, making debugging, testing, and AI generation more stable.
6 MB and 100 ms: How Obvious Is the Advantage?
The multiple complete applications demonstrated by Native SDK have release binaries that do not exceed 6 MB:
Calculator: 3.6 MB
Markdown Viewer: 3.5 MB
Notes: 3.5 MB
Soundboard: 5.7 MB
System Monitor: 3.7 MB
In a macOS ARM64 environment, the warm startup time for these examples—from process launch to the first frame—is about 71–131 ms.
A complete Markdown editor example has a binary of only 3.4 MB.
The reason is straightforward:
No Chromium
No Node.js
No system WebView
No JavaScript engine
No runtime template interpreter
The release artifact mainly consists of:
Your business logic
+
Native SDK rendering engine
+
System native frameworks
For applications like file utilities, desktop clients, productivity tools, Markdown editors, database managers, system monitors, and internal dashboards, this kind of size and startup speed is certainly very attractive.
Of course, these figures come from the project team’s tests on specified devices and sample applications. You cannot directly conclude that it is “tens of times faster than Electron.”
The runtime environments, browser capabilities, and ecosystem scale provided by the two are simply not in the same league.
But one thing is certain:
When an app no longer carries a browser runtime, its size and startup speed will naturally become much lighter.
Electron, Tauri, or Native SDK: How to Choose?
The technical paths of the three solutions are already very clear:
Electron
UI technology: HTML / CSS / JS
Runtime environment: Chromium + Node.js
Biggest advantage: Mature ecosystem, strong compatibility
Main cost: Large bundle size and high resource usage
Tauri
UI technology: HTML / CSS / JS
Runtime environment: System WebView + Rust
Biggest advantage: Small size, reusable front-end projects
Main cost: Still affected by WebView and platform differences
Native SDK
UI technology: .native + Zig
Runtime environment: Custom native rendering engine
Biggest advantage: No browser, small size, fast startup
Main cost: Early-stage ecosystem, need to learn Zig
Electron is still suitable for migrating complex web products, as well as applications that heavily depend on the browser ecosystem.
Tauri is suitable for teams that want to keep using Vue or React while reducing installer size and resource usage.
Native SDK targets another type of project:
Projects that want to keep the development efficiency of declarative UI while truly breaking free from the browser runtime.
It does not require developers to go back to the tedious AppKit, Win32, or GTK, nor does it keep stuffing the interface into a WebView. Instead, it rebuilds a layer between the two.
How Can Front-End Developers Get Started Quickly?
Installation is very simple—just use npm:
npm install -g @native-sdk/cli
To create a project:
native init my_app
cd my_app
native dev
Once it finishes, a real system window will open.
The default project structure is also clean:
src/app.native # Interface, layout, bindings, events
src/main.zig # State and business logic
src/tests.zig # UI tests
app.zon # App configuration, permissions, windows, packaging info
assets/icon.png # App icon
During development, if you modify src/app.native, the window will update automatically and try to preserve the current state.
If you make a mistake in the code, the old interface will not crash immediately. It will also return the specific file, line number, and column number.
To check the project:
native check
To run tests:
native test
To build a release version:
native build
To package the app:
native package --target macos
native package --target windows
native package --target linux
The CLI also handles the SDK path and the matching version of the Zig toolchain.
Developers do not need to maintain a complex build.zig right from the start. When the project really needs a custom build, they can use native eject to take over the full build files.
For front-end developers, this experience is very familiar:
Install CLI
↓
Initialize project
↓
Start dev server
↓
Modify interface
↓
Auto-update
↓
Build and package
Only this time, what ultimately runs is no longer a web page.
Five Platforms, One Runtime Model
Native SDK currently covers:
macOS
Windows
Linux
iOS
Android
The desktop side is currently the most mature part.
macOS
macOS is the most fully supported platform at the moment. It uses Metal for rendering and integrates system scrolling effects, menus, tray, pop-ups, and input methods.
Windows and Linux
Windows and Linux can already run, test, and package complete applications. However, they currently mainly use CPU software rendering, and the GPU rendering backend is still being improved.
Among them, Linux does not yet have system tray support, and some system capabilities on Windows and Linux are not as complete as on macOS.
iOS and Android
The mobile build pipeline has also been opened up:
native dev --target ios
native dev --target android
native package --target ios
native package --target android
iOS can generate a complete Xcode project, and Android can generate a complete host project and debug APK.
Developers do not need to maintain additional Swift, Kotlin, or Java host code in the project.
However, it should be noted that iOS and Android are still experimentally supported. They are mainly verified in simulator environments, and the toolchain, APIs, GPU rendering, and on-device workflows are still being refined.
So while using it to build desktop tools is already worth discussing, it is still too early to directly replace mature solutions like Flutter or React Native.
It Is Even Built for AI Agents
The most special thing about Native SDK may not even be the 6 MB size.
It builds AI automation capabilities directly into the runtime.
An agent can read the running application interface, inspect the accessibility tree, find buttons, enter text, click components, verify state, record operations, and generate deterministic screenshots.
native automate wait
native automate snapshot
native automate screenshot
The project also provides official Agent Skills:
npx skills add vercel-labs/native
After installation, agents such as Claude Code and Codex can obtain development instructions that match the current Native SDK version.
After an agent finishes writing the interface, it can also directly launch the app, operate the window, verify the results, and then go back and modify the code.
This closed loop is critical:
AI generates interface
↓
Compile and run
↓
Read real window
↓
Click and test
↓
Find problems
↓
Automatically modify
Previously, when AI wrote desktop applications, it could often only ensure that the code “looked like it would run.”
Native SDK wants agents to truly see the applications they have built.
It can even use component origin information to locate which .native file and which line of code a button comes from, and then automatically make the modification.
This is the truly AI-agent-oriented application development workflow.
Front-End Desktop Development Finally Has a Third Path
In the past, front-end developers did not have many choices when building desktop applications.
They either accepted Electron’s size and resource usage in exchange for a mature ecosystem and extremely low barrier to entry, or used Tauri to keep the web technology stack and leverage the system WebView and Rust for a lighter app.
Native SDK has chosen a more radical path:
Keep declarative UI
Keep component-based development
Keep data binding
Keep hot reloading
Keep the familiar front-end development experience
And then, delete the browser.
It is currently still in pre-1.0. The API will continue to change, and its ecosystem is far behind that of Electron and Tauri.
The rendering capabilities on Windows, Linux, and mobile also need to be further improved.
But this direction is already interesting enough.
A native application framework that is under 6 MB, starts in about 100 ms, supports five platforms, and even allows AI agents to directly operate and test it.
This time, the real competitor to Electron and Tauri has arrived.
Native SDK official website: https://native-sdk.dev/