Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 60 posts

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

#21

Post by 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?

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

#22

Post by comex »

5701652400 wrote: post #18
cosmic_cheese wrote: post #15

Earlier quoted context omitted.

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.

It is still meaningfully cross-platform to support all 3 major desktop platforms rather than just one.

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

#23

Post by lioeters »

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

In my experience, it's the opposite. Immediate mode GUI, or at least a functional and declarative approach, is the only way I've seen it scale well. It's more modular and scale-independent. On the other hand, retained mode, or imperative/OOP approach to state management, becomes complicated and monstrous quickly; it's the dominant style and can be made to work OK, but typically hellish to maintain or develop beyond a certain scale.

Admittedly I'm simplifying too much and conflating paradigms. My preference is something like "functional core, imperative shell" or maybe "immediate-mode core, retained-mode shell" if that makes sense.

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

#25

Post by lietuvis »

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.

I'm assuming you're the author, why not publish everything?

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

#26

Post by tptacek »

This looks better than the other native Go GUI frameworks. Frameworks like these are a really good target for coding agents: the biggest impediment to building a new UI framework is the sheer amount of meticulous grunt work needed. So, sure, I'm on board with the idea of languages not normally a perfect fit for native UI work getting solid, generated frameworks.

But: what's the real advantage at this point to having frameworks like these? I can get arbitrary SwiftUI interfaces built very quickly, with a lot of attention to macOS (for instance) idiom, and an automatically generated interface between the SwiftUI app and Go. That works pretty great. Why take the UX hit at all?

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

#27

Post by irq-1 »

nickcw wrote: post #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 dire…

> Mobile is under consideration (no decision yet). If it is supported, it will be limited to utility-style apps — not games or rich multi-touch experiences.

https://judi.systems/shirei/

No Multiple Windows so even desktop apps will be limited to "utility-style apps".

I compiled and ran the process_monitor example on linux: it works, compiles fast and is about 10mb. Also cross-built for windows and it's 8.4mb. Can't build for macos/arm64

(Under wine the windows exe doesn't render text. weird.)

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

#28

Post by bitwize »

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

Source is the new binary. Specs and requirements are where the engineering is happening now. Of course, this was anticipated in 1971 with the creation of the very successful PRIDE methodology, but it's taken a few decades, and a complete devaluation of their profession due to AI, for programmers to catch up.

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

#29

Post by pmontra »

bitwize wrote: post #28
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.…

Source is the new binary. Specs and requirements are where the engineering is happening now. Of course, this was anticipated in 1971 with the creation of the very successful PRIDE methodology, but it's taken a few decades, and a complete devaluation of their profession due to AI, for programmers to catch up.

This PRIDE? https://cio-wiki.org/wiki/PRIDE_Methodology
Post reply on HN