Why we skipped Tauri and WebView too

If you have looked at desktop app frameworks lately, you have probably noticed Tauri. It is a real improvement over Electron, and for a lot of teams it is the right answer. We looked at it seriously before deciding to go native instead.

Tauri’s win is real — but it is about the download

Electron bundles Chromium, so every install carries ~150 MB of browser. Tauri does not bundle anything: it renders your interface in the webview the operating system already ships — WebView2 on Windows, WKWebView on macOS, WebKitGTK on Linux.

The installer drops from about 165 MB to roughly 12 MB. That is a big win, and if your only metric is “how long does the download take”, the conversation is over.

The browser does not disappear, it just moves

Here is the part that does not show up in the download number: the webview is still a browser engine, and it still has to run.

• On Windows, WebView2 is Chromium. Launching your app spins up browser processes with their own memory, exactly like Electron does — just sourced from the system instead of your installer.
• Your first frame cannot be painted until that engine has initialised, so startup has a floor that has nothing to do with your own code.
• Rendering is now delegated to something you do not control and cannot tune. Different platforms ship different engines, so “it renders like this on my machine” is a real category of bug.

Measured side by side, the picture looks like this:

Tauri wins on download size. It does not win on what the application costs you after it is installed.

What “native” means for speedmark

speedmark uses egui, an immediate-mode GUI library for Rust. It does not ask the system for a webview; it draws every widget itself and talks to the OS graphics layer directly.

That is what removes the startup floor and the idle memory tax. There is no engine to boot, so the window appears in about 0.18 seconds. There is no renderer process, so an open editor sits around 45 MB instead of several hundred.

The honest trade-off

Going fully native costs us things a webview would have given us for free:

• No HTML/CSS for layout, no component libraries — we draw and lay out by hand.
• Text shaping, IME and accessibility are toolkit problems, not browser problems, and they take real work.
• We maintain more platform-specific code than a webview app would need.

We accepted those costs because speedmark is a small, focused tool. If we were building a dashboard with charts, tables and forms, we would probably have picked a webview and been happy about it.

Pick the tool that matches the job. An editor whose whole promise is it opens instantly cannot afford a browser in the process.