Hacker News Reader

Comment by oefrha | Hacker News Reader

I really tried to develop several cross platform GUI apps in Go, using various frameworks. The result was far from satisfactory. My advice: don’t bother, just use Qt. Or Electron if you can stand the resource usage. Or maybe Flutter, I have no experience with that; maybe I should give it a try.

View on HN

> don’t bother, just use Qt. Or Electron...

Qt and Electron are horrible options. What makes modern GUIs so complex that nobody's able to come up with a viable alternative that's simpler, faster and smaller? Whenever I talk to video game programmers, they scoff at the idea that UI is a difficult problem to solve. And they're right. They can get a computer to draw hundreds of complex 3d objects 120 times a second. Why can't we draw some text and a box 60 times a second so my window doesn't skip when I scroll?

Less horrible than other solution OP mentioned. Go ecosystem is great for CLIs, Web services but Desktop app support is not so great

What, on a fundamental level, makes Go worse than Javascript at desktop apps?

Investment.

GitHub then Microsoft invested heavily into Electron. Tons followed. Not to mention the existing web ecosystem.

There are like two dozen random open source developers who bothered to work on Go GUI libraries, on the side.

GitHub says Fyne has 120 contributors… and Fyne Labs is working to get substantial investment to secure the future like Google has done for Flutter or Facebook for react native.

There's nothing fundamental about Go that makes it unsuitable for GUIs.

It is objectively better than Javascript in many respects, not least of which is performance.

There are only two major blocking issues I see, and none of them is unsurmountable:

- Complex text layout (harfbuzz)

- Accessibility

> Why can't we draw some text and a box 60 times a second so my window doesn't skip when I scroll?

Battery, for starters. If desktop UIs were all written like games, nobody would carry their laptops anywhere. Because they all be plugged in at home.

What do you think your screen is doing all the time? You can't blit to the screen once and then "freeze" it. Your computer/phone is blitting pixels all the time.

Most games are immediate mode graphics. An operating system cannot function efficiently if its graphics are not more like a retained mode system. There’s a big difference between the two.

The point of the GP argument is that the lack of decent cross-platform GUI libraries is astounding to game programmers because games are much more difficult and involved than GUIs yet producing a game that runs on multiple platforms is mostly a solved problem.

The point is not to say "Why don't you guys do GUIs like games where you recompute the whole thing every frame?". Even the people who talk about immediate mode GUI are talking about the API of defining the UI, not the implementation details. It's perfectly consistent to have a GUI library that exposes an immediate mode API but retains a lot of state between frames and only does repainting when necessary.

Also I find this talk about battery life in general disingenious given that more and more tech companies are converging on implementing applications in Electron which drains battery life very quickly.

There was a post on HN where someone explored the immediate gui paradigm for their PhD (or masters degree, don't remember) and they discovered that this assumption is actually incorrect, given the interactions and os optimizations the battery usage (well, cpu usage and gpu usage) was lower overall. I remember very little details, it was amazing

I would have to read it to see what you mean. I cannot imagine a world in which the normal way of doing immediate mode graphics was more efficient than retained mode.

I'm trying hard to find the link, but I'm struggling, sorry.

During my researching, a lot of posts point out that "innediate mode" refers to the API, not the implementation, and that React is effectively a hack to obtain an immediate mode gui on top of retained mode.

Doesn't say anything about performance, just that the implementation behind the scene can retain state to save battery

The "cross platform" part, which is maybe less of an issue these days?

> Whenever I talk to video game programmers, they scoff at the idea that UI is a difficult problem to solve. And they're right.

You have no idea what you're talking about.

Enlighten me, then.

If you're truly interested in being enlightened then do the work. It's not up to internet strangers to refute your painfully uninformed assertions in detail. That's what education and work experience are for. You simply can't cover it in a comment.

I wrote my comment to make it clear for anyone else who doesn't work in this area that what you said is utterly wrong. HN typically has well informed comments so people take it a little more seriously than other places. The thread is also old enough now that no one except you will probably read it.

I'll at least give you something so that you're not left holding nothing but a mean internet comment.

First: If you were to rank the hardest technical challenges in modern computing then UI architecture is easily in the top 5, if not #1. In that same list you have distributed (as in networks) computing. It's an incredibly difficult problem with an endless pit of depth. UI IS HARD. If your next question is "what makes UI hard?" then - good! - you're curious. Take some courses or something. Try building a great UI for non trivial use cases. Educate yourself by doing!

Second: A computer drawing "hundreds of of complex 3d objects 120 times a second" has absolutely nothing to do with complexity of UI. The challenges in UI are not strictly a matter of drawing dots on the screen! The two things are orthogonal! Game engine renderers are solving a very constrained problem whereas UI architecture is totally unconstrained.

Third: Game GUIs have a TINY fraction of the UI components you'd need to support a sophisticated modern day business application (think Salesforce). Someone else mentioned accessibility but that's just the tip of the iceberg. The sheer number of UI components in business applications dwarfs what you see in games. Not only that but the UI components I'm talking about need to be assembled in an uncountable number of ways. And they're constantly being updated/tweaked.

There are many people who have devoted their entire life to finding a general purpose way to build great UI. No one has cracked it yet and it's not because people are stupid or don't want to. It's HARD. But also a lot of fun if it's something you enjoy doing.

Just try to use one of the minimal frameworks (which are usually also immature, buggy and poorly documented, especially in the Go GUI ecosystem, but that’s beside the point). Unless you’re developing something trivial or you’re the type who love to implement widgets from scratch and don’t give a crap about OS-level consistency, ten minutes in you’ll wish you have access to some standard OS widget that’s not implemented, and thirty minutes in you’ll wish you have one of the more complex widgets in Qt at your disposal. Most of us just want to make a damn app, not a widget library from scratch.

A few weeks ago I read a series of tweets from someone who used a game engine (I think godot) to write a cross platform tool with a GUI with great success.

Are you talking about this article[0]? That's interesting. I'll have to do some experiments with that. Thanks for sharing!

https://medium.com/swlh/what-makes-godot-engine-great-for-ad...

Video game UIs exclude a lot of hard problems (e.g. accessibility, power use, cross-platform abstractions like I/O, many control types) simply by being embedded in a video game.

Video game UIs do (almost) everything you just mentioned.

Accessibility: I'm not well versed on accessibility.

Power Use: mobile games are a thing. I wouldn't be surprised to find out that, on average, mobile games use less battery than electron apps (excluding Unity games. Unity games are the Electron Apps for video games).

cross-platform abstractions like I/O: video games run on more platforms than most apps with a larger variety of I/O and control types.

Regardless, that wasn't my point. My point is that video games are doing much, much more than most desktop apps could ever dream of doing in terms of pure work, and yet things like complex UIs and cross-platform deployments aren't considered difficult problems.

> Accessibility: I'm not well versed on accessibility.

Lol, you’ve pretty much torpedoed any credibility right off the bat.

> Power Use: mobile games are a thing. I wouldn't be surprised to find out that, on average, mobile games use less battery than electron apps

This is a flawed take on multiple levels.

> Regardless, that wasn't my point. My point is that video games are doing much, much more than most desktop apps could ever dream of doing in terms of pure work

This is very hand wavy as to be meaningless. What is “pure work” and how does it have anything to do with architectural complexity? I think you underestimate a lot of of the complexity that goes into the underlying stack of components for desktop applications. If you hand wave away (text) layout, text rendering, accessibility and performance optimization - then you can claim anything.

As already mentioned UIs in games are typically much more limited in scope and complexity.

There are very little videogames that can be played if blind, so the accessibility business is not the same as for apps

Just for font rendering you need harfbuzz+freetype if you want something decent (e.g not stb_truetype) so you're already talking 5-8 mb of libraries at the bare minimum. You also want ICU for proper unicode processing unless you don't have any unicode string operation anywhere in your software . +16 mb and we haven't rendered a single pixel. Then you're making a GUI - you aren't going to restrict it to people with a GeForce RTX1070+ right ? No, you want everyone to be able to use it, yes, including that one person in the back with a GMA500 intel chipset which does not support opengl 3.2 but will leave an absolutely scathing review of your app if it does not work on their machine (alternative: same thing but it's the company you're building the software for which had a fleet of 2008 dell Inspiron for their employees). So now you need to ship ANGLE + some software opengl implementation so that people with 2008 eeePCs won't see a black square when they open your app. Add 10 or so more megabytes and you have the very, very, very bare minimum on which to start building your UI toolkit if you want to cover common use cases.

These are valid points, I'm currently going through the dance of building a custom cross platform gui for mobilde+desktop tailored to my application. Proper localized text rendering is hard, Harfbuzz and Freetype are solid options to start with and are available on recent Linux desktops. I've abstracted the text rendering to replace Harfbuzz and Freetype with platform native libraries on Apple and Windows.

The renderer itself is abstracted and defaults to opengl 3.3 with a fallback to software rendering as last resort and to be portable.

Long story short: It's not easy but very possible to build a polished cross-platform GUI smaller than 1MB. My app binary currently compiles down to 135 KB on desktop, in the end I aim for less than 2 MB for the whole application.

However I wouldn't recommend this for most applications where a framework would be a faster option for a traditional GUI.

> I've abstracted the text rendering to replace Harfbuzz and Freetype with platform native libraries on Apple and Windows.

I hope your UI designers are happy with some text wrapping on one platform and not another because they have slightly different metrics even given the same font - for me this has never flown and I had to work to make things pixel-perfect across mac / windows / linux a few times now which definitely does not work when using the platform renderers.

This is dynamically linked to all those libraries which must be installed. One of the points above is how small can you be without those dependencies. All Fyne apps need is a working graphics driver capable of OpenGL spec from 2011.

I found the following file size for library files on my system:

816K /usr/local/opt/freetype/lib/libfreetype.a

1.9M /usr/local/opt/harfbuzz/lib/libharfbuzz.a

2.1M /usr/local/opt/sdl2/lib/libSDL2.a

I don't think people really mind a 20MB executable if it was a self contained application with good performance and UI.

Fyne manages to be below 10MB for a stand-alone application. A future release where we add more complete language support might have to be 12.5MB entry point sadly, but it’s still small by modern app standards.

Everything you just described takes work, but it isn't difficult. Applications both desktop and mobile have been doing all of that for decades now. Why hasn't somebody in the Go community managed it at some point in the past 10 years?

There are tons of other options.

My favourite alternative is probably https://crates.io/crates/conrod-core

That said you generally want widgets that look native in your platform, not some gui that feels like it's been taken out of a videogame.

As a backend-now-fullstack dev, i can tell you mobile dev is actually harder than backend now.

At its beginning, mobile apps were just a few simple screens mostly querying a server.

It is now closer to the gigantic desktop apps of the 90s (because most have to work offline), except with a much higher quality UX, as well as deep OS interaction (check the list of iOS extensions), AND internet connectivity.

That's why you see things like agent-based concurrency arriving on swift, which is mainly a client-side language.

Cross-platform is difficult

The Windows API through Delphi was simple and fast 20 years ago. Although the exe would take 400 KB space, so for smaller tasks I would bypass Delphi's stuff and call the Windows functions directly, and create 50 KB sized apps. (the A functions. Guess the Unicode W functions would already double the space)

But on Linux there is no way around Qt. (or Gtk, but the recent Gnome versions are horrible)

Although you could just make the Windows exe and run it through Wine. That is so simple to develop, and for any bug you can blame Wine.

Nowadays I use Lazarus. It is supposed to take the old Delphi code and create a native Windows,Qt,Gtk version from it. For Windows, it creates 2MB exes. Considering that Delphi made smaller files, it must be filling 3/4 of the file with garbage. The Qt,Gtk versions somewhat work, though Wine would probably more reliable

> But on Linux there is no way around Qt. (or Gtk, but the recent Gnome versions are horrible)

Except Fyne and others… we have a full desktop well underway and some distros are shipping Fyne apps and/or FyneDesk!

I tried Qt but the result was the furthest thing from satisfactory. My advice: don't bother.

Reply on news.ycombinator.com