This checks out. My leading mental model to explain this mismatch is that the critique has been from people who are expecting Mac idioms, which I can't speak to. Window and Linux GUI look/feel are fragmented as-is.

So long as the web views provide for accessibility (and thus UI automation), this sounds perfectly reasonable for the majority of applications.

Speaking of which, my dream is an "HTML light" standard with a subset of functionality specifically designed for local UI use, ideally with lightweight non-browser engines supporting this standard shipping with all major OS platforms as shared system components.

We had browsers that ran on systems with 8 MB RAM, after all, and while it's not a fair comparison, there's no technical reason why a system with three orders of magnitude more RAM should struggle to run more than a handful of applications merely because they use HTML and JavaScript for rendering.

> perhaps limited experience

New rule: Programmers with limited UI experience (that includes myself) should abstain from weighing in on what UI designers and programmers need.

To the limit that any Winit-based app is. Which is to say it builds and runs, and there is basic touch and text input support. But system integration is pretty limited.

It's absolutely in good faith. There are two kinds of GUI framework in Rust:

- Those people have poured consistent time and effort into over a period of years

- Those people vibe code into existence in a couple of weeks and typically abandon after a few months.

Nobody wants to waste their time on the latter, so I am pointing people to the former. Yes, mine is one of them, but that doesn't make it bad faith, it just means I know what I'm talking about.

> 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.

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

No, a DSL only needs to be better than the language itself to write a layout in. UI is a whole different beast than anything else, where deep nesting is common, layouts flow in many ways, and more. Rust is simply not appropriate to make that pleasant.

Take a simple layout like you'd declare it in Kotlin using Compose:

    @Composable
    fun GreetingScreen(title: String, onBack: () -> Unit) {
        var count by remember { mutableStateOf(0) }
        val scope = rememberCoroutineScope()

        Column(Modifier.fillMaxSize()) {
            Surface(Modifier.weight(1f)) {
                 Text("Count: $count", style = TextStyles.h1)
            }

            Button(onClick = onBack) {
                 Button(onClick = { count++ }) { Text("+1") }
                 Button(onClick = {
                    scope.launch {
                        delay(1000)
                        count++
                    }
                 }) { Text("+1 later") }
            }
        }
    }

In pure rust ?

    pub fn counter_screen(ui: &mut Composer, on_back: Rc<dyn Fn()>) {
        let count = remember(ui, || 0_i32);

        column(ui, Modifier::new().fill_max_size(), {
            let count = count.clone();
            let on_back = Rc::clone(&on_back);
            move |ui, col| {
                surface(ui, Modifier::new().weight(col, 1.0), {
                    let count = count.clone();
                    move |ui| {
                        let label = format!("Count: {}", *count.lock().unwrap());
                        text(ui, TextProps {
                            value: &label,
                            style: Some(&TextStyles::H1),
                            ..Default::default()
                        });
                    }
                });

                row(ui, Modifier::new(), {
                    let count = count.clone();
                    move |ui, _row| {
                        button(ui, ButtonProps {
                            on_click: {
                                let count = count.clone();
                                move || count.update(|n| *n += 1)
                            },
                            enabled: true,
                            modifier: Modifier::new(),
                        }, |ui| text(ui, TextProps { value: "+1", ..Default::default() }));

                        button(ui, ButtonProps {
                            on_click: {
                                let count = count.clone();
                                move || {
                                    let count = count.clone();
                                    spawn(async move {
                                        sleep(Duration::from_secs(1)).await;
                                        count.update(|n| *n += 1);
                                    });
                                }
                            },
                            enabled: true,
                            modifier: Modifier::new(),
                        }, |ui| text(ui, TextProps { value: "+1 later", ..Default::default() }));
                }
            });

            button(ui, ButtonProps {
                on_click: { let on_back = Rc::clone(&on_back); move || on_back() },
                enabled: true,
                modifier: Modifier::new(),
            }, |ui| text(ui, TextProps { value: "Go back", ..Default::default() }));
        }
    });

What a delicious piece of trash. Since you've said no macros, you're carrying an additional variable everywhere (Composer is a Compose system, but you have the same thing in every UI library that does the same. Call it Context, whatever you want). You have shitty lambdas that need to pass the scope too (because Modifier.weight() only works on a ColumnScope). You have no named parameters, and the only way you would would be crap like having a ButtonProps struct. You have impl Fn() + 'static written in your code. And then if you start to want to do some actual work like "clicking on the button increases a counter", you're suddenly spamming Arc::clone, |move| Rc's everywhere in your code because Rust is simply not a good language for UIs.

(And if you want to go the old school way of simply managing yourself a widget tree, good luck, not only is it always full of bugs, it's also an unmaintainable garbage fire.)

Clojure is not a good language for DSLs either, and the post you've linked is just jerking itself off saying "look i can convert some clojure into the exact bash equivalent by only changing one thing" when it's the exact reason why every single clojure project ends up reimplementing the wheel twelves times and is a piece of shit unmaintainable kludge of whatever code the local genius wanted to commit in this morning. Good languages have constraints.

So yes: DSLs _always_ offer a better alternative. QML is a good DSL, and using Javascript is not the reason why.

Hmm, I see, thanks for the correction