Recently I found myself in need of doing GUI with Rust, so I researched and experimented a bit. In this post, I want to share the data I collected, as it might help others. I will mostly compare Tauri, Iced and egui as those seem to be popular choices. I spent quite a bit of time performing tests to assess the speed/performance of these libraries, as a snappy UI experience is something I really value.

🔑 Key takeaways

• All three are likely fast enough for most cases.
• Tauri falls slightly behind Iced and egui in terms of startup time and resize performance (on my machine).

Note: This is by no means a full comparison! There are certainly important aspects that are not mentioned in this post. Also be sure to read the disclaimer regarding my performance tests! If you find any factual error, please let me know so that I can fix the post :)

Quick introduction

• Tauri: Uses the webview by the OS to render an HTML/JS frontend. You can chose any frontend framework (JS or Rust). “Backend” is written in Rust, can communicate with frontend via built-in methods.
• Iced: Elm-inspired (reactive) GUI library. Uses wgpu for rendering on desktop; experimental web backend to create DOM for rendering. All code in Rust.
• egui: Immediate mode GUI using OpenGL for custom rendering. All code in Rust.

Comparison

Statistics Tauri Iced egui GitHub 60k★, used by 10k 18k★, used by 2k 13k★, used by 6k crates.io downloads (recent/all-time) 145k / 485k 30k / 180k 135k / 600k

Architecture & Implementation Tauri Iced egui Programming model Depends on chosen frontend-framework Elm-like/reactive Immediate mode Desktop 🟢 via OS webview 🟢 wgpu-based 🟢 backend-agnostic, default backend is OpenGL-based Web 🟡 not built-in, manual setup possible 🟠 experimental, via iced_web 🔴 via WebGL†

Subjective Ratings Tauri Iced egui Stability/Maturity 🟢 1.0, big community, has sponsors, multiple devs, has Governance page 🟠 0.7, "experimental", active development since 2019, used a lot 🟠 0.20, “in active development”, “interfaces in flux”, “lacks features”, active development since 2019, mainly one dev, used a lot Documentation Fairly good; lots of templates; could use more guide-level docs for backend; crate docs could be better Good crate docs, but lacking guide-level docs; "book" basically non-existent; many examples Good crate docs; many examples DX 🟢 Frontend instant reload; browser dev tools; good CLI tools 🟠 Always recompile; debug overlay with performance metrics 🟠 Always recompile

Performance on my machine

(see disclaimer below!)

Tauri Iced egui Startup time ≈380ms (window after ≈125ms) ≈230ms (window after ≈33ms) ≈280ms Input delay (frame = 16ms) 2–3 frames 3 frames 2 frames Resize 🟠 10–15fps 🟡 12-30fps 🟡 12-30fps Binary size 5MB 17MB 18MB

† Using a canvas-based renderer on the web is not optimal for a number of reasons (not being able to ctrl+f, inputs being weird, …). See here for more information.

Performance

Important disclaimer

Everything was measured on my Ubuntu 20.04, Gnome 3.36.8, X11, Nvidia proprietary drivers, without animations (disabled in Gnome Tweaks), 60Hz monitor. I hardly changed any desktop/Gnome configuration, but still: the setup could be borked for any number of reasons (#linux). The fact that moving windows around was not always 60fps is already an indicator that something is wrong.

Do not interpret these performance metrics as a universal statement about these GUI libraries. I have not even tested Windows or macOS, which could behave wildly different.

Methodology

All of these measurements were taken by recording the full screen with OBS, then counting frames in Avidemux. Programs used:

• Tauri: helloworld example at 7e8e0e76ec.
• Iced: todos example at 98a717383a (yes, I should have used “hello world”, too, but I don’t think it makes a difference in this case).
• egui: hello_world example at 5725868b57.
• Sublime Text Build 4143 with a project and many tabs open.
• VS Code 1.74.3 with home directory opened in the side browser, but hardly any tabs.
• xclock

The first three I compiled myself with cargo build --release. The last three I included for comparison. I mainly use Sublime Text, an editor using a custom UI framework, which is often praised for its snappy UI. VSCode is a very popular editor that uses Electron, which is often criticized for being slow and sluggish. I figured xclock is a super low level UI application, without any framework, using X calls directly.

And yes, I realize this is not a fair comparison for Sublime Text and VSCode, as they are useful programs with lots of data loaded, instead of minimal examples. I still think the comparison is useful.

Startup time

Binaries were directly started from the terminal (no cargo or npm used). I counted the frames from the moment my “Enter” press was drawn by the terminal until the window appears/the final UI is rendered. This is not an exact measurement of the absolute perceived startup time, but it’s useful for a relative comparison. Numbers are in ms, one number per test/trials.

| | Final render | Window appears | Visual jumps | Behavior of window contents | | | ———— | ––––––– | ———— | ————————— | | Tauri | 366, 417, 400 | 100, 134, 150 | 1 | First grey, then final UI | | Iced | 333, 217, 266, 217, 217 | 33, 33, 33, 33, 50 | 1 | First black, then final UI | | egui | 300, 200, 283, 300, 250 | 🠔 | 0 | Final UI from the start | | xclock | 66, 100, 84 | 🠔 | 0 | Final UI from the start | | Sublime | 450, 450, 467 | 🠔 | 0 | Final UI from the start | | VSCode | 1450, 1250, 1450 | 500, 484, 517 | 4 | First grey, after 180ms blue, one frame later three color areas (roughly resembling the layout), roughly 400ms later almost final UI, 130ms later icons are drawn |

Resizing

App was horizontally resized (changing its width). FPS was determined by looking at the recording and counting frames between changes. By “decorations” I mean the window title bar with close buttons and the like.

| | Resize FPS | Behavior | | | ––––– | –––– | | Tauri | ≈10–15 fps | UI lags behind window | | Iced | ≈12–30 | UI in sync with window. Funnily, decorations lag behind | | egui | ≈12–30 | UI in sync with window | | xclock | ≈20–30 | UI in sync with window | | Sublime | ≈20–30 | UI in sync with window | | VSCode | ≈8–12 | UI lags behind window (sometimes black replacement, sometimes blue) |

Input lag

For each application I pick an element that changes color on hover. I count how many frames the cursor is over said element without the element changing color. The cursor is also recorded by OBS: I don’t know how exact this is, but the cursor sometimes seemed to lag/skip a frame in the recording. So take this, as everything else, with a grain of salt.

Input lag in frames (each tested multiple times):

• Tauri: 3, 2, 2, 3, 3, 3, 3
• Iced: 3, 3, 3, 3, 3, 3, 3
• egui: 2, 2, 2, 2, 2, 2
• Sublime: 2, 2, 2, 3, 2
• VSCode: 3, 4, 6, 3, 3, 6

I checked Tauri, Sublime Text, and VSCode and all three scroll with 30–60fps. Sublime hits the 60fps more often than the other two, but also skips a frame from time to time.

---

Discuss on Reddit.