Ribir: Non-intrusive GUI framework for Rust/WASM(github.com)
77 pointsby adamnemecek3 days ago4 comments
  • rubymamis3 days ago
    > 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
        }
    }

    ```

  • iamsaitam2 days ago
    It seems Rust has now achieved the glorious status of JS's "there's a new UI framework coming out every day"
    • enricozb2 days ago
      It's kind of an exploratory phase for what works sensibly with Rust's borrow checker, especially since most UI libraries/frameworks really rely on a GC.
    • swiftcoder2 days ago
      And none of them really work for non-trivial apps! Welcome to hell
      • the__alchemist2 days ago
        I'm using EGUI for a all-in-one molecular viewer / CAD. It's like PyMol, Coot, GROMACS and VMD in one. If this is trivial, I would like to see what you consider to be non-trivial!

        There are parts of the rust ecosystem that are only built for trivial apps (And demos, blog posts etc), but GUI is not one.

        • swiftcodera day ago
          Look, your application is certainly impressive, but it's extremely basic from the perspective of a UI toolkit.

          - It's not multi-window, so it doesn't have to integrate with a bunch of the OS window management affordances.

          - It doesn't have any complicated typesetting or rich text editing, so you get to pretty much ignore that whole mess.

          - Since it's a very visual tool that doesn't make much sense for blind folks, you haven't invested much in accessibility support.

          - And so on...

          This is a great use case for EGUI, and EGUI works great in this sort of UI-lite scenario. Whereas I wouldn't want to use it to implement something on the complexity of VSCode/Excel/FireFox.

        • bmitca day ago
          Is that application by any chance open source?
      • mdhb2 days ago
        It’s just not actually a very good language for writing UIs in compared to say Dart, Swift or Kotlin.
        • swiftcoder2 days ago
          Yeah, it turns out the popular UI paradigms rely on a lot of mutable state
          • brabel2 days ago
            A UI is by definition a view of some mutable state.
            • swiftcoder2 days ago
              The view part would be fine, the problem is updating the state. In a language which discourages shared mutability, most of the solutions are not terribly ergonomic.

              You either end up needing to:

              - handle all your state via interior mutability (i.e. Arc<RefCell<_>>)

              - use a reducer (i.e. the state blob is immutable during rendering, updates are deferred via events that are delivered between frames)

              - or invert the relationship between state and view (i.e. immediate-mode) which comes with it's own implementation challenges (caching immediate mode views is hard)

              • tcfhgj2 days ago
                > - use a reducer (i.e. the state blob is immutable during rendering, updates are deferred via events that are delivered between frames)

                This is how I implemented my last Angular project, works fine for non-trivial tasks.

            • galangalalgol2 days ago
              Rust is fine with mutable state, it just strongly encourages that it not be shared. Egui seems fine, we've used it to good effect.
          • littlestymaar2 days ago
            The most popular language by far used for writing UI is JavaScript, and the go to framework this day (React) doesn't use that though.

            From the various experiments that popped up over the years, it's pretty clear that the React way works pretty well for Rust, but it's also too slow to be desirable for Rust (what's the point of using Rust for UI if you're going to have web-like performance).

            And then again, making a half decent UI framework is a gigantic task, there's just not a whole lot of languages with a decent UI story at all, no matter what's the paradigm of the programming language. (And if you want a language for cross-platform UI, I'd argue that the only one that ticks the box is JS with React in Electron and React Native, and it's not even truly a single framework).

  • Blackarea2 days ago
    > 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...

    • Klonoar2 days ago
      Uh, what? The second DSL example is just pure Rust.
      • Blackarea2 days ago
        > btn.finish().with_child(pipe!($read(cnt).to_string()))
        • Klonoar12 hours ago
          That second macro isn’t for constructing UI, which is the point of the two examples.
  • the__alchemist3 days ago
    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.

    • mwcampbell3 days ago
      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.