rust-sciter VS egui

Most GUI apps don't need what Qt provides though. They mostly need stability and cross-platform support, so ... they should start with something like Tauri or Sciter, and if there is something they need natively they will be in a much better situation to pick their poison.

https://github.com/tauri-apps/tauri uses OS provided WebView

https://github.com/sciter-sdk/rust-sciter uses Sciter

I seriously advise against using rust-sciter. It uses a lot of unsafe code, some of which is invalid and directly causes Undefined Behavior; see for example issue #114. rust-sciter's author doesn't seem to have any interest in fixing those. Besides, the code is highly unidomatic and looks like it's been written to resemble C++ – this is in itself not wrong, but always a red flag.

I use https://github.com/sciter-sdk/rust-sciter in my project https://github.com/rustdesk/rustdesk

I use Egui, in a game-type application.

I'm a bit concerned with Egui gaining in popularity for general purpose GUI applications. It's leading to feature bloat, and probably more overhead. The stated goal originally was that Egui should use less than 1% of main thread frame time.

Originally, Egui was completely one pass. The API looks more general than that; you can align things against the bottom or right, and get things above or to the left to adjust. But originally, that didn't work. You pretty much had to lay out widgets down and to the right. This is fast and simple. Lots of stuff didn't work, such as scrolling text boxes with line wrap.

But users doing ordinary GUI work are demanding more and more layout features, and won't stop until they get browser level layout. Overhead is increasing.[1] This is a problem in Rust game land, which is tiny. At some point, someone may need to fork Egui and create Egui-lite.

[1] https://github.com/emilk/egui/issues/7059

That's very kind -- let's hope the legal profession feels the same way. It's certainly inspired by VS code. It's using egui (https://github.com/emilk/egui) under the hood. Big hats off to Emil Ernerfeldt and the team at rerun (https://app.rerun.io/) for the incredible work on a great immediate mode GUI library.

Thank you for linking your project—that looks really cool! I saw you also implemented a pan-and-zoom area. We are currently working on moving Rerun's implementation to egui [0], so maybe keep an eye on that.

It would be super cool to have layered graph drawing in (Sugiyama-style) in Rerun too. The tricky–but super interesting–challenge that we face is that our layout implementations need to be consistent across timestamps if the underlying structure of the graph changes, which is why we initially chose a force-based layout approach. There, the time-varying aspect is handled naturally by the simulation.

The very interactive nature of Rerun also poses more restrictions on the implementation of our algorithms: re-layouts ideally need to be fast, to produce visualizations quickly, especially when scrubbing the timeline.

I still hope we can rid you of some of the todos ;).

[0](https://github.com/emilk/egui/pull/5505)