Switching to wgpu as the default is a definite possibility, but something should be said for the simplicity of the glow backend. wgpu is a big beast, which takes more time to compile, and for a lot of eframe users it is simply over-kill.
…but then again, if you want simplicity and fast compiles, I can recommend the egui-miniquad backend. It's not as fully-featured as eframe, but with some love it could definitely get there.
Rerun is still in beta, but we think it’s already good enough to be useful. It is built on wgpu, Apache Arrow, my own egui.rs library, and it also runs as Wasm in the browser.
We just open-sourced Rerun today! It’s still in beta, but we think it’s good enough to be useful. It is built on wgpu, Apache Arrow, my own egui.rs library, and it also runs as Wasm in the browser.
Putting the UI in a canvas elements have some distinct drawbacks (https://github.com/emilk/egui/tree/master/crates/eframe#prob...) but for us it is definitely worth it. Having one unified codebase for our web app and native app, and having it all in Rust, is just amazing.
We're currently working on a 3D renderer based on wgpu (https://github.com/gfx-rs/wgpu) that we will likewise use for both web and desktop.
Good point about the yanking. But yes, there are multiple other problems such as typosquatting and adding malicious code to a patch release. `cargo-crev` and `cargo-vet` are both interesting tools that I'm keeping my eye on.
We are building the frontend of our _application_ in Rust and rendering it to a canvas using egui.rs. For the web site we are using more "traditional" tech, as you've noticed.
I am not a big fan of the complexity of modern web sites (including our own), which is exactly why I created egui. However, it is targeted at web apps, not web sites.