Show HN: Shirei, cross-platform GUI framework in native Go

#1

Post by hsn915 » Sun, Jul 12, 2026, 4:55 PM UTC

Show HN: Shirei, cross-platform GUI framework in native Go
github.com

Re: Show HN: Shirei, cross-platform GUI framework in native Go

#2

Post by swiftcoder » Sun, Jul 12, 2026, 5:09 PM UTC

> 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

Re: Show HN: Shirei, cross-platform GUI framework in native Go

#3

Post by TazeTSchnitzel » Sun, Jul 12, 2026, 5:14 PM UTC

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 
  Co-authored-by: Codex 
  Co-authored-by: Composer 
  Co-authored-by: Cursor Grok 4.5 
  
  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.

Re: Show HN: Shirei, cross-platform GUI framework in native Go

#4

Post by hsn915 » Sun, Jul 12, 2026, 5:14 PM UTC

swiftcoder wrote: post #2

> 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

It's the only thing that can scale to complicated UI

Re: Show HN: Shirei, cross-platform GUI framework in native Go

#5

Post by hsn915 » Sun, Jul 12, 2026, 5:15 PM UTC

TazeTSchnitzel wrote: post #3

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 Co-authored-by: Codex Co-authored-by: Composer Co-authored-by: Cursor Grok 4.5 377 files changed Lines changed: 62423 additions & 2871 deletions it's very hard.…

This is a publish-only mirror repo.

The commit history is the publish history, not the work history.

Re: Show HN: Shirei, cross-platform GUI framework in native Go

#6

Post by iafan » Sun, Jul 12, 2026, 5:16 PM UTC

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?

Re: Show HN: Shirei, cross-platform GUI framework in native Go

#7

Post by cosmic_cheese » Sun, Jul 12, 2026, 5:35 PM UTC

swiftcoder wrote: post #2

> 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

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.

Re: Show HN: Shirei, cross-platform GUI framework in native Go

#8

Post by roncesvalles » Sun, Jul 12, 2026, 5:37 PM UTC

Wails is another cross-platform GUI framework in Go: https://wails.io/

Re: Show HN: Shirei, cross-platform GUI framework in native Go

#9

Post by weare138 » Sun, Jul 12, 2026, 5:51 PM UTC

hsn915 wrote: post #5

TazeTSchnitzel wrote: post #3

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 Co-authored-by: Codex Co-authored-by: Composer Co-authored-by: Cursor Grok 4.5 377 files changed Lines changed: 62423 additions & 2871 deletions it's very hard.…

This is a publish-only mirror repo. The commit history is the publish history, not the work history.

Where's the actual repo then?

Re: Show HN: Shirei, cross-platform GUI framework in native Go

#10

Post by gen2brain » Sun, Jul 12, 2026, 5:57 PM UTC

hsn915 wrote: post #4

swiftcoder wrote: post #2

> 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

It's the only thing that can scale to complicated UI

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?