hckrnws

> You can choose to use it (macros) or not.

Yet both examples use macros.

I might still got ptsd from a job where literally all of the rust codebase was written as macros. Since then I avoid them at all costs.

I find the route, that gleam took, way more elegant with squirrel (sqlx-ish) and lustre (elm-like) being examples of what we could have instead. Avoiding language mixing is so important for proper/clean lsp-support - yet macros are a different language as i see it.

As for the rest of this: i also don't see how it's any different from iced, egui etc. but maybe I didn't take the time to check the details...

Uh, what? The second DSL example is just pure Rust.

> btn.finish().with_child(pipe!($read(cnt).to_string()))

> Unlike common object-oriented GUI frameworks, Ribir widgets do not need to inherit a base class or hold a base object. It is a pure composition model

I'm really not sure how this "composition" is any different to the usual inheritance you see in frameworks like QML *in practice*.

This in Ribir:

```

Column {

        align_items: Align::Center,

        item_gap: 12.,

        @H1 { text: "Todo" }

```

Would be this in QML:

```

ColumnLayout {

        spacing: 12

        Text {
                Layout.alignment: Qt.AlignHCenter

                text: "Todo"

                font.pointSize: 17
        }

```

Generally, many forms of inheritance do not compose, but I'm not sure that makes these primitives composable.

How does this compare to EGUI, GPUI, and Slint?

I like the idea of using macros to clean syntax; am writing some for EGUI right now to make colored text easier.

This may not be what you're after, but note that egui and Slint have accessibility support (at differing levels of completeness), e.g. for blind people using screen readers, while Ribir and GPUI do not.