Live data from Hacker News

Gio UI – Cross-platform GUI for Go

gioui.org

1–10 of 224 posts

Re: Gio UI – Cross-platform GUI for Go

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

Re: Gio UI – Cross-platform GUI for Go

#3
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.

What's your definition of decent performance?

My company has built quite a few complex capacitor + Angular + Ionic apps and the performance on iOS is fine. Some even got featured by Apple, so that should be some indication that quality and performance was alright.

Re: Gio UI – Cross-platform GUI for Go

#4
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.

We use Tauri, but I think that it’s important to know that we solely use it for internal tools. I have no idea if it’s a good tool for consumer facing products. It works well enough for what we use it for, which is mostly for our solar park technicians where using cross platform Typescript on terrible internet became too much work for our small team.

Re: Gio UI – Cross-platform GUI for Go

#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 would there be an allocation? Of what? How are we saving it?

Re: Gio UI – Cross-platform GUI for Go

#6
post #4
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.

We use Tauri, but I think that it’s important to know that we solely use it for internal tools. I have no idea if it’s a good tool for consumer facing products. It works well enough for what we use it for, which is mostly for our solar park technicians where using cross platform Typescript on terrible internet became too much work for our small team.

We use Tauri at GitButler and love it.

Re: Gio UI – Cross-platform GUI for Go

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

The best option is probably Flutter right now: https://flutter.dev/

If you don't mind writing the UI native, sharing only business logic code, Kotlin is an option: https://kotlinlang.org/docs/multiplatform.html#kotlin-multip...

Kotlin also can do the UI if you use Compose: https://www.jetbrains.com/lp/compose-multiplatform/ ... however, iOS support is still in alpha, and Web is "experimental". If you're not willing to cope with that (expect to have to change your code as they develop the framework) then Flutter is the way as it's pretty stable already on all platforms.

If you already know Typescript and React, you may also consider React Native (but I can't attest to its performance on iOS or anywhere else): https://reactnative.dev/

Re: Gio UI – Cross-platform GUI for Go

#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, then you are forced to implement your own retainer mode graphics. Again it reintroduces problems that have been solved a long time ago. Very fancy renderer based on piet-gpu that only takes control points of a bezier curve as input and tessellates everything from that. Cool concept, but try drawing a real circle with that, and some some approximation with 4 bezier curves. Wasm is not more then a proof of concept that won't be production ready without years of engineering by compile team. Overall nice for Go developers that wanna do some simple UI with lists and input fields.

Re: Gio UI – Cross-platform GUI for Go

#9
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…

On the first approach ColorOp{Color: red} would have to be boxed and thus heap allocated. This is because ops.Add in general would receive a (fat) pointer to a value implementing a particular interface rather than a value of concrete type.

(The sibling comment written at the same time has a more detailed explanation of the 'fat' part.)

Re: Gio UI – Cross-platform GUI for Go

#10
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…

Whenever you do:

  v := interfaceType(concreteTypeValue)
in Go, what you're actually doing on a lower level is:

  dataPtr := &concreteTypeValue
  typePtr := typeData[concreteType]()
  v := interfaceData{
          data: dataPtr,
          typ: typePtr,
  }
The first line here is the allocation, since (at least, the way I recall the rule) in Go pointers never point to values on the stack, so concreteTypeValue must be allocated on the heap. The rule about pointers not pointing to the stack is there to make it easier for goroutine stacks to grow dynamically.

See https://go.dev/doc/faq#stack_or_heap.

Post reply on HN