8 ms·
Build desktop applications using Go and Web Technologies
- Exoristos 10mo agoThe lengths we will go to avoid writing a proper desktop application.
- conceptme 10mo agobecause there is no proper UI library that does cross platform as well as the web
- raffraffraff 10mo agoNot just UI. I just wrote a KDE Plasma 6 widget for systemd-networkd / networkd and it was a nightmare.
- kosolam 10mo agoWhy? Give more details please
- robert_dipaolo 10mo agoWhat about QT? I've used that in the past and it's really good for native apps.
- Kelteseth 10mo agoWe 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/ 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 10mo agoIndeed, I wrote my note-taking app using Qt with QML: https://get-notes.com https://get-notes.com
- adastra22 10mo agoThere are quite a few. Qt, React Native, Xamarin, and Flutter come to mind.
- mono442 10mo agoI 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 10mo agoWhat are the Linux native controls? GTK and KDE controls are native to GTK and KDE.
- jdiff 10mo agoSure, but GTK and KDE aren't also cross-platform native.
- adastra22 10mo 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 10mo ago
- lloydatkinson 10mo agoMy 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 10mo agoLazarus and Free Pascal and it will run several times faster than the web.
- breve 10mo agoThese two are good: https://avaloniaui.net/ https://avaloniaui.net/ https://platform.uno/ https://platform.uno/
- divan 10mo agoWhat's the reason not to write desktop apps in Flutter in 2025?
- mock-possum 10mo agoBut 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 10mo agoIt's a strange world that I live in now.
- gen2brain 10mo agoTo 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 10mo agoI 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 10mo agoWhy can't there be web developers and desktop developers?
- foresto 10mo agoYou might find this appealing: https://github.com/mappu/miqt https://github.com/mappu/miqt
- irq-1 10mo agoCame here to say this. I just started with miqt and it seems to work really well. Go + Qt is near ideal.
- diath 10mo agoMaking 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 10mo agoIt 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 10mo agoQML 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 10mo agoQt Quick components are just C++ classes[1]. [1] https://github.com/qt/qtdeclarative https://github.com/qt/qtdeclarative
- foresto 10mo ago
- PaulKeeble 10mo agoFyne is a pretty decent native solution for doing this in Go.
- jdiff 10mo agoIt'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 10mo agoWhen all that people want to use is how to use an hammer, they see nails everywhere.
- hnlmorg 10mo agoWhat’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?
- lifty 10mo agoAnyone knows how wails v3 is progressing and if they are actually adding mobile support?
- pylotlight 10mo agobeta soon tm. mobile eventually with some PoCs around but nothing concrete yet sadly.
- 8-prime 10mo agoI 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 10mo agoElectron 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 10mo agoWe 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 10mo 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 10mo agoI 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.
- ohboybotagain 10mo ago[dead]
- singularity2001 10mo agogo install github.com/wailsapp/wails/v2/cmd/wails@latest Why is that hidden behind a click and two walls of text?
- p2detar 10mo agoHave a look at Fyne as well [0], which is a Go-only native UI toolkit. 0 - https://fyne.io https://fyne.io Other discussions: - https://news.ycombinator.com/item?id=31785556 https://news.ycombinator.com/item?id=31785556 - https://news.ycombinator.com/item?id=19478079 https://news.ycombinator.com/item?id=19478079 - https://news.ycombinator.com/item?id=22291150 https://news.ycombinator.com/item?id=22291150
- piotr_bulinski 10mo agoWe 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 10mo agoI did a project a few years ago with Fyne and it was excellent.
- fithisux 10mo agoGio-UI seems to be more suitable for desktop applications because it is native.
- dualogy 10mo agoAlso very neat is DearImgui via either https://github.com/AllenDang/giu https://github.com/AllenDang/giu (Go-convenient wrapper) or https://github.com/AllenDang/cimgui-go/ https://github.com/AllenDang/cimgui-go/ (raw bindings)
- pantulis 10mo agoOh 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 10mo agoNo more please. Please stop and build desktop applications with native languages.
- moribvndvs 10mo agoNot all of us have the resources to write and maintain the same app 2 to 6 times.