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.
A bit tangential, but since you're using wgpu in your own product now, do you have any plans to switch to using wgpu by default in eframe, and possibly even eliminate glow? I'm just curious; this probably doesn't have any effect on anything I'm working on. Anyway, eliminating the multiple code paths in eframe would be nice.
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.
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.
Thanks for working with me to get AccessKit support integrated.
I should note that the web demo isn't yet accessible, except with the built-in text-to-speech option that can currently only be enabled through the inaccessible UI itself. Not a complaint; just a clarification, since the parent comment mentioned both accessibility and the web demo. Sooner or later AccessKit will have a web platform adapter that will implement the usual parallel-DOM workaround for canvas-based apps.
OK, that's an interesting language feature, but I can't say it's something that I've often wanted to do in C++. Of course C++ does have std::variant and std::any, although I'm not really a fan. I'd tend to (and have) just use a class that contains the variants and an enum to track which one, then setters and getters.
Of course the Rust features being used by that Event type are runtime polymorphism and type introspection, so another obvious C++ approach would be just to use a pointer to a virtual based class including the type, then:
switch (event->type) {
case EvKeyPressEvent:
{
auto kpe - dynamic_cast<KeyPressEvent*>(event)
...
}
break;
}
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.
I'm very curious how well this is working for you in practice, since I've been thinking about what it would look like to share a single Rust UI implementation across a webapp and native apps.
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.