Build desktop applications using Go and Web Technologies

https://github.com/wailsapp/wails

98•selvan•2mo ago

Comments

Exoristos•2mo ago

The lengths we will go to avoid writing a proper desktop application.

conceptme•2mo ago

because there is no proper UI library that does cross platform as well as the web

raffraffraff•2mo ago

Not just UI. I just wrote a KDE Plasma 6 widget for systemd-networkd / networkd and it was a nightmare.

kosolam•2mo ago

Why? Give more details please

robert_dipaolo•2mo ago

What about QT? I've used that in the past and it's really good for native apps.

Kelteseth•2mo ago

We are using it for our apps, but I can see why people do not use it for new projects:

1. The state of C++ is not great. Few developers, C++ footguns, complicated build systems, and generally slow progress, see my https://arewemodulesyet.org/

2. How Qt presents and licenses itself. Either you go LGPL or you have to pay big money for a commercial license, which will then infect all other apps as well. For example, when you have two Qt apps that talk to each other you must license _both_ commercially.

3. The split of Widgets and QML makes the ecosystem fragmented, because Widgets will never die. Even the Qt devs themselves are split about this. You can see this when example code for a new feature uses Widgets. QtCreator is also a nice example, where they reverted some new QML code quite a while ago and have not substantially added any new QML code since then.

4. Tooling: We use QML for everything and the tooling is not great. The language server is still super flaky and breaks, and developer tooling like the Chrome Dev Tools is virtually nonexistent.

5. Packaging is still also not great but has gotten better in the last few versions where Qt creates a deployment cmake script for you, but you still need logic for your own (vcpkg) packages.

rubymamis•2mo ago

Indeed, I wrote my note-taking app using Qt with QML: https://get-notes.com

adastra22•2mo ago

There are quite a few. Qt, React Native, Xamarin, and Flutter come to mind.

mono442•2mo ago

I wouldn't exactly call Flutter native. It uses its own rendering engine and doesn't necessarily behave like operating system native controls. It is not really different from using electron.

lloydatkinson•2mo ago

What are the Linux native controls?

GTK and KDE controls are native to GTK and KDE.

jdiff•2mo ago

Sure, but GTK and KDE aren't also cross-platform native.

Exoristos•2mo ago

Why should they be?

jdiff•2mo ago

Of course, there's no need for them to be. But this conversation started out with "why do people use web based UI solutions?" and "because there is no proper UI library that does cross platform as well as the web".

adastra22•2mo ago

"Native" seems to mean different things to different people. I'm mostly with you on this, but the tides are turning. In any case, the other 3 do use real native widgets.

prmoustache•2mo ago

Using the word native doesn't make any sense anymore.

brulard•2mo ago

Using electron at least uses some UI primitives from chromium. Flutter has thrown away all the usability and robustness of existing components and just reimplemented everything. It absolutely is different from electron

miki123211•2mo ago

Those are not native (on desktop) in any sense of the word. They don't use native controls. For that, you want WX or SWT, but those come with their own sets of problems.

On Windows, it's not even obvious what native is any more, even Microsoft just uses Web views. Mac is a bit better, but there are still 4 UI libraries to choose from (AppKit, UIKit through Catalyst, native SwiftUI and Catalyst SwiftUI).

I'm personally a fan of AppKit and Win32, but those are "dated" apparently.

gen2brain•2mo ago

I am working on the UI library and bindings for Go. Still not finished, but currently, the same app can be compiled for Win32, Cocoa, GTK2, GTK3, GTK4, Qt5, Qt6, and Motif. There is a web browser control, a GL canvas, and a regular canvas. I still work on the native table control, though.

https://github.com/gen2brain/iup-go

dardeaup•2mo ago

Impressive work!

gen2brain•2mo ago

IUP has custom-drawn controls for tables and cells (additional controls), and it uses another CD (canvas draw) library for that, not internal IUP Draw functions. I also started rewriting that to use the core IUP drawing functions instead. I also added a few more drawing functions, for rounded rectangles, bezier curves, and gradients. But ALL drivers, including Motif, have native table controls, so I really want to add one. Edit: Also, the GLcanvas control now has an EGL driver, with native Wayland support for GTK3, GTK4, and Qt6 (needs private headers). I modernized a bit of everything, added support for APPID, DARKMODE, etc. Linux uses xdg-open rather than hardcoding browsers. Win32 driver is not using the Internet Explorer web control but the WebView2 with custom loader, on GTK, you do not have to worry about the WebKitGTK, it will find the correct library with dlopen, etc, etc. But, there is still a lot to do.

dardeaup•2mo ago

Does IUP have a table control? I looked at the IUP website and didn't see one.

euroderf•2mo ago

Treeviews are where the rubber meets the road, IMHO.

adastra22•2mo ago

Qt Quick Controls, React Native, and Xamarin.Forms all generate honest-to-god native controls. E.g. Cocoa, Win32 or Windows Presentation Forms, etc.

jasode•2mo ago

gp was using a more restrictive definition of "native controls". I.e. "o/s builtin UI controls" vs "framework canvas painted elements".

For Windows, "native" would be the classic Win32 UI "common control" elements from "Comctl32.dll"[0] that is directly used by older GUI frameworks such as Windows Forms. Those map to classic Win32 API CreateWindow(L"BUTTON", ...). In contrast, the newer frameworks of WPF and Xamarin Forms and Qt Quick "paints controls on a canvas" which are not "native" and makes every app UI look different instead of standardized "look & feel" of common controls.

But others include custom-canvas painting UI objects as "native" -- as long as it's not Electron.

[0] https://learn.microsoft.com/en-us/windows/win32/controls/com...

adastra22•2mo ago

I've never used Qt Quick so I learned something new. It's like Flutter then.

React Native and .NET MAUI/Xamarin.Forms use real native UI widgets - WinUI on Windows and AppKit on macOS.

foresto•2mo ago

It's worth noting that some cross-platform toolkits are non-native in the strict sense, but mimic each platform's native controls.

This is harder to get right than one might think; small differences in text rendering look very much alien to me, and user input handling that isn't exactly the same as the platform's native conventions will make me stumble every time I perform common operations.

In my experience, Qt does an excellent job with this. It's not technically native (except on KDE and other Qt-based desktops), but it looks and feels right, or so close that I find it comfortable and well integrated with the rest of each platform I've tried. I haven't found any other cross-platform toolkit to match Qt in this area, so that's what I use for now.

Some day, I hope we'll see an alternative that accomplishes this at least as well as Qt, while being more flexible to license, easier to bind to other languages, and better at memory safety. (It's written in C++.) There seems to be renewed interest in GUI toolkit development lately, perhaps fueled by the excitement for newer languages like Zig and Rust, so perhaps I'll get my wish.

anthk•2mo ago

QT will mimick Win32 and Cocoa just fine.

MaxBarraclough•2mo ago

Assuming you use Qt Widgets.

As far as I can tell, Qt Quick doesn't have anything like the same set of polished widgets that integrate nicely into the target platform. It's been this way for years, they just don't seem interested in implementing them.

https://doc.qt.io/qt-6/qtquickcontrols-examples.html

pjmlp•2mo ago

Native is what comes from the platform vendor, secondly anything using native graphics APIs to render instead of shipping a browser on top.

Web is only native on ChromeOS and WebOS, because they don't have anything else as UI technology.

lloydatkinson•2mo ago

My cross platform application written in C#/.NET and Avalonia strongly disagrees with this crazy assertion.

I can also think of QT and GTK for other languages too.

anthk•2mo ago

Lazarus and Free Pascal and it will run several times faster than the web.

breve•2mo ago

These two are good:

https://avaloniaui.net/

https://platform.uno/

Ray20•2mo ago

But we want the web into the desktop, not the desktop into the web.

dualogy•2mo ago

That is both .NET stuff, Wails is one of various Go options.

divan•2mo ago

What's the reason not to write desktop apps in Flutter in 2025?

mock-possum•2mo ago

But I already know how to write a web app, I don’t know how to write a desktop app. It’s faster to just write and wrap a web app, and as far as most people can tell, it works just fine.

Ya gotta be practical.

adastra22•2mo ago

It's a strange world that I live in now.

gen2brain•2mo ago

To me, this argument always sounds like someone is being forced or threatened into creating a desktop app. It was never supposed to be easy; the goal is to create an app that users would want and will actually use.

pjmlp•2mo ago

I have been programming since 1986, have enough knowledge across several platforms, even though in 2025 distributed systems + Web UI pays the bills, I can still easily code native in a couple of UI frameworks.

Doing native UIs is only a matter of actually wanting to learn how to do it.

Exoristos•2mo ago

Why can't there be web developers and desktop developers?

foresto•2mo ago

You might find this appealing:

https://github.com/mappu/miqt

irq-1•2mo ago

Came here to say this. I just started with miqt and it seems to work really well. Go + Qt is near ideal.

diath•2mo ago

Making good GUI software requires a lot of iteration and trial and error before you're satisfied with the UI and UX. With a web-based tech, you make a change, auto reload triggers, you see the change almost instantly, making tweaking very easy. If you're working with a large Qt codebase, every little change to a header file requires a long ass compile times. It's really frustrating when you spend an hour just tweaking a few controls when you know it could have taken 5 minutes. Also, the reactive model as seen in web frameworks like React or Vue is much superior to the typical flow of state management in retained mode GUI applications in desktop frameworks. Until we have a decent solution that solves these problems, people will continue using tech like Electron or OS web views.

throwup238•2mo ago

It takes half a day to implement proper hot reload in QtQuick, which also has all the reactive features. Even less now that AI can just write it for you, and it’ll be more performant than Vite dev builds.

Coming to desktop app development from the web, I’ve got most of the same conveniences I’m used to like GammaRay as the inspector. The only real difference is I’m willing to wade through cmake and linking errors.

Even QWidgets is still super fast to develop with if you’re using PySide (although hot reload is a bit more difficult to implement and distribution becomes the nightmare).

diath•2mo ago

QML is not native, PySide uses Python. If you pick either of those, you lose native controls and low level language for performance, so again, may as well use web-based tech. Especially that HTML/CSS support significantly more styling/animating options than QML.

rubymamis•2mo ago

Qt Quick components are just C++ classes[1].

[1] https://github.com/qt/qtdeclarative

foresto•2mo ago

On the other hand, the developer convenience offered by Electron et al. comes by sacrificing runtime efficiency. It's astonishingly wasteful of resources, and that waste gets multiplied by every computer that runs the program, and every time it is run. The long-term costs saved by the developer are thereby amplified and pushed onto the users, in the form of shorter hardware upgrade cycles (and potentially increased electricity usage).

Just as a book will be read many more times than it is written, the burdens associated with a program's architecture will be borne many more times (collectively) by its users than by its developer. This is why I avoid web-based tech when building applications.

Relatedly, I'm glad to see that sustainable computing has begun showing up in global discourse.

PaulKeeble•2mo ago

Fyne is a pretty decent native solution for doing this in Go.

jdiff•2mo ago

It's fast, quick, and easy, but it's peak programmer UI. It's pretty unattractive, does not integrate well with its host OS (in terms of behavior), and does not integrate at all with accessibility tools.

At least last I looked into it.

pjmlp•2mo ago

When all that people want to use is how to use an hammer, they see nails everywhere.

hnlmorg•2mo ago

What’s not clear to me for either the readme nor their website, is how does this actually work?

With Electron, for example, a stripped down Chromium is shipped. So what does the web view rendering with this package?

adamors•2mo ago

The OS's native rendering engine, there's no embedded browser. Here's a more detailed writeup https://wails.io/docs/howdoesitwork

brulard•2mo ago

so similar to Tauri?

lifty•2mo ago

Anyone knows how wails v3 is progressing and if they are actually adding mobile support?

pylotlight•2mo ago

beta soon tm. mobile eventually with some PoCs around but nothing concrete yet sadly.

8-prime•2mo ago

I really enjoyed building small apps with wails. Even though people would prefer that we all used native UI frameworks, the DX is simply incomparable to that of web technologies.

And for most apps using browser based rendering won't be an issue. People often underestimate how optimized mondern browsers really are. And because Chromium is not shipped the bundle size is managable.

Not wanting to use JS on the backend I tried both Tauri and Wails and found the simplicity of Go to just work perfectly for my use-cases

DanielHB•2mo ago

Electron is quite bad on memory usage because it carries its own v8 environment on top of its own browser platform on top of using _another_ v8 environment for the nodejs part.

Tauri and Wails just use the one available in the OS (UIWebKit in macos, WebView2 in windows), it is also why they load so fast, you probably already have the heavy part loaded in memory. And, of course, brings a tiny statically linked binary instead of running on top of a massive runtime.

mnafees•2mo ago

We built a background daemon as a macOS menu bar app in Go, and the performance was surprisingly bad. The Go bindings for native UI frameworks ended up being massive RAM hogs. When we profiled it, we found that the GC essentially gave up under load, which explained why customers were reporting a simple menu bar app consuming 2.5GB+ of RAM on their Macs. We eventually abandoned the Go approach and switched to Electron. (Not-so) Surprisingly, both the DX and UX improved significantly for our use case. Personally, I’d still prefer Swift/C#/C++ for native desktop work (coming from a Qt C++ background), but given the business constraints at the time, Electron ended up being the most pragmatic choice.

arghwhat•2mo ago

> When we profiled it, we found that the GC essentially gave up under load

Hmm, the Go GC is really quite capable, so I wonder what kind of pathological load it was being presented with. Even then, when the GC "fails" it means elevated CPU load from collection.

The main thing I can think of would be the application "leaking" by having unintentional references (or worse, actually leaking through cgo bindings), or trashing the allocator to cause temporary spikes in between cleanups.

However, while I don't think Go was actually to blame here, I would never use native UI bindings to a language that isn't 1:1 compatible with the original design and memory management principles, as such bindings get disproportionaly large and complex. It just sets you up for a bad time.

mnafees•2mo ago

I totally agree :) I don't blame Go either. We were already a pure Go shop with a lot of focus on backend and infra systems engineering and were trying to venture into the desktop app market for our device monitoring software. Once we validated our idea with a rather buggy MVP haha, we quickly switched over to Electron and deployed on all 3 desktop OSes properly.

lenkite•2mo ago

> The Go bindings for native UI frameworks ended up being massive RAM hogs.

Which bindings did you use ?

mnafees•2mo ago

Been a while since I worked on it but I remember we used https://github.com/getlantern/systray at some point along with some interaction with fyne.io AFAIR.

jdndbdhd•2mo ago

Not wanting to discredit your experience, but that sounds very strange.

This sounds to me like leaking resources from the binding. Which binding did you use and how did you manage it's lifetime?

mnafees•2mo ago

I remember we used https://github.com/getlantern/systray at some point along with some interaction with fyne.io. That said, I do not remember how we managed the lifetime but we did test it thoroughly before deploying to our initial beta users (or so we thought :P). The GC behavior started to happen whenever the app was in the background, which it was supposed to be for the majority of the time.

lioeters•2mo ago

That is a surprising use case about Go and Electron (!), I would have imagined no contest for the superior performance of a compiled language, even with garbage collection. But the mention of "bindings for native UI frameworks", it was probably running the compiled code in a very tight loop, stressing the runtime. In contrast, Chromium specializes in UI with years of optimization.

Recently for a specific purpose I was reviewing options including Tauri, various WebView bindings, and in the end had to admit that Electron is probably the best approach in terms of feature set, development speed, etc.

leeman2016•2mo ago

I actually did something similar: business logic and most things written in Go, but the menu bar or tray icon done in native APIs like Win32 and Gtk. It was surprisingly very good experience overall. I have tried so many ways around it before settling for that.

mnafees•2mo ago

Very interesting! How would the Electron and Go processes communicate in this case? Did you expose a Unix socket or TCP port perhaps?

leeman2016•2mo ago

Ohh, my apologies for the confusion. I was just using Go as a menubar/tray icon application (with some OS-specific bindings) and meant to say that its performance was excellent. No electron involved

singularity2001•2mo ago

go install github.com/wailsapp/wails/v2/cmd/wails@latest

Why is that hidden behind a click and two walls of text?

p2detar•2mo ago

Have a look at Fyne as well [0], which is a Go-only native UI toolkit.

0 - https://fyne.io

Other discussions: - https://news.ycombinator.com/item?id=31785556 - https://news.ycombinator.com/item?id=19478079 - https://news.ycombinator.com/item?id=22291150

piotr_bulinski•2mo ago

We recently did evaluation of different ways of building a cross-plarform desktop app as a Go team. We have built a PoC with Wails and Fyne, and we love Fyne. After a week from making a decision to go with Fyne, we are now 90% done and already running first alpha tests with users (who also love the simplicity of it). Devs like the ease of development and a ton of dependencies we don’t need to worry about, since Fyne is a lot leaner than Wails.

Just my 2 cents ;)

PaulKeeble•2mo ago

I did a project a few years ago with Fyne and it was excellent.

fithisux•2mo ago

Gio-UI seems to be more suitable for desktop applications because it is native.

dualogy•2mo ago

Also very neat is DearImgui via either https://github.com/AllenDang/giu (Go-convenient wrapper) or https://github.com/AllenDang/cimgui-go/ (raw bindings)

pantulis•2mo ago

Oh the reference to Rails made me ponder how long have we come after the initial Joyent Slingshot vision for desktop apps based on, yes you guessed, Ruby on Rails.

nipperkinfeet•2mo ago

No more please. Please stop and build desktop applications with native languages.

moribvndvs•2mo ago

Not all of us have the resources to write and maintain the same app 2 to 6 times.

Start all of your commands with a comma

OpenCiv3: Open-source, cross-platform reimagining of Civilization III

The Waymo World Model

How we made geo joins 400× faster with H3 indexes

Unseen Footage of Atari Battlezone Arcade Cabinet Production

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

Jeffrey Snover: "Welcome to the Room"

Vocal Guide – belt sing without killing yourself

Monty: A minimal, secure Python interpreter written in Rust for use by AI

Show HN: I spent 4 years building a UI design tool with only the features I use

Hackers (1995) Animated Experience

Sheldon Brown's Bicycle Technical Info

Microsoft open-sources LiteBox, a security-focused library OS

Show HN: If you lose your memory, how to regain access to your computer?

An Update on Heroku

Was Benoit Mandelbrot a hedgehog or a fox?

PC Floppy Copy Protection: Vault Prolok

Dark Alley Mathematics

How to effectively write quality code with AI

Delimited Continuations vs. Lwt for Threads

What Is Ruliology?

Where did all the starships go?

Introducing the Developer Knowledge API and MCP Server

Female Asian Elephant Calf Born at the Smithsonian National Zoo

I now assume that all ads on Apple news are scams

I spent 5 years in DevOps – Solutions engineering gave me what I was missing

Understanding Neural Network, Visually

Why I Joined OpenAI

Learning from context is harder than we thought

Show HN: R3forth, a ColorForth-inspired language with a tiny VM

Start all of your commands with a comma

OpenCiv3: Open-source, cross-platform reimagining of Civilization III

The Waymo World Model

How we made geo joins 400× faster with H3 indexes

Unseen Footage of Atari Battlezone Arcade Cabinet Production

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

Jeffrey Snover: "Welcome to the Room"

Vocal Guide – belt sing without killing yourself

Monty: A minimal, secure Python interpreter written in Rust for use by AI

Show HN: I spent 4 years building a UI design tool with only the features I use

Hackers (1995) Animated Experience

Sheldon Brown's Bicycle Technical Info

Microsoft open-sources LiteBox, a security-focused library OS

Show HN: If you lose your memory, how to regain access to your computer?

An Update on Heroku

Was Benoit Mandelbrot a hedgehog or a fox?

PC Floppy Copy Protection: Vault Prolok

Dark Alley Mathematics

How to effectively write quality code with AI

Delimited Continuations vs. Lwt for Threads

What Is Ruliology?

Where did all the starships go?

Introducing the Developer Knowledge API and MCP Server

Female Asian Elephant Calf Born at the Smithsonian National Zoo

I now assume that all ads on Apple news are scams

I spent 5 years in DevOps – Solutions engineering gave me what I was missing

Understanding Neural Network, Visually

Why I Joined OpenAI

Learning from context is harder than we thought

Show HN: R3forth, a ColorForth-inspired language with a tiny VM

Build desktop applications using Go and Web Technologies

Comments