FRESH

Hacker News

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

38 points by hsn915

by nickcw

0 subcomment

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.

by TazeTSchnitzel

2 subcomments

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.

by swiftcoder

2 subcomments

> 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

by iafan

0 subcomment

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?

by ahriad

0 subcomment

How it compares to Fyne?

by shinzui

1 subcomments

What a waste of tokens.

by roncesvalles

0 subcomment

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

by 5701652400

2 subcomments

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.

by oooyay

0 subcomment

[dead]