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

31–40 of 60 posts

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

#31

Post by homarp »

pmontra wrote: post #29
bitwize wrote: post #28

Earlier quoted context omitted.

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

PRIDE is the registered trademark of M. Bryce & Associates (MBA)

https://www.modernanalyst.com/Resources/News/tabid/177/ID/50...

and https://web.archive.org/web/20240422044352/http://www.phmain...

https://patch.com/florida/palmharbor/50-years-pride has the meaning "an acronym for "PRofitable Information by DEsign - through phased planning and control."

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

#32

Post by irq-1 »

irq-1 wrote: post #27
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 b…

examples/process_monitor$ GOOS=darwin GOARCH=arm64 go build

    # go.hasen.dev/shirei/cocoabackend
    ../../../gopath/pkg/mod/go.hasen.dev/shirei@v0.5.0/cocoabackend/
    perf_darwin.go:198:11: undefined: softRenderer
    ../../../gopath/pkg/mod/go.hasen.dev/shirei@v0.5.0/cocoabackend/
    perf_darwin.go:208:22: undefined: softRenderer

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

#33

Post by em-bee »

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.

that doesn't make much sense. why go out of your way to publish a selected history instead of the whole work?

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

#35

Post by rootlocus »

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

Is Tracy complicated enough? Because it's imgui.

https://github.com/wolfpld/tracy

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

#36

Post by pancsta »

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…

Theres is another new project which does NOT rely on CGO https://github.com/gogpu/ui Its basically the whole WebGPU implemented in Go. Theres also Gio, but not sure if its still active. CGO is a huge pain…

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

#37

Post by opem »

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.

but if you other ppl to read, use or contribute, they will probably need the "work history" more than a "publish history". because nobody is going to read those big ass commits, specially when unsure about it worthiness.

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

#38

Post by timhh »

rootlocus wrote: post #35
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

Is Tracy complicated enough? Because it's imgui. https://github.com/wolfpld/tracy

That looks quite simple. Think about something like this, a commercial SystemVerilog simulator (this only shows a fraction of the UI).

https://blog.reds.ch/wp-content/uploads/2018/09/questa13.png

Or something like Visual Studio.

Obviously most GUIs are not nearly that complex so immediate mode can get you quite far. Its biggest limitation is that it makes it hard to do some layouts. Your GUI layout becomes dictated by your data dependencies which is quite awkward.

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

#39

Post by bitwize »

homarp wrote: post #31
pmontra wrote: post #29

Earlier quoted context omitted.

This PRIDE? https://cio-wiki.org/wiki/PRIDE_Methodology

PRIDE is the registered trademark of M. Bryce & Associates (MBA) https://www.modernanalyst.com/Resources/News/tabid/177/ID/50... and https://web.archive.org/web/20240422044352/http://www.phmain... https://patch.com/florida/palmharbor/50-years-pride has the meaning "an acronym for "PRofitable Information by DEsign - through phased planning and control."

This is the PRIDE I meant. It's hard to tell if MBA (more recently, M&JB Investment Company) is still a going concern. Milt Bryce's son Tim was keeping the lights on but he died of cancer at the end of 2023.

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

#40

Post by well_ackshually »

timhh wrote: post #38
rootlocus wrote: post #35

Earlier quoted context omitted.

Is Tracy complicated enough? Because it's imgui. https://github.com/wolfpld/tracy

That looks quite simple. Think about something like this, a commercial SystemVerilog simulator (this only shows a fraction of the UI). https://blog.reds.ch/wp-content/uploads/2018/09/questa13.png Or something like Visual Studio. Obviously most GUIs are not nearly that complex so immediate mode can get you quite far. Its biggest limitation is that it makes it hard to do some layouts. Your GUI layout becomes dictated b…

Absolutely zero difficulty redoing this in a react style renderer. The only complexity is being careful with your data dependencies so as to not needlessly rerender.

Each pane is easily isolated, can share data with a view model scoped properly, etc. Writing it in an imperative toolkit is a "oops I forgot to update my data here" kind of hell. Data binding makes it slightly less worse

Post reply on HN