Our API client is a 29 MB binary and starts in 0.1s. Here's the Tauri vs Electron footprint, with numbers

Every dev tool I install seems to weigh more than my IDE. My API client, the thing I use to fire off HTTP requests, sat at a few hundred megabytes on disk and used close to a gigabyte of RAM just sitting open in the background.

When we started Ironcall, keeping it small and fast wasn't a bullet point on a feature list. It was the whole reason we bothered. This post is about one decision that came out of that goal: using Rust and Tauri instead of Electron. What it costs, what it buys, and the numbers behind it.

The benchmark

I'll start with the data, since that's the only fair way to back up a "we're lighter" claim. Same machine, same task (app open, clean profile, nothing loaded), three clients:

(ratios shown as "vs Postman / vs Insomnia")

One thing about reading this: trust the ratios more than the absolute numbers. I ran it on a high-end desktop, so on a normal laptop you'll see slower startups and more RAM across the board. But the gap between the clients stays roughly the same on any hardware. Installed size doesn't depend on the machine at all: 29 MiB against 394 and 1538.

Methodology, so you can reproduce it or pick it apart:

• Versions: ironcall-bin 0.8.1, postman-bin 12.12.6, insomnia-bin 12.6.0. Run on 2026-06-11.
• Machine: Intel Core i9-14900KF, 31 GB RAM, NVMe, EndeavourOS, kernel 7.0.10-zen1.
• Startup is time-to-window, median of 5 runs. RAM is PSS of the full process tree, so Ironcall's WebKit helpers and Electron's renderer, GPU and helper processes all count. Neither side gets undercounted.
• All three forced onto XWayland so it's apples to apples (Ironcall with GDK_BACKEND=x11, Postman and Insomnia with --ozone-platform=x11).
• Full numbers and method are on the site: https://ironcall.dev/benchmarks

I left request latency out on purpose. It's dominated by the network and the server, so it's about the same in any client. Claiming faster requests there would be nonsense and easy to disprove.

Tauri vs Electron, concretely

Why is the gap that big? It's structural, not some clever micro-optimization.

Electron ships a full Chromium runtime inside every app. Five Electron apps means five copies of a browser engine resident in memory. Nice for the developer, heavy on disk, and that 394 MiB / 1538 MiB install is mostly the bundled /opt runtime.

Tauri goes the other way. It uses the webview the OS already has (WebKitGTK on Linux, WebView2 on Windows) instead of shipping its own browser. The UI is still web tech, but the engine is already there. Ironcall is a ~29 MiB binary linking the system WebKitGTK, with no Chromium to carry around. Most of the startup and size difference comes down to that.

There's a real cost to it, though. With Electron you target one Chromium everywhere. With Tauri you target two webview engines, WebKitGTK and WebView2, and they don't behave the same. Here's what actually bit us:

• WebKitGTK has no native undo in text inputs. On Windows, Ctrl+Z in an <input> or <textarea> works like you'd expect. On Linux it does nothing. We had to write our own undo/redo, a beforeinput listener that keeps snapshots and restores them on Ctrl+Z and Ctrl+Y. Something a browser gives you for free, rebuilt by hand.

• The OS themes native <select> elements. WebKitGTK draws the dropdown with the system theme, so you get a light popup over a dark UI that looks broken. We replaced every native <select> with our own Portal-based dropdowns so we control the look on both platforms.

• WebKitGTK eats some keyboard shortcuts before JS sees them. Ctrl+Shift+Tab gets caught at the GTK level and never reaches our keydown handler. Our fix isn't pretty: we handle forward shortcuts on keydown and backward tab navigation on keyup, because keyup isn't intercepted. Asymmetric, purely because of the platform.

• A strict CSP rules out new Function(). We originally wanted pre and post-request scripts to run in the webview through new Function(...). Our CSP (script-src 'self', no unsafe-eval) refuses to compile a string as JavaScript, and we weren't about to loosen the CSP on an app that renders HTTP response bodies. So scripts run in the QuickJS engine in the Rust core instead. That one worked out well (real sandboxing, same engine as the CLI), but the platform forced our hand.

• Auto-update isn't the same on both. Tauri's in-place updater works on Windows. There's no Linux equivalent, so Linux users get an "update available" banner that points at the download page instead of updating in place. Not a bug, just something Electron hides and Tauri makes you deal with yourself.

None of this was a dealbreaker, but it's the price of the footprint above. You give up "one engine everywhere" for a smaller, faster app, and you pay it back in platform quirks.

What's actually doing the work

The size claim would be hollow if the app were just a webview around an empty backend. It isn't. Most of the work in Ironcall happens in native Rust, in a shared core library:

• The HTTP engine, the collection runner (run_collection), variable interpolation, the cookie jar and YAML import/export are all native Rust.
• The same core backs a headless CLI, so desktop and CLI run the exact same engine. A request behaves identically whether you fire it from the UI or a terminal.
• Pre and post-request scripts run on QuickJS (the rquickjs crate), sandboxed with a 64 MiB memory cap and a 2-second timeout. No full Node runtime involved.

The UI is web tech. The parts that decide correctness and speed aren't.

Private by default

A couple of things that come out of being offline-first:

• Your collections live in a local SQLite database and export to plain YAML, so you can diff them in git. No account and no connection needed to use the app.
• Optional team sync is end-to-end encrypted. Keys are derived on the client with Argon2id, workspace keys are shared between members over X25519 with HKDF-SHA256 wrapping, and payloads are AES-256-GCM. The server only ever stores ciphertext it can't read. Hosting is EU-only. The same crypto code compiles to WASM for the web side, so there's one implementation rather than three.

What it is, and what it isn't yet

Ironcall is in public beta right now, on Linux and Windows, free during the beta. The local client stays free and unlimited for good (CLI included), and only the optional team sync becomes paid later on.

Since it's a beta, the gaps: no macOS build yet, and a few V1 things aren't in (OAuth2 helper, OpenAPI/Bruno import, WebSocket/SSE, command palette, mTLS).

If a lightweight, local-first API client is something you've wanted, the beta's free and I'd like your feedback, especially if you can break the benchmark above. It's at https://ironcall.dev/download