zero-native wants web UIs to ship as native apps without the usual Electron tax

zero-native is one of those repos that immediately makes sense if you have ever wanted the ergonomics of a web frontend without automatically accepting the size and memory overhead that usually comes with desktop web stacks. The core idea is simple: keep the product UI in familiar web frameworks, but make the native shell small, fast, and explicit enough that it still feels like real application engineering instead of a browser bundle in disguise.

What makes the project interesting is that it does not pretend there is one perfect rendering strategy for every app. zero-native lets builders choose the platform WebView when tiny binaries and fast startup matter most, or bundle Chromium through CEF when rendering consistency matters more than footprint. That tradeoff sounds obvious, but many desktop stacks hide it behind ideology. Here it is a first-class product decision.

The native side is written in Zig, and that choice feels aligned with the whole pitch. The repo is optimized around quick native rebuilds, a small runtime surface, direct C interop, and fewer layers of glue between your app and the platform. In practice, that means teams can keep using Next, React, Svelte, Vue, or other web tooling on the frontend while still having a clearer path to native APIs, codecs, and local integrations when the app needs to do more than render a page.

I also like that zero-native treats security as part of the architecture instead of an afterthought. The README is explicit that the WebView is untrusted by default. Native commands, permissions, navigation rules, external links, and window APIs are opt-in and policy controlled through the app manifest. That is a much healthier starting point than the common pattern of exposing a broad bridge first and cleaning it up later.

Another good signal is the shape of the app model. The project uses a small App object, a Runtime, a structured app.zon manifest, and a size-limited window.zero.invoke() bridge with origin and permission checks. None of that is flashy on its own, but it shows the repo is trying to define a durable product surface, not just a demo wrapper around WebView.

The scope is wider than the repo subtitle first suggests. zero-native is still pre-release, but the current docs already position it around macOS, Linux, and Windows desktop build paths, with mobile embedding examples for iOS and Android through a C ABI. The latest v0.1.9 release also added Linux and Windows desktop support improvements plus better CEF packaging and install flows. That matters because it signals real ambition: not only "how do I wrap a webpage," but "how do I shape a reusable native shell across platforms."

For product-minded builders, the strongest idea here is optionality without chaos. A lot of cross-platform app tooling becomes heavy because it tries to abstract away every tradeoff. zero-native goes the other direction. It keeps the choices visible: which engine to ship, which permissions to expose, which frontend assets to trust, and how much native behavior to surface. That makes it more interesting than another "desktop app from web tech" starter.

There are still obvious caveats. WebView-based products always inherit platform differences, and bundled Chromium brings back some of the size and distribution complexity that lightweight shells are trying to avoid. The repo is honest about being pre-release, so teams should treat it as an ambitious foundation rather than a settled default. But I am glad the project exists, because it pushes the conversation past the lazy assumption that the only options are Electron everywhere or fully custom native UI.

If you build products with web teams but still care about native footprint, startup time, and explicit security boundaries, zero-native is worth watching closely.

GitHub: https://github.com/vercel-labs/zero-native Homepage: https://zero-native.dev