[HN Gopher] Ribir: Non-intrusive GUI framework for Rust/WASM
___________________________________________________________________
Ribir: Non-intrusive GUI framework for Rust/WASM
Author : adamnemecek
Score : 75 points
Date : 2025-11-07 20:26 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| the__alchemist wrote:
| 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.
| mwcampbell wrote:
| 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.
| rubymamis wrote:
| > 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
| }
|
| }
|
| ```
| pshirshov wrote:
| Generally, many forms of inheritance do not compose, but I'm
| not sure that makes these primitives composable.
| mkl wrote:
| To format as code on HN, indent two spaces.
| https://news.ycombinator.com/formatdoc
| Blackarea wrote:
| > 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...
| Klonoar wrote:
| Uh, what? The second DSL example is just pure Rust.
| Blackarea wrote:
| > btn.finish().with_child(pipe!($read(cnt).to_string()))
| iamsaitam wrote:
| It seems Rust has now achieved the glorious status of JS's
| "there's a new UI framework coming out every day"
| swiftcoder wrote:
| And none of them really work for non-trivial apps! Welcome to
| hell
| mdhb wrote:
| It's just not actually a very good language for writing UIs
| in compared to say Dart, Swift or Kotlin.
| swiftcoder wrote:
| Yeah, it turns out the popular UI paradigms rely on a lot
| of mutable state
| brabel wrote:
| A UI is by definition a view of some mutable state.
| galangalalgol wrote:
| 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.
| swiftcoder wrote:
| 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)
| tcfhgj wrote:
| > - 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.
| littlestymaar wrote:
| 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).
| the__alchemist wrote:
| 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.
| enricozb wrote:
| 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.
___________________________________________________________________
(page generated 2025-11-08 23:02 UTC)