EGUI slaps. I'm interested in comparing it with GPUI too: That one gets immediate cred for being demonstrated in a responsive program that demonstrates the range of its complexity.
EGUI bonus: Good integration with WGPU, so you can show 3D things as part of your UI.
Complaining time: Historically, syncing winit, EGUI, WGPU, the binder between GPU and EGUI, and EGUI libs like for file dialogs has been a pain. It gives me anxiety thinking about upgrading versions. That said... the teams are sometimes shockingly fast about syncing their UIs. It is when winnit or WGPU etc make big breaking changes (Often from accumulation over time) where things get hairy!
The wgpu/winit/egui churn is a headache. It's worse if you're doing 3D work. Too many crates want to own the event loop. "We're a framework now!"
I'm dreading the "upgrade" from wgpu 24 to wgpu 29. I stayed with wgpu 24 for a year so I could get work done. Now I have to fix three programs and all their tests and examples.
> It is when winnit or WGPU etc make big breaking changes (Often from accumulation over time) where things get hairy!
Winit has had so much churn over time, I hope they settle down at some point.
I can pretty much guarantee that if I try to build a project from 3+ years ago, the old version of winit will not compile on my Mac, and the new version of winit will have a completely different API surface.
Wait until you try Device Events on certain newer Linux versions. You might be in for a surprise, of which is no fault of Winit.
le sigh