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

51–60 of 60 posts

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

#51

Post by hsn915 »

rowanseymour wrote: post #12
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.…

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?

Most open source projects are abandoned because the author never finds enough time to work on it or can't muster the focus and attention needed.

It is not true that there is "lack" of human investment in the creation of this. If anything, I spent the last two weeks glued to the screen most of the time, to a degree I have never experienced before, building out all the different areas that lead to this release.

I will not mention the monetary investment because it's not the type that matters here.

Attention, which is arguably the most scarce form of investment, was invested in ample amounts.

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

#52

Post by swiftcoder »

well_ackshually wrote: post #40
timhh wrote: post #38

Earlier quoted context omitted.

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

> Absolutely zero difficulty redoing this in a react style renderer

I would not classify a react style renderer as "immediate mode". It has aesthetic similarities with IM GUIs, but ultimately there is a fully retained tree under the hood, that gets diffed/mutated on every update

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

#53

Post by swiftcoder »

hsn915 wrote: post #49
gen2brain wrote: post #10

Earlier quoted context omitted.

What does "scale"even mean in UI context? 10 or 100 controls in app makes difference how exactly? Retained apps redraw when needed, they are idle most of the times. How redrawing every frame helps to scale?

Does "immediate mode" mean the UI refreshes at a constant 60fps rate like a video game, redrawing everything all the time? No. It means that you build the UI by describing what it should look like now, based on the data / state you own, without referencing any existing "widget" object or trying to manipulate it. Scale is not about the number of buttons, but the structure of the data. You have a list of objects, withi…

> In immediate mode, none of that matters. You don't have a parallel widget tree.

No, instead, you need to have your entire dataset in memory, and potentially rebuild your whole tree on every update. This causes quite a lot of problems for out-of-core datasets - you end up needing to maintain proxies for things like items in scrollable lists that aren't loaded into memory yet.

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

#54

Post by 5701652400 »

hsn915 wrote: post #43
5701652400 wrote: post #13

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.

If desktop only is so useless, why are so many people create TUI apps?

they are useless too. 99.99999% of normal people do not open terminal in their entire life nor do not even know what that is. get out and touch grass, friends.

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

#56

Post by hsn915 »

swiftcoder wrote: post #53
hsn915 wrote: post #49

Earlier quoted context omitted.

Does "immediate mode" mean the UI refreshes at a constant 60fps rate like a video game, redrawing everything all the time? No. It means that you build the UI by describing what it should look like now, based on the data / state you own, without referencing any existing "widget" object or trying to manipulate it. Scale is not about the number of buttons, but the structure of the data. You have a list of objects, withi…

> In immediate mode, none of that matters. You don't have a parallel widget tree. No, instead, you need to have your entire dataset in memory, and potentially rebuild your whole tree on every update. This causes quite a lot of problems for out-of-core datasets - you end up needing to maintain proxies for things like items in scrollable lists that aren't loaded into memory yet.

> you need to have your entire dataset in memory

Are we talking about displaying tables with billions of entries? I'd like you to show me how retained mode gui scales well with that use case.

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

#57

Post by hsn915 »

tptacek wrote: post #26

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…

I think AIs generally "like" the API surface exposed by Shirei. They seem to understand it pretty well and are able to "vibe code" any kind of UI you ask of them using this framework.

To your general point though, yes, there's a lot of uncertainty about what things it makes sense to build in the AI era. I don't have good answers for what would make sense for 10 years down the road, but at this point of time, I think a project like this actually makes perfect sense.

Now that AI can write the code for us, we need better frameworks and libraries, because a lot of what we have now is quite honestly slop.

You could say that you could get AI to maintain 3 separate codebases of the same application UI, each one targeted to a different platform, and the AI will maintain the feature parity and you won't have to worry about it.

For now, AI can take care of coding, but it does not relieve you of having to pay attention to things. If you create 2 or 3 code bases for the different platforms you target, the maintenance burden still falls on you.

But I don't know for how long the situation will remain like this.

Last year I did not think I'd be using AI for coding. I dug up a few tweets I posted last year saying that LLMs have hit a plateau and will stop improving, and that AI coding is a scam being promoted by charlatans.

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

#58

Post by TazeTSchnitzel »

hsn915 wrote: post #51
rowanseymour wrote: post #12

Earlier quoted context omitted.

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?

Most open source projects are abandoned because the author never finds enough time to work on it or can't muster the focus and attention needed. It is not true that there is "lack" of human investment in the creation of this. If anything, I spent the last two weeks glued to the screen most of the time, to a degree I have never experienced before, building out all the different areas that lead to this release. I will…

> I spent the last two weeks glued to the screen most of the time, to a degree I have never experienced before,

With respect, a single period of manic hyperfocus is not what makes a project, it is being in it for the long-haul and putting in the hours here and there even when it isn't fun any more and you have many other things you might rather be doing.

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

#59

Post by rowanseymour »

hsn915 wrote: post #51
rowanseymour wrote: post #12

Earlier quoted context omitted.

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?

Most open source projects are abandoned because the author never finds enough time to work on it or can't muster the focus and attention needed. It is not true that there is "lack" of human investment in the creation of this. If anything, I spent the last two weeks glued to the screen most of the time, to a degree I have never experienced before, building out all the different areas that lead to this release. I will…

To be clear I don't want to detract from what you've made here. Agentic engineering done right does still require a lot time and attention IMO. But you've still got a challenge on your hands to demonstrate to potential adopters that you're in it for the long haul.

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

#60

Post by kolkov »

pancsta wrote: post #36
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…

[flagged]
Post reply on HN