Live data from Hacker News

Show HN: Spot – Simple, cross-platform, reactive desktop GUI toolkit for Go

github.com

41–50 of 63 posts

Re: Show HN: Spot – Simple, cross-platform, reactive desktop GUI toolkit for Go

#41
Been using

https://fyne.io/

https://github.com/fyne-io/fyne

for years but will check this out

( terminal but still great go guis:

https://github.com/gizak/termui

https://github.com/charmbracelet/bubbletea )

Never used but should be in this list:

https://gioui.org/

https://mattn.github.io/go-gtk/

https://github.com/lxn/walk

Re: Show HN: Spot – Simple, cross-platform, reactive desktop GUI toolkit for Go

#43
I have been looking for something like this in Go for a while. I think there's a real opportunity for Go to provide a great developer experience for cross platform UI due to how simple the build process is. Speaking from experience, half the pain of cross platform development is managing build complexity, which Go basically eliminates.

I'm curious how you'll end up solving for cross-platform layout when native controls have different intrinsic sizes per platform?

This is something I haven't seen solved super well in cross platform toolkits.

Wishing you luck though.

Re: Show HN: Spot – Simple, cross-platform, reactive desktop GUI toolkit for Go

#46

Been using https://fyne.io/ https://github.com/fyne-io/fyne for years but will check this out ( terminal but still great go guis: https://github.com/gizak/termui https://github.com/charmbracelet/bubbletea ) Never used but should be in this list: https://gioui.org/ https://mattn.github.io/go-gtk/ https://github.com/lxn/walk

[deleted]

Re: Show HN: Spot – Simple, cross-platform, reactive desktop GUI toolkit for Go

#47
post #30

Earlier quoted context omitted.

For complex scenarios (i.e. the user interacting with the UI while there are some long-running processes in the backround doing this, too), managing the state quickly gets unwiedly: You need to write callback code everywhere that carefully has to inspect the current status of all other activities and might then updates 10s of widgets accordingly. With the reactive approach you are able to write a single rendering fun…

I'm already convinced of the benefit of declarative GUIs over imperative ones. To be clearer, what I mean by declarative GUIs is ones where I can specify that UI elements should be bound to certain values in the memory of my program, so that they don't have to be changed explicitly by imperative code. Ex.: TextBox { Text: app.currentUser.name } Instead of having to call setText on that TextBox. What I'm still missing…

This is exactly how the data binding APIs in Fyne (another Go GUI toolkit) work. And it's also an optional feature, so if you want to handle things by registering callbacks and calling setters yourself you can do that too.

Re: Show HN: Spot – Simple, cross-platform, reactive desktop GUI toolkit for Go

#49

Been using https://fyne.io/ https://github.com/fyne-io/fyne for years but will check this out ( terminal but still great go guis: https://github.com/gizak/termui https://github.com/charmbracelet/bubbletea ) Never used but should be in this list: https://gioui.org/ https://mattn.github.io/go-gtk/ https://github.com/lxn/walk

It's strange to see "inspired by Material Design," and then a bunch of controls that look nothing like Material.

Re: Show HN: Spot – Simple, cross-platform, reactive desktop GUI toolkit for Go

#50
post #22

If only I had known about this (or judging by commit history, if it existed) ~3 weeks ago. I've been saying for ages that either React ported to Go or a React-like framework for Go would be an incredible development experience, so this looks perfect (I used to be a big hater of React.js until I was enlightened by React.lua).

I had the same problem - really liked the way I used to do component composition in React, it was hard to go back. Eventually found a way to do something similar using just the standard Go html/template. I’ve written about the implementation here: https://www.sheshbabu.com/posts/react-like-composition-using...

This a great write-up and similar to an approach that I stumbled upon a few years ago. Have you thought about HTMXing this approach to get away from full page renders?
Post reply on HN