IMHO Rust isn't a great language for describing UIs because it is too explicit in places that doesn't need to be for coding a UI. Which is why in Slint (another Rust UI framework) we opted for a DSL. The application logic stays in Rust, but the UI is described in a language designed for it.

Your example would look like this:

    export component Hello inherits Rectangle {
        in property <string> text: "World";
        width: 500px; height: 500px;
        background: #505050;
        border-width: 1px; border-color: blue;
        drop-shadow-blur: 15px; drop-shadow-color: #0008;
        VerticalLayout {
            alignment: center; spacing: 12px;
            Text { text: "Hello, \{root.text}!"; font-size: 20px; color: white; horizontal-alignment: center; }
            HorizontalLayout {
                alignment: center; spacing: 8px;
                for c in [#f00, #0f0, #00f, #ff0, #000, #fff]: Rectangle { width: 32px; height: 32px; background: c; }
            }
        }
    }
    

My experience has been that DSLs don't scale well. For simple things they provide a veneer of ease-of-use but eventually they were an albatross with Chef just as they were with QML and Slint. With both Slint and various Qt bindings for Rust marshalling data between Rust and the UI is painful. With Slint you get the added bonus of things just not yet existing in the DSL. That's a result of both immaturity and a strong focus on mobile at the expense of desktop. But the result is same. gpui has a killer dock widget, QML has the primitives to approximate one, and it's pretty much a no-go with Slint (though there's a third-party dock widget for Slint it's written in C++).

Here's a more idiomatic version of the previous example. IME gpui (and iced) is a lot easier to extend than something with a DSL, and if you check out the gpui example you'll see that gpui provides convenient methods to get consistent styles vs the Slint example where you hardcode widths and sizes. Those hex color abbreviations give me a facial tic every single time.

    use gpui::{black,red,green,blue,yellow,white};

    let Self{text,..} = self;
    
    v_flex()
        .gap_3()
        .bg(rgb(0x505050))
        .size(px(500.0))
        .justify_center()
        .items_center()
        .shadow_lg()
        .border_1()
        .border_color(black())
        .text_xl()
        .text_color(white())
        .child(format!("Hello, {text}!"))
        .child(
            h_flex()
                .gap_2()
                .children(
                    [red(), green(), blue(), yellow(), black(), white()].map(|color|
                        div().size_8().bg(color)
                    )))

> Rust isn't a great language for describing UIs because it is too explicit in places that doesn't need to be for coding a UI.

That's is not about just Rust ... Any domain has its own optimal or sub-optimal language describing it. Criteria of optimality is a bit subjective of course. Like: INI, TOML, YAML, etc. are better (YMMV, again) for user facing configs than JSON or XML and so on.

I think that HTML is better for defining hierarchical UI structures and CSS and CSS selectors are (arguably again) better to define UI styling.

My Sciter[1] was initially using .FRM alike inputs (VisualBasic forms, good for IDE but bad for a human) but I quickly discovered that having styles, structure and code-behind-UI in single PL makes non-manageable mess. So Sciter uses HTML, CSS and JS we all familiar with. Not 100% match of course but good enough.

[1] https://sciter.com

Slint is proprietary though, so that’s a dead end. I’m not going to use something which will inevitably be rug-pulled when you sell to private capital.

isn't that basically QML?

I'm not sure it matters anymore unfortunately. I've vibe coded a few apps using gpui-kit and it works well. It helps that gpui-kit provides a number of high quality components (e.g. the data table is especially good). But even where it doesn't (e.g. log output) Opus 5.5 was able to easily write one that worked perfectly.

It even added ANSI colour support... which I am still on the fence about but it did make the very good point that it means the logging is exactly the same in GUI and CLI mode.