# Niva: a Tauri WRY webview shell for frontend-only desktop apps

> Niva is a Rust and TypeScript framework for building Windows and macOS desktop apps on top of the Tauri WRY webview, aimed at teams that only want to write frontend code. It keeps the runtime small by using the system WebView, and it still ships as a beta candidate with Node compatibility, signing and notifications unfinished.

**bramblex/niva** — 一个基于 Tauri WRY 跨端 Webview 库的超轻量极易用的跨端应用开发框架。

- Repository: https://github.com/bramblex/niva
- Website: https://bramblex.github.io/niva/
- Stars: 716 · Forks: 44
- Language: Rust
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/bramblex-niva

## A webview shell for people who only write frontend code

Niva is described in its README as a lightweight, easy to use cross-platform application development framework built on the Tauri WRY cross-platform webview library, with Rust as the primary language. The target audience is stated plainly: you build a desktop application using frontend technologies, and you should not have to learn the complex Node.js and Electron APIs or wrestle with complicated configuration to get there. A simple project with no bundler, a common Vue project and a common React project are all described as needing no extra configuration, where you drag the project in and build it in one click. The repository is MIT licensed, the default branch is main, and the documentation site is bramblex.github.io/niva.

## The system WebView instead of a bundled Chromium

The size story starts with a decision not to ship a browser engine. The README states that Niva uses the system WebView, so it does not bundle Chromium or Node.js with the application. That choice is what makes the small binary possible, and the project backs it with a self-imposed measurement rather than a marketing number. The stated hard gate for the complete runtime main program is strictly under 3,300,000 bytes on macOS and strictly under 3,500,000 bytes on Windows, with 3,000,000 bytes on macOS kept as a reference target only. The README is careful that this figure does not represent the size of the whole application package or of the build kit. Supported platforms are Windows and macOS, and the exact support range and acceptance status are recorded per candidate release.

## Building from source means the TypeScript runtime comes first

The page runtime is generated from TypeScript in packages/runtime, so it has to be built before the native side is compiled. The README gives the sequence in four commands.

```sh
npm ci
npm run build --workspace=packages/runtime
cargo build --release -p niva -p niva-packager
npm run build --workspace=packages/devtools
```

After changing runtime sources, the generated artifacts have to be regenerated, and the release Cargo profile is tuned for size rather than speed.

```toml
[profile.release]
lto = true
opt-level = "z"
codegen-units = 1
strip = true
panic = "abort"
```

The Cargo workspace is made up of crates/niva, crates/icon_creator, crates/win_packager and crates/niva_packager, and the top level of the repository also carries build_MacOS.sh and build_Windows.cmd for the two host platforms. One thing to know before you start: the Cargo build does not download npm dependencies, so the order of the commands above matters.

## The IPC contract: api_call, data channels and Base64 frames

The bridge is where a frontend-only project still meets native constraints, and the README describes it in specific terms. This candidate version provides the existing Niva native API and a unified TypeScript runtime, and both CommonJS and ESM Node-style modules can be enabled independently. Asynchronous API creation and control all travel over a single IPC call named api_call. Streaming operations can use a stable IPC data channel once the stream has been created, and an already ready WebSocket is only an optional optimisation on top of that. Binary frames crossing the transport boundary are encoded in Base64, which is a real cost for anyone moving large buffers. Synchronous XHR is reserved for the Node-compatible APIs that need a synchronous return value, and the window, file and process capabilities together with their transport boundaries are set out in the bridge contract document under docs.

## One packaging core for a Windows EXE and a macOS app bundle

Delivery is the part Niva tries to remove from the developer's plate. The graphical development tool builds a desktop application with one click, without complex command line work and without requiring a Node environment on the machine doing the packaging. On Windows the output can be a single EXE or a portable ZIP, and on macOS it is a .app application bundle that can additionally be zipped, with both paths using the same packaging core, which the README refers to as the unified packager. There is a second level for teams that do not want toolchains at all: a release build kit contains the compiled main program and the unified packager, so packaging a business application with the kit requires neither Node nor Rust on the developer machine. The Niva packager is a Rust crate, and the repository includes a win_packager crate as well as an icon_creator crate.

## What the 0.10.0-beta.1 candidate still leaves open

This is a candidate, and the README says so rather than dressing it up. The current candidate is 0.10.0-beta.1, with its scope and per-platform acceptance status recorded in a dedicated acceptance document, and the project states that a candidate is not a passed 1.0 acceptance. The roadmap for 1.0 has application signing still open for both macOS and Windows. Node contract and real project acceptance is also open, and the note is explicit that a target subset does not mean a full Node runtime, with the stdio host using an ordinary process flow from the main window. System notifications are on the list as not yet supported. A separate 2.0 line carries a MiniBlink compatibility plan for older Windows, which the README says was deferred by user decision and has not been implemented.

## Node-style modules are an option, not a guarantee

The wording around Node is where a buyer should be most careful. The README says the candidate provides the existing Niva native API and a unified TypeScript runtime, and that CommonJS and ESM Node-style modules can each be enabled independently, but it explicitly declines to promise complete Node.js compatibility and qualifies the promise by the implementation capability of each existing module. The npm workspace is private and contains packages/devtools, packages/types and packages/runtime, with husky and the Node type definitions as development dependencies and a type-checker script that builds the runtime first and then type checks the types package. The examples directory makes the testing intent visible, with smoke projects for bridge routing, IPC fallback, the devtools CLI, macOS APIs, Node compatibility, resource layout, the runtime bootstrap, the stdio host, TypeScript CLI and Windows.

## Conclusion

Adopt Niva if your product is a desktop app written in Vue, React or plain frontend code, you ship on Windows or macOS, and you want a small runtime without bundling Chromium or Node.js. Keep away if you need signed installers, system notifications, a full Node runtime, or support for older Windows without a system WebView you control. Before you commit, build the release profile yourself, because the project enforces a hard size gate of under 3,300,000 bytes for the runtime main program on macOS and under 3,500,000 bytes on Windows, and that gate covers the runtime rather than the whole application package.

## FAQ

### Does Niva bundle Chromium or Node.js with the application?

No. The README states that Niva uses the system WebView, so it does not ship Chromium or Node.js inside the app, and the runtime main program is kept under a hard size gate of 3,300,000 bytes on macOS and 3,500,000 bytes on Windows.

### How do I build Niva from source?

The page runtime is generated from TypeScript in packages/runtime, so you build that workspace first and then compile the native crates with cargo. The release Cargo profile enables LTO, sets opt-level to z, uses one codegen unit, strips symbols and aborts on panic.

### Is Niva a stable 1.0 release yet?

No. The current candidate is 0.10.0-beta.1, and the README says a candidate does not represent a passed 1.0 acceptance. Application signing for macOS and Windows, Node contract acceptance and system notifications are still open items on the roadmap, and the last push to the repository was on 2026-10-06.

### Can my team package a Niva app without installing Node or Rust?

Yes, if you use the release build kit, which contains the compiled main program and the unified packager. The README states that packaging a business application with the kit does not require the developer to have Node or Rust installed, and the graphical development tool can build a desktop app without command line work.

## Sources

- [bramblex/niva on GitHub](https://github.com/bramblex/niva)
- [License: MIT](https://github.com/bramblex/niva/blob/main/LICENSE)
- [Project website](https://bramblex.github.io/niva/)
- [README](https://github.com/bramblex/niva/blob/main/README.md)
- [Releases](https://github.com/bramblex/niva/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bramblex-niva