Live data from Hacker News

Gio UI – Cross-platform GUI for Go

gioui.org

21–30 of 224 posts

Re: Gio UI – Cross-platform GUI for Go

#21
post #5

Go newbie here. Can anybody elaborate on this piece of the docs? """ You might be thinking that it would be more usual to have an ops.Add(ColorOp{Color: red}) method instead of using op.ColorOp{Color: red}.Add(ops). It’s like this so that the Add method doesn’t have to take an interface-typed argument, which would often require an allocation to call. This is a key aspect of Gio’s “zero allocation” design. """ Why wou…

Heh. Go just doesn’t let you write zero-cost generic abstractions the way C# does.

Re: Gio UI – Cross-platform GUI for Go

#22
post #8

Experience report: Impossible to write any serious complex application in this. Lacks components for basic things everyone gets for free on other platforms, things like video, maps or rich text components. Nor does if offer any clear easy path to add them yourself. Breaking API changes every few months. No way to theme something. Immediate mode graphics are great until you need to start managing some complex state, t…

If you care about WASM, Uno Platform has decent support for it, there’s also AvaloniaUI and both are stable at this point with relatively rich control collections and libraries.

Re: Gio UI – Cross-platform GUI for Go

#23

How does this compare with Fyne?

They both owner-draw every widget themselves (not using platform native widgets).

Gio is pure Go, Fyne is cgo.

Gio is immediate-mode, Fyne is retained-mode.

Flamewar starts here: I don't know why anyone would seriously choose an immediate mode GUI toolkit. When you receive an event, in immediate mode you have to recreate the whole world, then the toolkit has to then either rerender the world from scratch, or else diff the world against a clone on the heap, and rerender dirty regions. These kind of toolkits "advertise" hitting 60fps rerender speed as if that was impressive. In retained mode you merely don't respond to events you don't need to, the framebuffer doesn't need modification at all, and getting only 60fps updates would be embarassingly slow.

I understand the appeal of integrating e.g. Dear Imgui into your game's render loop if you're already re-rendering the whole viewport. But for desktop/mobile applications where the platform has a retained framebuffer, it seems like a deliberate deoptimisation.

Re: Gio UI – Cross-platform GUI for Go

#24
post #2

A bit off-topic, but what's the best method to build cross-platform mobile & web apps nowadays ? I'm talking either business logic + UI , or just business logic ? like gomobile, rust, typescript, etc ? At some point i thought about using typescript for all business logic, as it seemed the most portable tech, but i realized there's no good way to have decent performance running javascript on iOS.

My team achieved better than native performance using RN when rewriting a very large iOS app. And that was in 2018, before Hermes and a lot of other optimizations. It takes some careful usage of requestIdleCallback and avoiding doing work in the UI thread but it is not rocket science. You do have to avoid a lot of the going advice and bloated libraries / frameworks though.

| better than native performance

Maybe better than the native you had before the rewrite lol

Re: Gio UI – Cross-platform GUI for Go

#26
post #2

A bit off-topic, but what's the best method to build cross-platform mobile & web apps nowadays ? I'm talking either business logic + UI , or just business logic ? like gomobile, rust, typescript, etc ? At some point i thought about using typescript for all business logic, as it seemed the most portable tech, but i realized there's no good way to have decent performance running javascript on iOS.

In Go land, there's Wails

https://wails.io/

Re: Gio UI – Cross-platform GUI for Go

#27
post #18
post #12

Earlier quoted context omitted.

>in Go pointers never point to values on the stack This is only the case for pointers that the compiler can't prove not to escape: >In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.

That could be true, but I've done a few optimizations of allocations in Go code, and I don't recall pointers to stack values ever being optimized (unless the entire branch is removed, of course). If anyone could provide an example of the code that does pointer operations yet doesn't cause allocations, I'd appreciate it!

Sure, here you go:

https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename...

Re: Gio UI – Cross-platform GUI for Go

#28
post #2

A bit off-topic, but what's the best method to build cross-platform mobile & web apps nowadays ? I'm talking either business logic + UI , or just business logic ? like gomobile, rust, typescript, etc ? At some point i thought about using typescript for all business logic, as it seemed the most portable tech, but i realized there's no good way to have decent performance running javascript on iOS.

I tried quite a lot of multiplatform frameworks in the context of mobile, and for me Flutter is in a completely different league than the rest of them. I really love it.

Re: Gio UI – Cross-platform GUI for Go

#29
post #23

How does this compare with Fyne?

They both owner-draw every widget themselves (not using platform native widgets). Gio is pure Go, Fyne is cgo. Gio is immediate-mode, Fyne is retained-mode. Flamewar starts here: I don't know why anyone would seriously choose an immediate mode GUI toolkit. When you receive an event, in immediate mode you have to recreate the whole world, then the toolkit has to then either rerender the world from scratch, or else dif…

One positive side of immediate mode is that the code becomes a lot more straight forward. You only see that loop function, so it's very nice if you need a POC, or if it's going to be ran on embedded.

Re: Gio UI – Cross-platform GUI for Go

#30
The amazing thing is that 30 years ago there were cross platform toolkits like Neuron Data and the toolkit under OpenOffice(called StarOffice originally), and yet today the options are still fragmented and imperfect.

We have far better compilers and even languages for cross-platform work, so it should be easier by now.

Post reply on HN