Live data from Hacker News

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

github.com

11–20 of 60 posts

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

#12

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.…

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?

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

#14
> Immediate mode API in the true sense: you never need to maintain UI widgets or sync your data with widget state.

https://judi.systems/shirei/

Known Issues & Limitations

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?

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

#15

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.

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.

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

#16
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.

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

#18

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.

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 essen…

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.

Post reply on HN