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

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 <noreply@anthropic.com>
  Co-authored-by: Codex <codex@openai.com>
  Co-authored-by: Composer <composer@cursor.com>
  Co-authored-by: Cursor Grok 4.5 <noreply@cursor.com>
  
  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.

> 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

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?

How it compares to Fyne?

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.

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

[dead]