Shirei - Cross-platform immediate mode GUI framework in native Go
Show HN: Shirei, cross-platform GUI framework in native Go
Shirei is a practical, cross-platform GUI framework built entirely in native Go, designed for developers seeking a modern immediate mode interface with a familiar flexbox layout model. It eliminates the need for complex bindings or external dependencies by leveraging native backends for Windows, macOS, and Linux, including Wayland and X11 support. With features like a built-in software renderer, robust text input handling, and IME support, Shirei empowers engineers to build responsive desktop applications quickly while maintaining the simplicity and performance of the Go ecosystem.
A practical, immediate mode GUI framework in native Go featuring a flexbox model and native backends for seamless cross-platform development.
- nickcw
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.
- TazeTSchnitzel
I will admit that I don't like vibecoded things, but perhaps I must stomach that AI will be writing a lot in this brave new era.
However, when the commit history has stuff like
v0.5.0: native backends, software renderer, text input, IME
Co-authored-by: Claude <[email protected]>
Co-authored-by: Codex <[email protected]>
Co-authored-by: Composer <[email protected]>
Co-authored-by: Cursor Grok 4.5 <[email protected]>
377 files changed
Lines changed: 62423 additions & 2871 deletions
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.
- swiftcoder
> 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
- Reubend
> 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
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?