Five months after switching Fluxzy from Electron to Tauri

New<br>Fluxzy v2 just shipped. Electron is out, Tauri is in. gRPC ready, 3x smaller install.<br>Learn more

Five months after switching Fluxzy from Electron to Tauri

Quick context. We make Fluxzy, an HTTPS debugging proxy in the Fiddler and Charles family. It runs offline, no account, no cloud. The capture engine is fluxzy.core, an open source .NET MITM library (https://github.com/haga-rak/fluxzy.core) that handles HTTP/1.1, HTTP/2, gRPC, and WebSocket. The desktop app sits on top of that engine and adds the things we actually wanted when debugging traffic: native PCAPNG capture with embedded TLS keys so Wireshark can decrypt the session, JA4 fingerprinting, decoded multipart forms and JWTs, Monaco-based editors for inspecting and tweaking payloads, and a few things aimed at the new mess of LLM API traffic that nobody's tooling really handles yet.

The desktop app shipped in February 2023 on Electron. In December 2025 we pushed v2, which moved the shell to Tauri. The Angular frontend stayed put, and the .NET sidecar that runs the engine stayed put too.

Five months in. Here's what actually happened.

Why I left Electron in the first place

Electron was a great first run. Genuinely. The docs are excellent, the community is huge, and getting a multi-platform desktop app out the door in 2023 was basically a solved problem because of it. I have nothing bad to say about the people who maintain it. They do hard work.

But a few things piled up.

Bundle size and memory. The Windows installer dropped from around 190mb to 55mb. On macOS and Linux the memory footprint dropped noticeably too, because we're now running on WKWebView and WebKitGTK respectively instead of a bundled Chromium per app. On Windows, WebView2 is shared system-wide so there's no per-app Chromium being copied around. Same story.

I expected visual regressions going from Chromium to three different webviews. Got essentially none. Angular's build pipeline already handles polyfills and prefixing, which did most of the work for me. I am not going to pretend I was clever here. I was lucky that the frontend was already conservative.

Electron has a perception problem. This is uncomfortable to write but it's real. Among developers and network folks, the audience Fluxzy is aimed at, "Electron app" carries weight. Some of it deserved, some not. When a competitor in the proxy space is on Electron and you're not, that becomes part of the pitch whether you like it or not. I was naive about marketing for a long time. I thought good software sold itself. It doesn't. Stack matters to the people you want to reach.

Opening archives needs to be fast. A lot of Fluxzy users open many archive files in a session, debugging across captures. Cold start and file-open latency on Tauri is dramatically better than Electron. I don't have a clean benchmark to drop here so I won't pretend I do, but every user who tried both noticed without being prompted.

The Tauri capability model is genuinely nice. Coming from Electron, where the renderer either has access to everything you wire up or nothing, Tauri's capabilities feel like the right default. Permissions are scoped, declarative, and you opt in to what each window can call. For Fluxzy I never had to write a custom capability. The defaults plus a few standard plugin permissions covered everything: window controls, file system access on the archive paths, dialog, shell open for external links.

The whole surface lives in one JSON file and reads exactly like what it is:

"identifier": "default",<br>"windows": ["main"],<br>"permissions": [<br>"core:default",<br>"core:window:allow-set-title",<br>"core:window:allow-start-dragging",<br>"core:window:allow-minimize",<br>"core:window:allow-maximize",<br>"core:window:allow-close",<br>"shell:allow-open",<br>"dialog:default",<br>"dialog:allow-open",<br>"dialog:allow-save",<br>"clipboard-manager:allow-write-text",<br>"clipboard-manager:allow-read-text",<br>"process:allow-exit",<br>"process:allow-restart",<br>"identifier": "fs:allow-read-text-file",<br>"allow": [{ "path": "**" }]

That is a small thing on paper but it matters when your app is in the security/network space and you actually care about what the frontend is allowed to do. With Electron I had a hand-rolled IPC surface that I had to be paranoid about. With Tauri the framework is paranoid for me.

The shell got cleaner. The architecture was always Angular renderer plus Electron main plus a .NET sidecar doing the proxy work. The Node main process was glue, nothing more. Replacing that glue with Rust trimmed code I never enjoyed maintaining anyway. Rust forces a discipline that Node main processes do not. You do not get to leave a half-typed callback chain lying around for two years.

Pain points, because there are always pain points

IPC. Electron's IPC and Tauri's command/event model are different enough that this could have been a nightmare. It wasn't, because the Electron version already had a clean split between renderer...