> Experience has shown us that an immediate mode API is the only sane way to program GUI applications
I wonder how long till they pivot away from this belief. I feel like everyone in UI goes through this phase as some point, but in the end it doesn't scale to truly complicated UI
hsn915•Jul 12, 2026
It's the only thing that can scale to complicated UI
gen2brain•Jul 12, 2026
What does "scale"even mean in UI context? 10 or 100 controls in app makes difference how exactly? Retained apps redraw when needed, they are idle most of the times. How redrawing every frame helps to scale?
cosmic_cheese•Jul 12, 2026
Yeah. Based on my personal experience I think some kind of hybrid of old-school imperative retained and declarative retained, both with granular reactivity is probably the correct balance for "serious" high-utility desktop applications. Declarative approaches are great for smaller components but become a nightmare for anything much more complex than a relatively simple mobile app while imperative requires a lot of extra legwork at the component level, and as I understand (which may be incorrect) immediate mode makes certain types of optimization more difficult.
lioeters•Jul 12, 2026
In my experience, it's the opposite. Immediate mode GUI, or at least a functional and declarative approach, is the only way I've seen it scale well. It's more modular and scale-independent. On the other hand, retained mode, or imperative/OOP approach to state management, becomes complicated and monstrous quickly; it's the dominant style and can be made to work OK, but typically hellish to maintain or develop beyond a certain scale.
Admittedly I'm simplifying too much and conflating paradigms. My preference is something like "functional core, imperative shell" or maybe "immediate-mode core, retained-mode shell" if that makes sense.
it's very hard. These “change the entire world” commits make for a history that is impractical to follow for a human, and therefore of little interest to me.
hsn915•Jul 12, 2026
This is a publish-only mirror repo.
The commit history is the publish history, not the work history.
weare138•Jul 12, 2026
Where's the actual repo then?
lietuvis•Jul 12, 2026
I'm assuming you're the author, why not publish everything?
em-bee•Jul 12, 2026
that doesn't make much sense. why go out of your way to publish a selected history instead of the whole work?
rowanseymour•Jul 12, 2026
I think a challenge for a vibe coded library to gain adoption is if there is a lack of human time investment in its creation, how do we know there will be investment in its maintenance?
bitwize•Jul 12, 2026
Source is the new binary. Specs and requirements are where the engineering is happening now. Of course, this was anticipated in 1971 with the creation of the very successful PRIDE methodology, but it's taken a few decades, and a complete devaluation of their profession due to AI, for programmers to catch up.
I understand the core is the layout engine and a component library? Does the rendering somehow benefit from GPU?
I recently had a good experience creating custom UI based on ebitengine — also a cross-platform Go engine. As it is a game engine, it has this built in game drawing loop, GPU-accelerated, with some cross-platform kb/mouse input handling. And this feels like a good platform to build the layout engine and components on top of. Have you ever considered this? Or how does your approach compare to that of ebitengine? Did you try (and do you position) your library to build custom UI for some underpowered computers such as Raspberry Pi?
roncesvalles•Jul 12, 2026
Wails is another cross-platform GUI framework in Go: https://wails.io/
thisislife2•Jul 12, 2026
Wails is more like Tauri (Rust) - https://tauri.app/ - both use a WebView to render the frontend.
ahriad•Jul 12, 2026
How it compares to Fyne?
5701652400•Jul 12, 2026
cross-platform is overstatement.
can I run it on Android? iOS?
no? then 99.999999% of real world users cannot access it. and if it is desktop oly, what is the point? it is no better than web.
cosmic_cheese•Jul 12, 2026
The needs of desktop and mobile are different enough that it's extremely difficult to build a UI framework for both that doesn't seriously compromise one paradigm or the other.
I would argue it's one of the main reasons why frameworks like Flutter stuggle with widespread adoption on desktop — it was conceived primarily as mobile-oriented, and so on desktop you're stuck with half-baked third party components for essentials such as datagrids and tree views. WinUI with its mobile heritage in UWP suffers similar problems.
GTK + Adwaita tries to straddle the fence and produces a subpar experience on both sides. Desktop data density is terrible due to mobile-minded button sizes and margins (big touch targets, bloated whitespace to make inadvertant touch interactions less frequent) and desktop-oriented widgets like tree views feel out of place on mobile.
5701652400•Jul 12, 2026
so it is not cross-platform? or all available platforms are... desktop.
serious vibes of shortcuts and avoiding real hard work that brings real value.
comex•Jul 12, 2026
It is still meaningfully cross-platform to support all 3 major desktop platforms rather than just one.
DANmode•Jul 12, 2026
Web is fantastic.
oooyay•Jul 12, 2026
> Immediate mode API in the true sense: you never need to maintain UI widgets or sync your data with widget state.
The following are known issues and limitations that we plan to tackle:
Large text blocks will kill responsiveness! Use the LargeText widget.
The widget catalog is aimed at developer tooling, not general consumer polish: no rich text, tree widget, or date picker yet.
There is no robust theming system. Some widgets take an accent color; custom button styles mean implementing your own (the stock Button is a usable reference). Styling can still be verbose at times.
Are these statements compatible?
nickcw•Jul 12, 2026
I had a look through the code to see how it manages not to use a pile of C libraries with cgo like other Go GUI libraries.
The answer is platform dependent:
Windows loads the relevant DLLs by hand and calls them. This is a well established technique in Go programs and due to the super stable DLL interface works well.
Linux has an x11 and Wayland backends and these implement (through a library) the wire protocols directly in Go which is nice and will make cross compilation and distribution easy.
macOS does appear to use cgo to access the cocoa libraries. macOS doesn't like statically linked Go programs anyway though as they don't use system name resolution so this isn't a bad compromise, but will mean macOS stuff needs to be built on macOS I think.
I didn't see Android or iOS support.
A nice innovative approach to GUI building. Since the lowest common denominator for the backends is an RGBA buffer, this will bypass all accessibility things the OS provides.
The above gleaned after a few minutes reading the source so may not be 100% accurate.
irq-1•Jul 12, 2026
> Mobile is under consideration (no decision yet). If it is supported, it will be limited to utility-style apps — not games or rich multi-touch experiences.
No Multiple Windows so even desktop apps will be limited to "utility-style apps".
I compiled and ran the process_monitor example on linux: it works, compiles fast and is about 10mb. Also cross-built for windows and it's 8.4mb. Can't build for macos/arm64
(Under wine the windows exe doesn't render text. weird.)
irq-1•Jul 12, 2026
examples/process_monitor$ GOOS=darwin GOARCH=arm64 go build
true to that. looks like AI took shortcuts and avoided real work and real hard problems. might as well just flip a random bits for cpu hours.
Reubend•Jul 12, 2026
> What is it that matters for "immediate mode"? Is it that the UI renders everything every frame? No. It's that you build the UI by describing what it should look like everyframe, based only (or mostly) on the data. This is why React won...
I don't think that's why React got so popular. React popularized unidirectional data flow, which is different than immediate mode rendering. This readme file seems to conflate the two of those.
Now that I think of it, couldn't one argue that React itself is a retained mode UI, since it choses which components to re-render and which not to?
lietuvis•Jul 12, 2026
Super vibe coded project still uses an LRU cache (github.com/dboslee/lru v0.0.1) as a dependency, this is exactly the things these llms were supposed to solve right, why the hell do people still add these 100 lines dependencies in their projects?
tptacek•Jul 12, 2026
This looks better than the other native Go GUI frameworks. Frameworks like these are a really good target for coding agents: the biggest impediment to building a new UI framework is the sheer amount of meticulous grunt work needed. So, sure, I'm on board with the idea of languages not normally a perfect fit for native UI work getting solid, generated frameworks.
But: what's the real advantage at this point to having frameworks like these? I can get arbitrary SwiftUI interfaces built very quickly, with a lot of attention to macOS (for instance) idiom, and an automatically generated interface between the SwiftUI app and Go. That works pretty great. Why take the UX hit at all?
13 Comments
I wonder how long till they pivot away from this belief. I feel like everyone in UI goes through this phase as some point, but in the end it doesn't scale to truly complicated UI
Admittedly I'm simplifying too much and conflating paradigms. My preference is something like "functional core, imperative shell" or maybe "immediate-mode core, retained-mode shell" if that makes sense.
https://github.com/wolfpld/tracy
However, when the commit history has stuff like
it's very hard. These “change the entire world” commits make for a history that is impractical to follow for a human, and therefore of little interest to me.The commit history is the publish history, not the work history.
https://www.modernanalyst.com/Resources/News/tabid/177/ID/50...
and https://web.archive.org/web/20240422044352/http://www.phmain...
https://patch.com/florida/palmharbor/50-years-pride has the meaning "an acronym for "PRofitable Information by DEsign - through phased planning and control."
I recently had a good experience creating custom UI based on ebitengine — also a cross-platform Go engine. As it is a game engine, it has this built in game drawing loop, GPU-accelerated, with some cross-platform kb/mouse input handling. And this feels like a good platform to build the layout engine and components on top of. Have you ever considered this? Or how does your approach compare to that of ebitengine? Did you try (and do you position) your library to build custom UI for some underpowered computers such as Raspberry Pi?
can I run it on Android? iOS?
no? then 99.999999% of real world users cannot access it. and if it is desktop oly, what is the point? it is no better than web.
I would argue it's one of the main reasons why frameworks like Flutter stuggle with widespread adoption on desktop — it was conceived primarily as mobile-oriented, and so on desktop you're stuck with half-baked third party components for essentials such as datagrids and tree views. WinUI with its mobile heritage in UWP suffers similar problems.
GTK + Adwaita tries to straddle the fence and produces a subpar experience on both sides. Desktop data density is terrible due to mobile-minded button sizes and margins (big touch targets, bloated whitespace to make inadvertant touch interactions less frequent) and desktop-oriented widgets like tree views feel out of place on mobile.
serious vibes of shortcuts and avoiding real hard work that brings real value.
https://judi.systems/shirei/
Known Issues & Limitations
The following are known issues and limitations that we plan to tackle:
Are these statements compatible?The answer is platform dependent:
Windows loads the relevant DLLs by hand and calls them. This is a well established technique in Go programs and due to the super stable DLL interface works well.
Linux has an x11 and Wayland backends and these implement (through a library) the wire protocols directly in Go which is nice and will make cross compilation and distribution easy.
macOS does appear to use cgo to access the cocoa libraries. macOS doesn't like statically linked Go programs anyway though as they don't use system name resolution so this isn't a bad compromise, but will mean macOS stuff needs to be built on macOS I think.
I didn't see Android or iOS support.
A nice innovative approach to GUI building. Since the lowest common denominator for the backends is an RGBA buffer, this will bypass all accessibility things the OS provides.
The above gleaned after a few minutes reading the source so may not be 100% accurate.
https://judi.systems/shirei/
No Multiple Windows so even desktop apps will be limited to "utility-style apps".
I compiled and ran the process_monitor example on linux: it works, compiles fast and is about 10mb. Also cross-built for windows and it's 8.4mb. Can't build for macos/arm64
(Under wine the windows exe doesn't render text. weird.)
I don't think that's why React got so popular. React popularized unidirectional data flow, which is different than immediate mode rendering. This readme file seems to conflate the two of those.
Now that I think of it, couldn't one argue that React itself is a retained mode UI, since it choses which components to re-render and which not to?
But: what's the real advantage at this point to having frameworks like these? I can get arbitrary SwiftUI interfaces built very quickly, with a lot of attention to macOS (for instance) idiom, and an automatically generated interface between the SwiftUI app and Go. That works pretty great. Why take the UX hit at all?