Electron alternatives: Tauri, Wails, Neutralinojs, Flutter and native
If you want to leave Electron, the closest swap is a framework that keeps your HTML, CSS and JavaScript but uses the web view the operating system already has: Tauri, Wails or Neutralinojs. If you would rather drop the web stack, Flutter, .NET MAUI or a fully native app are the other routes. If you only want a website in its own window, you do not need a framework at all, and a wrapper such as Pake does that without writing code.
Why people look past Electron
Electron describes itself as a framework for building desktop apps with JavaScript, HTML and CSS, and says it works by embedding Chromium and Node.js into its binary. Every Electron app therefore carries its own browser engine, which is where the large download comes from, and the app's author is the one who ships engine updates. Tauri vs Electron for wrapping a website compares those two trade-offs in detail, so this post does not repeat it.
An empty app’s size does not represent your own app. Published comparisons usually measure an empty app, and installer size is a different thing from memory in use. What can be said from the vendors' own pages is structural: Tauri says apps do not bundle a browser engine and that a minimal one can be under 600 KB, a claim about an empty app on its own terms. Whether your app uses less memory depends on the engine and on what your page does, so measure your own build in Activity Monitor or Task Manager before you decide.
The reasons that hold up are narrower. You want a smaller download. You do not want to ship Chromium security updates yourself: Electron's release timeline puts out a new major every 8 weeks and supports only the latest three, so a major leaves support about 24 weeks after it ships, and an app that skips that pace runs an unsupported Chromium. Or your app is mostly a website and carries a whole browser for it.
The options, from the vendors' own words
Tauri. Its start page calls it a framework for tiny, fast binaries for all major desktop and mobile platforms. You use any frontend that compiles to HTML, JavaScript and CSS, and the backend can use Rust, Swift and Kotlin. Apps use the web view already on the user's system, with WRY rendering it. It is the nearest thing to a drop-in idea for an Electron team, with a Rust backend in place of Node.js.
Wails. Its README says to use standard Go for the backend, to wrap Go code and a web frontend into a single binary, and that it uses native rendering engines, "no embedded browser". The page does not list platforms by name, so check its installation docs for yours. A fit for a Go team.
Neutralinojs. Its documentation says it does not bundle Chromium and uses the existing web browser library in the operating system, runs on Linux, Windows, macOS and the web, and can be extended in any language through extensions. It describes itself as lightweight and portable. As with the others, the web engine is the OS's.
Flutter. Flutter's desktop page says it compiles native Windows, macOS or Linux apps, and its multi-platform page speaks of native-compiled performance without large browser engine dependencies. Flutter uses the Dart language, per its fundamentals guide. You rewrite the interface in Dart rather than reuse a web UI, so it suits a new app more than a port.
.NET MAUI. Microsoft's overview says it is for native mobile and desktop apps in C# and XAML, on Android, iOS, macOS and Windows. macOS apps use Mac Catalyst and Windows apps use WinUI 3. Linux is not in that list. If you need web content inside it, its WebView uses WebView2 on Windows and WKWebView on Mac Catalyst.
Native. SwiftUI or AppKit on a Mac and WinUI on Windows give the most platform behavior and the most work, since each platform is its own code base.
A comparison table
| Language | Web view | Platforms (per vendor page) | Fit | |
|---|---|---|---|---|
| Electron | JavaScript, HTML, CSS | Bundled Chromium | Windows, macOS, Linux | Same engine everywhere |
| Tauri | Frontend in web tech, backend Rust, Swift or Kotlin | System web view | Major desktop and mobile | Web UI, small binary |
| Wails | Go plus web frontend | Native rendering engine | "Multiplatform", no list in its README | Go teams |
| Neutralinojs | Web frontend, any language by extensions | OS web browser library | Linux, Windows, macOS, web | Very small tools |
| Flutter | Dart | Compiles native apps, no browser engine dependency per its page | Windows, macOS, Linux | New UI, not a port |
| .NET MAUI | C#, XAML | Native controls; WebView optional | Android, iOS, macOS, Windows | .NET teams |
The table leaves out maturity. The vendors' pages do not give a comparable measure, and release dates and star counts age fast. Check each project's release notes and issue tracker for the last few months before you commit.
How a system web view changes the work
Moving off Electron is not only a packaging change. With a system web view the page is rendered by WKWebView on a Mac, WebView2 on Windows and WebKitGTK on Linux, as Tauri's webview reference lists. The same HTML can behave differently in each, so you test on every system you ship to, including the WebKitGTK version your Linux users have. You also lose anything that depends on Chromium specifics or on Node.js inside the renderer. In return the engine updates with the OS, WebView2 or the distribution, not with your release.
What Pake uses and why
Pake is built on Tauri. It wraps an address and does not give you a framework, so it is the right tool only when your "app" is an existing website. The CLI copies a Tauri template, writes your options into its config, compiles it and bundles an installer, as How Pake works describes. Its FAQ says the installer is small because the engine is the system's, and that runtime memory is governed by the engine and the page, not by Pake. It documents no setting that swaps in Chromium. If you need the same Chromium everywhere, Pake is the wrong tool and an Electron-based wrapper fits better.
pake https://example.com --name Example
Moving a Nativefier app to Pake and WebCatalog, Unite, Coherence X and Pake compared cover the wrapper tools that sit next to these frameworks.
Choosing
If you have a working Electron app with a web UI, try Tauri first, then Wails or Neutralinojs if your team already writes Go or wants the smallest runtime. If you are starting a new UI and can leave the web stack, look at Flutter, MAUI or native. If the product is a website, wrap it. In every case build a small prototype of your riskiest screen on the target systems before committing, since engine differences show up there.
FAQ
Is Tauri smaller than Electron?
Tauri says apps do not bundle a browser engine and that a minimal app can be under 600 KB, so the download is smaller. Memory use depends on the engine and your page, so measure it.
Can I keep my React or Vue code?
Tauri says any frontend that compiles to HTML, JavaScript and CSS works, and Wails and Neutralinojs both host a web frontend. Node.js APIs in the renderer will not carry over.
Do I need a framework to put a website in a window?
No. A wrapper that builds an app from an address is enough, and Website to desktop app shows the options.
