Comment by noodletheworld

17 hours ago

> List is hand-picked list, ordered by crates.io downloads.

O_o

Just say it’s a hand picked list of ones you like and why.

Do you like them? Have you used them?

I found iced to be unreliable (couldn't reliably render basic widgets); slint overly relies on their DSL and honestly seemed to be moving away from rust; and GPUI felt sloppy. That was my personal “lets try rust gui” journey before I went; nope, guess we’re doing native ui and a shared rust core.

This is just a random list of stuff; I can't tell if you think they're all good (I dont) or just copy pasted chatgpt output.

For each one: why is it on the list? Do you like it? Why do you think, for example, slint, deserves to be on the list, when you dont even write the ui scripts in rust?

5 comments

noodletheworld

Reply
ogoffart  11 hours ago

(Slint author here) Slint is written in Rust, and Rust API is at its core. That's not changing. What's wrong with the DSL? the UI is described in the DSL, the application logic in Rust. I wrote about why here: https://slint.dev/blog/domain-specific-language-vs-imperativ...

What gave you the impression we're moving away from Rust?

  • noodletheworld  8 hours ago

    The website developer docs.

    Look, bluntly, you can’t have your cake and eat it to. Either it’s a rust library or it’s not.

    If you’re not writing your ui in rust, then even if parts of it are implemented in rust, it’s not a rust ui library any more than a js library like calls a c backend is a c library.

    I really really wanted to like slint and absolutely did not.

    > Domain Specific Languages like Slint offer a great alternative to traditional GUI toolkit APIs.

    No they don’t.

    If you can arbitrarily assert something so can I.

    A DSL needs it clear the minimum bar of “why is this not just using a real programming language?”.

    UI programming is tricky, but declarative approaches have almost universally failed, because there’s always some edge case logic that needs a full programming language to handle it.

    The few UI DSLs that Ive seen work (eg. blueprint) exist a) as stand alone languages, and b) fill a niche that an existing language doesn’t.

    What does your DSL do that is unique? Why was using js like qt quick not good enough? Why not just use rust?

    The issue I have with it is you’ve never articulated why it exists.

    Good DSLs like those implemented using clojure (1) are additions to the language that can natively be mixed into the existing language ecosystem.

    You could have done the same in rust using proc macros; but instead you’ve chosen (as far as I can tell) to chase the non-rust UI market with a custom DSL.

    Well.. you want an opinion? There you go. I don’t like slint, sorry. It’s not a rust UI library. It just happens to be implemented in rust, in my opinion.

    (1) - https://clojure-doc.org/articles/cookbooks/growing_a_dsl_wit...

    • ogoffart  8 hours ago

      > Either it's a rust library or it's not.

      It is one. Your app is a Rust program that depends on a crate. The UI compiles to Rust code, and we also have the `slint!` proc macro.

      > there's always some edge case logic that needs a full programming language

      Right, and that language is Rust. The DSL only describes the GUI. You operate it from Rust.

      > Why was using js like qt quick not good enough?

      QML was the inspiration. I worked on Qt and wrote QML bindings for Rust before (qmetaobject-rs). Slint is a new take on it, compiled ahead of time, no GC, strongly typed.

      1 reply →