Raph Levien, who's behind Druid and Xilem (<a href="https://raphlinus.github.io/rust/gui/2022/05/07/ui-architecture.html" rel="nofollow">https://raphlinus.github.io/rust/gui/2022/05/07/ui-architect...</a>) UI frameworks, recently gave a talk about very similar issues. Slides here:<p><a href="https://docs.google.com/presentation/d/1P8Su5mZSYkfZ1A9mPAaKag-vtXmVD8nUBD7Ym-pfwJM/edit?usp=sharing" rel="nofollow">https://docs.google.com/presentation/d/1P8Su5mZSYkfZ1A9mPAaK...</a>
I gave up and started using Flutter with flutter_rust_bridge for business logic. I'm convinced that UI development from scratch simply cannot happen without a large company backing the project, giving it time and money. Flutter took over ten years and likely millions of dollars. HTML, CSS, and JS / TS? Likely billions.<p>This is because simply building the UI toolkit itself is usually not a prime motivator for a startup, they want to work on their differentiating features, not on reinventing the wheel. Of course, if the startup is a text editor or other such UI heavy app, then it may make sense to reinvent the UI wheel. Figma showed this successfully, and perhaps Zed and Warp might, too.
Recommended reading for everyone that doesn't get how traits are just yet another kind of OOP.<p>"Component Software: Beyond Object-Oriented Programming"<p><a href="https://www.amazon.de/-/en/Clemens-Szyperski/dp/0201745720" rel="nofollow">https://www.amazon.de/-/en/Clemens-Szyperski/dp/0201745720</a><p>"Authoring ActiveX with VB 6"<p><a href="https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/aa262304(v=vs.60)" rel="nofollow">https://learn.microsoft.com/en-us/previous-versions/visualst...</a><p>"Traits - Composable Units of Behavior"<p><a href="https://scg.unibe.ch/research/traits" rel="nofollow">https://scg.unibe.ch/research/traits</a><p>"Working with Protocols"<p><a href="https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithProtocols/WorkingwithProtocols.html" rel="nofollow">https://developer.apple.com/library/archive/documentation/Co...</a>
I haven't done any UI work in Rust, have used the language sparingly on the side.<p>But while reading the article, I was thinking "You're modelling the tree wrong! The memory layout doesn't need to know that it is a tree!" - gladly we came to the same conclusion.<p>The funny thing with this pattern is that Rust is much more loose when it comes to modelling with hashmaps and vectors. You are essentially creating user-space references and maintaining them with your own logic.<p>You're basically circumventing the borrow checker, but also a lot of other problems as you encapsulate the maintenance of these references within your tree / graph data structure.<p>But in a sense it's cheating! When you give me a key to a hashmap, do _I_ know whether the thing is there?
Maybe it turns out web and electron UIs took over the world because web technologies are just a better way of building UIs, and everybody who tries them in earnest realizes it.<p>How about "Every GUI toolkit out there trying to avoid using web tech is going to end up implementing a half-baked implementation of CSS", to coin a phrase.
I'm confused by the discussion of OO. Just use an enum, aka algebraic data type, if you want control over the data. You can build an extension point into the ADT for user defined components, if that is desirable. The tradeoffs of OO style vs FP style vs having-your-cake-and-eating-it aka the expression problem are well studied. (This comment is a bit cryptic. Sorry. Don't have much time right now. Might return later.)<p>My experience using ECS in bevy is it feels like fancy spaghetti code. I'm not convinced it's a great approach, at least on the small scale I'm working at.
As a relatively old person, I've had a few experiences of waiting for my favorite niche language to finally get a decent GUI library. In my experience, it never happens. It's just too much work. Only the most popular few programming languages in any given moment have usable GUI options. Even something as comparatively mainstream as Go lacks a good GUI story.
Interesting that they are working with one of the Zed people. I’ve been wondering about the Ui framework they use. Opening up this framework could invite a lot of attention since they are dogfooding it in a (imho) solid product.
UIs are inherently about state, and a lot of state is hard in Rust. The big 'tree of state' is just awkward.<p>UIs are inherently async and event drive, it's callbacks over callbacks, again, harder in rust.<p>UIs have a lot of detail. A little screen has a lot of hidden bit of small complexity.<p>Rust is a heavy language that wants to treat every line of code as an existential security threat and performance.<p>It's really not the right tool.
Perhaps the most obvious answer is that it is may not be the appropriate language for that use case? It is like suggesting to use Solidity or Assembly to build the UI for your app.
Is the challenge really Rust’s design? Or is it an ongoing case of best is the enemy of good? It seems like every UI toolkit we see is another attempt at The Perfect UI Paradigm instead of just being Rust bindings for fltk or whatever.<p>(Oh hey that’s a thing! <a href="https://www.fltk.org/articles.php?L1771" rel="nofollow">https://www.fltk.org/articles.php?L1771</a> )
the people over at <a href="https://zed.dev" rel="nofollow">https://zed.dev</a> have done a great job. do they use something special?
This is a white whale for a lot of people.<p><a href="http://www.areweguiyet.com" rel="nofollow">http://www.areweguiyet.com</a> (seems updates to this thing have stopped?)<p><a href="https://blog.logrocket.com/state-of-rust-gui-libraries/" rel="nofollow">https://blog.logrocket.com/state-of-rust-gui-libraries/</a><p>The state of TUI on the other hand is better (posted recently, there are a few others):<p><a href="https://github.com/tui-rs-revival/ratatui">https://github.com/tui-rs-revival/ratatui</a><p><a href="https://news.ycombinator.com/item?id=35173866" rel="nofollow">https://news.ycombinator.com/item?id=35173866</a>
First of all, it is great that there is are ongoing attempts to build a new approach at creating UI with Rust. I hope it turns out into several competing frameworks with different target audiences.<p>I believe, you are confusing performance with responsiveness. Where a traditional mutating UI framework would happily update a widget and keep CPU idle most of the time, your approach keeps wasting processor cycles to build widget tree on demand for rendering. This could be unacceptable for devices with an energy budget (IOT, for example). So, your approach works well where loss of efficiency is not critical.
Rust sucks for UI, async services, language runtimes, and a couple other things because memory usage patterns of those apps don't favor Rust's memory/safety model? I mean, who would've thought? Rust was introduced as a "systems" programming language after all, and doesn't have to be everything to everybody. Rust isn't even extensively used within its originating project/org (FF/Moz).<p>IMHO, Rust's anti-C/C++ narrative also starts from wrong assumptions: in traditional Unix, what you're doing with C (apart from the OS) is implement the runtime of higher-level languages, but no-one has bothered to implement JavaScript or other engine with GC (let alone JIT) because committing to Rust's one-size-fits-all borrow checker just means the result can't be competitive. malloc()/free() also sucks, but its problems are only amplified by today's desire for single-process multithreaded or async backends; for one-shot commandline apps or process-per-request backends OTOH, there hasn't been much of a problem.