Ribir: Non-Intrusive GUI Framework for Rust/wasm
Postedabout 2 months agoActiveabout 2 months ago
github.comTechstory
calmmixed
Debate
60/100
RustGUI FrameworksWasm
Key topics
Rust
GUI Frameworks
Wasm
The Ribir GUI framework for Rust/WASM is introduced, sparking discussion on its design choices and comparison to other frameworks.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
56m
Peak period
4
0-3h
Avg / period
2.2
Comment distribution24 data points
Loading chart...
Based on 24 loaded comments
Key moments
- 01Story posted
Nov 7, 2025 at 3:26 PM EST
about 2 months ago
Step 01 - 02First comment
Nov 7, 2025 at 4:22 PM EST
56m after posting
Step 02 - 03Peak activity
4 comments in 0-3h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 9, 2025 at 5:08 PM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45850671Type: storyLast synced: 11/20/2025, 7:50:26 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I like the idea of using macros to clean syntax; am writing some for EGUI right now to make colored text easier.
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 {
}```
Would be this in QML:
```
ColumnLayout {
}```
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...
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)
This is how I implemented my last Angular project, works fine for non-trivial tasks.
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).
There are parts of the rust ecosystem that are only built for trivial apps (And demos, blog posts etc), but GUI is not one.
And quite amazing work, so thank you for sharing. This will be fun to dive into. I'm generally liking egui but have just recently been using it, so I'm still new at it.
- 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.