Gio UI – Cross-platform GUI for Go

by gjvc • 2 years ago

299 184 2 years ago

bsaul• 2 years ago

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.

Pepe1vo• 2 years ago

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.

devjab• 2 years ago

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.

junon• 2 years ago

We use Tauri at GitButler and love it.

DreaminDani• 2 years ago

Agreed. Tauri for desktop, capacitor for mobile. Bring your own front-end library either way.

brabel• 2 years ago

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/

lakomen4• 2 years ago

If you use oidc, you can't use Flutter with web or desktop as build targets. It requires a feature that isn't supported by Flutter on those platforms.

382• 2 years ago

The one flutter website I have come across is an absolute piece of garbage. Completely destroys the ability to modify or even inspect the HTML source. See for yourself

https://sunrisetv.ch/de/vod/1/details/vod/crid:~~2F~~2Fog.li...

iamkonstantin• 2 years ago

I would also add Tauri to the list as they now support mobile as well https://v2.tauri.app/blog/tauri-2-0-0-beta/

I think all cross platform frameworks come with some kind of drawbacks and in most cases, learning about the underlying native platforms is unavoidable (like widgets, visionOS support etc).

So I wouldn’t worry too much or get into a FOMO decision block - I’d pick the one that feels most fun and fits your use case.

lessisless• 2 years ago

A long time ago, nativescript[1] seemed to be a strong alternative to reactnative. Is that still the case?

[1] https://nativescript.org/

mdhb7• 2 years ago

Flutter is so far in front of anything else out there I think at the moment.

petesergeant• 2 years ago

I’m getting on pretty well with Ionic + TypeScript, using React and Redux. Performance hasn’t really been an issue, although I’m also not doing anything that performance heavy. I’d recommend it. I like that it ends up being comprehensible HTML + CSS, as well as simple React that I’m already comfortable with and can debug.

SoKamil• 2 years ago

I would say React Native with all the Expo stuff. While Flutter is okayish, web is bad in terms of feel and accessibility since it renders to a canvas. Also, iOS still has issues with lag even after introducing Impeller rendering engine.

Look at Bluesky's client. The app performs decent on all supporting platforms and has single codebase.

https://github.com/bluesky-social/social-app

ricardobeat3• 2 years ago

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.

mradonic• 2 years ago

| better than native performance

Maybe better than the native you had before the rewrite lol

robterrell• 2 years ago

better than native performance using RN

You had an app written natively in Objective-C or Swift, switched to single-threaded javascript React Native, and then your app ran faster?

neonsunset7• 2 years ago

Businesses do seem to like AvaloniaUI and Uno.

https://avaloniaui.net/

https://platform.uno/

lakomen4• 2 years ago

Thanks, which of the two would people recommend for a C# beginner? And is oidc well supported on all target platforms?

kitd• 2 years ago

In Go land, there's Wails

https://wails.io/

lakomen4• 2 years ago

What are all the target platforms? The website doesn't have a list, or I'm unable to find one.

EDIT: never mind, I found it https://wails.io/docs/reference/cli#platforms

It doesn't seem to support Android, IOS or web.

ludwik• 2 years ago

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.

divan• 2 years ago

For the last 4 years the answer is Flutter.

Robinxd• 2 years ago

Has been posted here before also, so adding it for people not aware of it already - https://areweguiyet.com

scosman4• 2 years ago

Native UI for anything that requires polish. I’ve been through too many iterations of frameworks that promise everything and don’t deliver. You’re up and running faster, then soon after you’re patching the core libraries after an OS update to try to get the FPS closer to native, or match a system animation more closely. The time saving only exist if you never polish your UI.

Core logic can be shared. I use gomobile - mostly love it but 3mb overhead for runtime (so not for web). Kotlin multi platform looked good, but I found it missing pretty basic libraries (which exist for Kotlin Android, so no one is building multi platform equivalents). Rust with Mozilla’s language binding layer looks good but I haven’t tried it.

mdhb7• 2 years ago

I don’t think that premise of “native UI for anything that needs polish” is true these days.

Canonical the company behind Ubuntu have said for some time now that all future app UIs of theirs would be done in Flutter starting with the very first thing people see the installation process.

Google just rewrote Google Earth’s UI in Flutter.

BMW are doing all of their in-car entertainment systems in Flutter.

bossyTeacher• 2 years ago

You already answered your own question imo. The web is the best thing we have so far and nothing comes closer to the full package. It literally is write once and write everywhere.

All the other alternatives are young frameworks that have not been battle tested and have weird quirks once you want anything relatively complicated.

andsoitis3• 2 years ago

what's the best method to build cross-platform mobile & web apps nowadays ?

Uno (https://platform.uno):

* open-source

* targets Android, iOS, Windows, Mac, and Linux (https://platform.uno/platforms/)

* C#

* automatically implements views and controls using each platform's native UI frameworks

* good IDE support: Visual Studio, VS Code, Rider (though you are not limited to those)

* Figma plugin for design collaboration

mort967• 2 years ago

I mean I guess that's fine if you're into .NET but how about those who prefer to avoid that

noveltyaccount2• 2 years ago

Also in the .NET world, Maui Blazor Hybrid is interesting. Uses HTML and the platform-native web renderer for the front end, and compiles to native code (not WASM)--i.e. clicking a button on your HTML invokes native code. Depending on your front end library, the app will look and feel more or less like a native app or web app.

An older article but puts it in context with Electron and how they differ https://www.codemag.com/Article/2111092/Blazor-Hybrid-Web-Ap...

Alifatisk3• 2 years ago

Flutter

paulddraper2• 2 years ago

Expo targets iOS, Android, web.

raminf• 2 years ago

For mobile, this looks promising: https://skip.tools

Transpiles SwiftUI over to Kotlin/JetPack Compose. Native all the way down. Haven't used it in production, but the demos work and are native after going through XCode and Android Studio.

malermeister• 2 years ago

first-class development environment (Xcode)

this made me lol. As somebody who does mobile dev professionally, the worst thing about iOS dev is how terrible XCode is compared to Android Studio.

There's no way I would want this.

marcusbuffett• 2 years ago

I tried React Native, but ended up re-writing and going with SolidJS + Capacitor, and I love the setup. I've barely thought about performance since switching, people think the iOS/Android apps feel native, there's almost never any differences in behavior between the platforms, it's a fantastic setup for a solo dev.

felipefar• 2 years ago

I would mention as an alternative QML, although I wouldn't claim it is the "best method". It's marketed as being mobile-capable, but I've heard problems about scrolling inertia and vsync delays.

I'm curious to know what others think about it.

shikaan2• 2 years ago

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?

foldr5• 2 years ago

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

ainar-g3• 2 years ago

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.

foldr5• 2 years ago

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.

pquki4• 2 years ago

https://stackoverflow.com/questions/39492539/go-implicit-con...

kevindamm• 2 years ago

This has to do with how Go handles dynamic typing via interfaces and how structs fit into that.

When a function takes an interface type as an argument, and you pass a pure struct to it, it creates a wrapper around it (this is the allocation referred to in your quote) which is simply a pair of pointers, one being a type/vtable pointer and the other being a pointer to the struct's data.

Doing it this way allows code to do run-time type inference as well as allow interface extension implicitly (that is, implementing an interface is done by implementing its methods, and you don't have to explicitly type it like ByteReader extends Reader"). Since you only pay this cost if you use it, a lot of fast-path code will use structs exclusively if it can.

DougBTX• 2 years ago

How do generics change this? Can a type bound on a generic work like a static interface implementation specification, and recover the cost of wrapping the struct?

neonsunset7• 2 years ago

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

shikaan2• 2 years ago

Thanks all (:

Someone• 2 years ago

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)

Others answered your question, but on a different subject: I find that weird to read. To me

  op.ColorOp{Color: red}.Add(ops)

reads like “add ops to the result of op.ColorOp{Color: red}. I would name that function AddTo:

  op.ColorOp{Color: red}.AddTo(ops)

Still unconventional, but at least it messages that the function argument gets modified.

DrDroop• 2 years ago

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.

neonsunset7• 2 years ago

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.

mort967• 2 years ago

Breaking API changes every few months.

I find this to be the case with a depressing amount of Google code. They do not seem to have a culture which values not breaking their users' code.

Philip-J-Fry• 2 years ago

Gio isn't made by Google

suby• 2 years ago

It's even a core point for Carbon, their hopeful C++ replacement

Under language goals on their readme,

We also have explicit non-goals for Carbon, notably including:
* A stable application binary interface (ABI) for the entire language and library
* Perfect backwards or forwards compatibility

There's also this blurb

Our goals are focused on migration from one version of Carbon to the next rather than compatibility between them. This is rooted in our experience with evolving software over time more generally and a live-at-head model. Any transition, whether based on backward compatibility or a migration plan, will require some manual intervention despite our best efforts, due to Hyrum's Law, and so we should acknowledge that upgrades require active migrations.

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

mdhb7• 2 years ago

This isn’t true in Flutter. They literally bake into the CLI with each release which will automatically identify and upgrade any parts in your application using old APIs without any intervention required. It’s literally the opposite of what you’re describing here.

https://docs.flutter.dev/tools/flutter-fix

gedw992• 2 years ago

You can write anything with it.

V0.6 made your issues much less tricky.

Also there is a Material Design theme. And also light and dark.

Here is an excellent example of a gioui app that has light / dark with a custom theme.

https://github.com/chapar-rest/chapar

If you’re on MAC or Windows it’s just “ go run .”.

If you wanted text keening or text sweeping around an arc or RTL / LRT it can do it thanks to github.com/go-text/typesetting

Complex widgets for Calendar spinners or diagrams are out there on GitHub. An effort to bring these together is lacking, and I reckon that if all these things weee brought together it would definitely encourage more developers to dive in.

anon-3988• 2 years ago

How does this compare with Fyne?

mappu2• 2 years ago

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.

ramon156• 2 years ago

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.

metaltyphoon• 2 years ago

Gio is pure Go

7% C is not pure Go.

pants2• 2 years ago

I recently wrote a little document previewer in Fyne. It's a great experience and super easy to build simple GUIs, however Fyne struggled with a few pages of text (slow scrolling and resizing). I'll have to try Gio.

w1nst0nsm1th• 2 years ago

Blazor is cross-platform, in combo with MAUI.NET

lakomen4• 2 years ago

I didn't downvote.

AFAIK it's not supporting Linux as a target platform. Correct me if I'm wrong.

andsoitis3• 2 years ago

.NET MAUI supported platforms:

* Android 5.0 (API 21) or higher is required.

* iOS 11 or higher is required

* macOS 10.15 or higher, using Mac Catalyst

* Windows 11 and Windows 10 version 1809 or higher

While Linux isn't supported, that is also not a typically significant market for GUI apps.

https://learn.microsoft.com/en-us/dotnet/maui/supported-plat...

shrubble2• 2 years ago

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.

throwaway894345• 2 years ago

I’m not sure whether those toolkits abstracted over native GUI interfaces or whether they attempted to recreate a native look and feel or whether they attempted to provide their own look and feel across platforms, but in any case the problem isn’t languages and compilers, it’s that the expectations for a GUI toolkit are dramatically greater now than then. Here are a few things that are (I think) expected from GUI toolkits today, but not 30 years ago:

* Hardware acceleration (in particular abstracting over metal, opengl, direct x, vulkan, etc)

* More complex layouts

* Animations

* Much hateful text rendering (e.g., right-to-left language support): https://faultlore.com/blah/text-hates-you/

* Accessibility

And if you want to emulate a native experience, getting keyboard shortcuts, focus behavior, and a billion other details correct is nearly impossible.

And by the way, today we have web engines that take care of most of these things for free and a huge pool of people who know how to build for them, so it’s often easier to leverage that capability than to essentially reinvent them.

And if people can contain their knee-jerk anti-electron reaction for a moment, I think that’s a pretty reasonable approach. I would really like to see something like an unlocked ChromeOS where the browser is the native interface, but unlike electron, we don’t ship a web browser with each app. Especially as webasm takes form, I could see this as a more compelling solution for cross-platform graphics with multi-language support than cross-language bindings or by trying to maintain a toolkit per language while trying to maintain some illusion of a consistent experience.

jwells892• 2 years ago

In some ways, expectations for UI toolkits have dropped too, though. Practically no UI toolkits created in the past 5-10 years come with a row recycling tableview/datagrid widget (table with column headers, sort by column, etc) for example, which used to be table stakes (which is why they’re present in Win32, MFC, AppKit, GTK, and Qt among others of the old guard). New toolkits that lacked a tableview would not have been taken seriously back then.

This has been a major blocker for my adoption of newer toolkits. I understand that it’s a result of mobile UI trends dominating the space, but that’s not helpful when I’m looking to build useful desktop apps, for which these widgets are crucial. Relying on third party libraries to fill these gaps (if they even exist) isn’t appealing either, adding yet another dependency to the pile and making a major part of my app subject to likely eventual abandonment by the library’s dev.

elteto2• 2 years ago

Why would it be easier now? What does a better compiler get you in terms of building a cross-platform UI toolkit?

We now have GPUs, mobile OSs with their own separate UI abstractions, the web, WebAssembly, etc. And people want write-once deploy anywhere.

You didn’t have any of that 30 years ago.

shrubble2• 2 years ago

The compilers of 30 years ago had incompatible behaviors between OSes, for instance C or C++ had a great deal of variation. And 30 years ago you had pre-OSX MacOS as well.

Now you can just choose 1 compiler such as GCC and it works the same on all platforms; even cross-compiling to a different CPU architecture works well and is far easier to setup (before it was a black art).

hulitu• 2 years ago

You didn’t have any of that 30 years ago.

Java ?

supportengineer4• 2 years ago

Pre-Java there was a need to have UI applications that ran on Windows NT as well as Solaris and HP-UX. I worked with a commercial software package called Visix Galaxy. We developed in C++. It included libraries for each platform. It also had an interface builder very similar to those today (like the one in XCode). These were polished tools that made it easy to build beautiful GUIs.

igouy2• 2 years ago

You didn’t have any of that 30 years ago.

"Ubiquitous Applications: Embedded Systems to Mainframe"

"To support a variety of platforms, Smalltalk uses a virtual machine approach to portability that allows applications to be easily migrated between platforms with little or no change to the code."

https://dl.acm.org/doi/pdf/10.1145/226239.226264

"… Smalltalk developers can work and deploy on Linux, Windows, AIX®, Sun Solaris, HP-UX, and OS/2®. You can also create applications to be deployed on the mainframe with VisualAge Smalltalk Server for OS/390 and z/OS."

https://www.ibm.com/docs/en/announcements/archive/ENUS202-10...

amelius• 2 years ago

We have HTML now, which is a great advancement. Don't forget about that.

zackbrown4• 2 years ago

HTML was a huge advancement, but it is likely a local maximum.

The HTML / CSS stack comes with significant ergonomic hurdles (layout / positioning / "creative fidelity") and performance hurdles (inescapable GC pauses, constant overhead of constraint-solving layout system, DOM overhead in general.)

Can we do better? IMO the future GUI lingua franca is deeply inspired by HTML and will stand on the shoulders of that giant, but will:

  - Build to LLVM native apps as well as websites
  - Include React-style templating as a foundational concern
  - Be fundamentally designed for visual building (think of the ergonomic differences between Webflow & Figma — if "an HTML" existed that "a Figma" could read & write natively, building front-ends would take a quantum leap)

WebAssembly makes all of this possible while still extending the Web and browser ecosystems.

gonzo41• 2 years ago

I'm still super disappointed that javafx died.

mark38848• 2 years ago

Anything related to Java dying is a win in my book

obdev2• 2 years ago

JavaFX is alive.

Check out what do people work on using JavaFX: https://www.jfx-central.com/links

winrid• 2 years ago

It's not dead. I just launched an app this year with it. Users love it.

zackbrown4• 2 years ago

Building a cross-platform GUI toolkit takes an incredible amount of work & time, especially at the systems level.[0]

A robust cross-platform ecosystem for the underlying programming language is a necessary but insufficient piece of the puzzle.

Given the proliferation of HTML and WebView/web-tech wrappers (Electron, Tauri, React Native etc.) there are now enough "good enough" solutions that most organizations that would underwrite the in-house R&D of a new Neuron Data or Delphi or Flash simply don't feel the need.

When it does happen — say Google Flutter — it's almost statistically impossible to keep the hydra of VPs and biz folks aligned over the decades of ongoing investment it takes to mature & form community around this kind of technology — see the recent Flutter team layoffs at Google.

[0] speaking from my experience building a cross-platform GUI solution in Rust for several years now; see pax.dev

rohansingh• 2 years ago

Isn't the whole "Flutter team layoffs" narrative somewhat debunked at this point? My understanding is that some positions were cut and some were moved, but no more than any other engineering area at Google.

bugbuddy• 2 years ago

Maybe Google execs watched Theo’s JS frameworks review? https://m.youtube.com/watch?v=WJRf7dh5Zws

TheCleric• 2 years ago

Exactly. Many programmers don’t want to worry about edge cases, and cross platform GUI frameworks are essentially coding an “oops all edge cases” project.

KronisLV• 2 years ago

I really think that the Lazarus Component Library took the right approach: https://en.wikipedia.org/wiki/Lazarus_Component_Library

I wonder why the idea of widgetsets never really went anywhere: https://en.wikipedia.org/wiki/Widgetset

You could take a program that says you need a button in the window and it would make one for you on Qt, GTK or whatever else was supported, on any platform that you were compiling for.

We might as well have gone a step further: your programming language --> UI toolkit bindings for your language --> programming language independent GUI toolkit --> widgetsets for GTK, Qt, WPF, Win32 or whatever else --> executable for that specific platform

With that many layers of abstraction it's likely that we'd get the lowest common denominators for all functionality across platforms, but at least it would run better than web technology does, with the accessibility and platform look & feel you'd expect.

Of course, for whatever reason, seems like nobody wanted to undertake the borderline crazy effort of creating something like that, something foundational for others to build upon, so that's why we get super fragmented frameworks that are bound to specific languages nowadays and each of them have to reinvent a wheel a lot.

Either way, FreePascal/Lazarus were pretty amazing for RAD: https://en.wikipedia.org/wiki/Lazarus_(software) except that the community and ecosystem isn't exactly getting bigger.

supportengineer4• 2 years ago

Now there is a generation of software developers who grew up with web technology, and they aren’t old enough to recall the days of native apps - they don’t know any way other than HTML.

supportengineer4• 2 years ago

Yes, as a longtime software developer people have been trying to solve this problem different ways my entire career. The closest we got was Java swing. And it works well enough for things like eclipse but for some reason, nobody wants to use it and they want to use things like Electron instead

smokel2• 2 years ago

Regarding the "for some reason": Java Swing (and JavaFX, and Windows Forms for that matter) all suffer from lack of integration with modern web browsers. It is near impossible to find a way to combine these model-view-controller based user interfaces with the DOM in a reasonable way.

Horrible as it is, web browsers have managed to provide a common platform for user interface delivery. The browser wars have been fierce, and getting this foot between the door has cost several companies a lot of money. This technological monopoly is far from optimal, but I fear that we are stuck with it, as we are with QWERTY keyboards, USB thumb drives that must be unmounted manually, and the hopeless misery that is Bluetooth.

wiseowise3• 2 years ago

Isn’t Eclipse written using SWT?

oefrha2• 2 years ago

It's a good sign that unlike fyne, this library passed the very first test I threw at it: rendering some CJK text. Fyne can't do that unless you give it one custom font to render everything in — well, good luck finding one satisfactory font encompassing all commonly used scripts around the world, not to mention emojis. Which means fyne is immediately dead to me whenever I'm building anything with a remote chance of user-generated/web content and/or localization.

maccard• 2 years ago

Noto sans is pretty good in this regard.

oefrha2• 2 years ago

Noto Sans isn't limited to Latin — it supports Cyrillic and Greek as well — but immediately fails my CJK test. Or Arabic, or various other scripts used by half of the world.

flohofwoe• 2 years ago

Interesting that the WASM demo on the front page just render a black rectangle where the text is supposed to be on my fairly vanilla Windows 10 PC with Chrome (it rendered fine in Chrome on my Android phone).

bwat49• 2 years ago

same here with edge on windows 11

joezydeco• 2 years ago

It wasn't just me. Whew. It also ran incredibly slow.

glass-z13• 2 years ago

Yet non of the GUI libraries/frameworks for GO support drag/drop file to get the real path

andsoitis3• 2 years ago

doesn't appear to support Unicode.

diskdance• 2 years ago

Seemingly it's using a <canvas> to render everything just like Flutter on Web, which is known to have problems with accessibility and feel non-native.

mort967• 2 years ago

I mean it's not primarily a web app framework, it's a native GUI toolkit which has a web back-end.

Longhanks2• 2 years ago

It isn't native on any other platform either.

afavour• 2 years ago

I’m curious if anyone has a variant of this idea where an invisible DOM lives alongside the canvas for accessibility reasons. It should work but I imagine it would also take a lot of work.

mwcampbell• 2 years ago

This is how Flutter for web implements accessibility. It's been a while since I checked, but last time I tried using a Flutter app on the web with a screen reader, there were problems. I don't remember specifics.

zackbrown4• 2 years ago

Check out the approach that Pax is taking.[0]

Pax renders vector graphics to canvas layers and composites + clips + occludes native elements (web DOM nodes, iOS SwiftUI Text elements, etc.) in the same space to make a cohesive scene.

This solves accessibility and SEO, as well as dramatically reducing runtime size (~100KB WASM network footprint) because text rendering and atomic native UI elements don't need to be reinvented.

To my knowledge we're the only ones taking this particular approach so far (I'm on the team behind Pax) but it works quite well. Yes it was a lot of work.

[0] see pax.dev or check out a simple example: https://static.pax.dev/space-game/ ; source code for space game in examples on github https://www.github.com/paxengine/pax

zdragnar• 2 years ago

The canvas element allows children specifically for this purpose, iirc.

Edit: unless you're doing something like flutter where your goal is to escape the DOM/JS paradigm in your code entirely, the fallback DOM nodes don't tend to be implemented too often.

The biggest reason is that canvas is for things with interactive/consumptive patterns that don't work well without vision.

Cute animations, 3d explorers and configurators, that sort of thing.

For users who rely on screen readers, they are better served by a DOM and interactive patterns that are not strictly recreating the canvas.

As an example, canvas based animations might have a fallback equivalent to an alt attribute on an image. A 3d explorer or configurator might be represented in DOM as a multi step form with verbose descriptions- no need to recreate drag and drop, camera controls, or anything else.

So, if you're not automating it like flutter is (and even if you are) what you really need to do is effectively an entirely alternate UX for screen reading users... Trying to get your product team to budget that is difficult despite being a Good Thing to do.

chris37879• 2 years ago

That's actually how Flutter works now if you enable web accessibility, and it does take a lot of work, and come with a performance cost: https://medium.com/flutter/accessibility-in-flutter-on-the-w...

abroadwin• 2 years ago

Definitely doesn't feel native or accessible on web. Can't tab between radio buttons. On macOS CMD+A doesn't select all text field text (CTRL+A does).

brirec• 2 years ago

Can’t even copy or paste at all on an iPhone.

okasaki• 2 years ago

The demo doesn't work for me. I see some buttons but mostly it's all black. Chromium on Win 11.

andreygrehov3• 2 years ago

Why do all these cross-platform GUIs look like they were designed 50 years ago?

paulddraper2• 2 years ago

I...would like to know what you were using in 1974 that looked like that.

andreygrehov3• 2 years ago

Heh. The "50 years ago" part was an intentional stretch to add more weight to how disappointed I am. But seriously, the first demo they presented is an immediate rejection.

9999000009992• 2 years ago

I built a small app in Go using Fyne.

Never again. Both Gio and Fyne lack tons of polish and features Flutter provides.

I built my core logic in Golang, and then decided to wrap it in an Android app. The GUI feels like it came out of 2003 with limited ways to fix it.

saganus• 2 years ago

Sounds interesting. How did you wrap it in an Android app if you could elaborate?

9999000009992• 2 years ago

Simple, I basically wrote a script to figure out probabilities for gambling ( I won't open source it since I don't want someone angry at me when they lose money). Then you basically have the UI layer call the script.

It's really hacked together, but it works.

PhilippGille• 2 years ago

A different option is Wails [1], which allows you to write all logic in Go, and the UI in HTML (with any or no web framework). It's like Electron but lighter because it doesn't ship Chrome but uses the system's web viewer instead.

[1] https://github.com/wailsapp/wails

buildbuildbuild• 2 years ago

Wails is great. Also, see Tauri for a similar lightweight approach in the Rust ecosystem.

cabalamat• 2 years ago

I note form the demo that there's a "Flat" button that looks like normal text. This is a mis-feature and should be removed; controls should look different from things you can't interact with.

gjvc• 2 years ago

strongly agree

luismedel2• 2 years ago

Not about Gio UI but related.

I'm really enjoying the conversation around UI toolkits here. But I think we're all missing the elephant in the room and it's that we already had (have?) a superb toolkit and development model in the Visual Basic (later Windows Forms) era and nothing really manages to replicate that experience nowadays.

Microsoft destroyed it when they tried to push WPF and later shenanigans, only to realize it was a mistake years later.

I can't understand why we all, as a sector, agree about standards being a good thing, even if some are only de facto, and never agreed to maintain that really simple model.

I remember Mono tried to bring that to all platforms and everybody ignored/smashed them because "it's Microsoft".

Edit: typo

skydhash3• 2 years ago

I remember Mono tried to bring that to all platforms and everybody ignored/smashed them because "it's Microsoft".
Microsoft destroyed it when they tried to[…] only to realize it was a mistake years later.

Answer is right there.

siproprio• 2 years ago

Can't even right click text lol

gedw992• 2 years ago

Have been using gioui to build streaming apps. It’s very easy and upgrading is always easy because it’s golang and the core devs take it seriously when they make a change.

When I need a web gui I use a gioui plugin system here: https://github.com/gioui-plugins/gio-plugins

WebViews work on web, desktop and mobile. It’s amazing. Deep linking also so you can send out a link to an email or Monike notification and the users app will open the gio gui in the right part of the gui.

It also has notifications and share extensions for all OS’s. It’s really a complete system. I can’t believe how much devs complain about things not being easy , when it’s all there. I definitely share the feelings that’s it’s so hard to support so many OS’s, but it’s the world we live in - plurality.

I like how I can do all of this with only golang , instead of switching between bits and bobs.

I always write my golang backend to work with gio and html.

So if I need SEO or video playback I can still do it in a web view and also keep googles seo happy for the gio web. I just use Hugo and feed it markdown. This is what Google SEO sees.

Gio UI – Cross-platform GUI for Go

Related Stories