Create beautiful applications using Go. Contribute to wailsapp/wails development by creating an account on GitHub.
The traditional method of providing web interfaces to Go programs is via a built-in web server. Wails offers a different approach: it provides the ability to wrap both Go code and a web frontend into a single binary. Tools are provided to make this easy for you by handling project creation, compilation and bundling. All you have to do is get creative!
- Use standard Go for the backend
- Use any frontend technology you are already familiar with to build your UI
- Quickly create rich frontends for your Go programs using pre-built templates
- Easily call Go methods from Javascript
- Auto-generated Typescript definitions for your Go structs and methods
- Native Dialogs & Menus
- Native Dark / Light mode support
- Supports modern translucency and "frosted window" effects
- Unified eventing system between Go and Javascript
- Powerful cli tool to quickly generate and build your projects
- Multiplatform
- Uses native rendering engines - no embedded browser!
The project roadmap may be found here. Please consult it before creating an enhancement request.
The installation instructions are on the official website.
This project is supported by these kind people / companies:
-
Is this an alternative to Electron?
Depends on your requirements. It's designed to make it easy for Go programmers to make lightweight desktop applications or add a frontend to their existing applications. Wails does offer native elements such as menus and dialogs, so it could be considered a lightweight electron alternative.
-
Who is this project aimed at?
Go programmers who want to bundle an HTML/JS/CSS frontend with their applications, without resorting to creating a server and opening a browser to view it.
-
What's with the name?
When I saw WebView, I thought "What I really want is tooling around building a WebView app, a bit like Rails is to Ruby". So initially it was a play on words (Webview on Rails). It just so happened to also be a homophone of the English name for the Country I am from. So it stuck.
The contributors list is getting too big for the readme! All the amazing people who have contributed to this project have their own page here.
This project was mainly coded to the following albums:
Read the original article
Comments
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.
> 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.
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.
By ohboybotagain 2025-11-2415:01 [dead]
By leeman2016 2025-11-2413:301 reply 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.
By mnafees 2025-11-2416:53 Very interesting! How would the Electron and Go processes communicate in this case? Did you expose a Unix socket or TCP port perhaps?
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.
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?
By mnafees 2025-11-2411:50 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.
> The Go bindings for native UI frameworks ended up being massive RAM hogs.
Which bindings did you use ?
By mnafees 2025-11-2411:47 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.
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
By DanielHB 2025-11-2418:39 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.
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
By piotr_bulinski 2025-11-2412:38 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 ;)
By PaulKeeble 2025-11-2415:41 I did a project a few years ago with Fyne and it was excellent.
