Wails v3 beta: Go desktop apps with native webviews, no embedded browser
Create beautiful applications using Go
At a glance
- What is it?
- Wails wraps Go code and a web frontend into a single binary using native rendering engines, and v3 is now in beta. This review covers the mechanism, the CLI workflow, the limitations, and who should wait for stable.
- Who is it for?
- Adopt Wails v3 beta if you are a Go programmer who wants a lightweight desktop app with an HTML/JS/CSS frontend and native menus and dialogs, and you can tolerate beta instability and API changes. Do not adopt it if you need production stability, a fully mature ecosystem, or if you prefer a server-based architecture.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Wails solves: no server, no browser tab
The README frames the problem clearly: the traditional way to give a Go program a web interface is to run a built-in web server and open a browser. Wails replaces that with a single binary that wraps both the Go code and the web frontend. The frontend is rendered by a native rendering engine, not an embedded browser. That distinction matters. An embedded browser, like the one in Electron, ships a full Chromium runtime, which balloons binary size and memory use. Wails uses the operating system's own webview, so the app feels lighter and starts faster. The target user is a Go programmer who wants to bundle an HTML/JS/CSS frontend without managing a server process or forcing the user to open a browser. The FAQ explicitly says it is not a strict Electron alternative, but it does offer native menus and dialogs, so it can serve as a lightweight one.
How it works: native webviews, Go bindings, and a unified event system
The core mechanism is a bridge between Go and the frontend. The README lists the key features: Go methods can be called from JavaScript, and TypeScript definitions are auto-generated for Go structs and methods. That means you define your backend logic in Go, and the frontend gets typed access to it. There is also a unified eventing system between Go and JavaScript, so the two sides can push messages to each other without polling. Native dialogs and menus are supported, along with dark and light mode and modern translucency effects like frosted windows. The rendering is done by native engines, which is the architectural difference from Electron. The README does not specify which engine is used on each platform, only that it is native. The v3 roadmap is managed through Wails Enhancement Proposals (WEPs), submitted as draft pull requests rather than feature-request issues, which suggests a structured approach to public behaviour changes.
Getting started: two versions, two CLI tools
Wails has two active versions. v2 is stable and installed with `go install github.com/wailsapp/wails/v2/cmd/wails@latest`. v3 is in beta and installed with `go install github.com/wailsapp/wails/v3/cmd/wails3@latest`. The README points to full installation instructions at wails.io for v2 and v3.wails.io for v3. The CLI tool handles project creation, compilation, and bundling, so the workflow is: install the CLI, run a scaffold command, write your Go backend and your frontend, then build. The README does not list the exact scaffold commands, but it says the CLI is powerful and makes it easy to generate and build projects. The v3 beta releases are frequent: v3.0.0-beta.15 came out on 2026-08-27, with beta.14 and beta.13 on the two days before. That velocity suggests active development, but also that the API may still be shifting.
Limitations and failure modes: beta instability and platform dependencies
The most obvious limitation is that v3 is in beta, and the release cadence shows rapid change. Three beta releases in three days means breaking changes can land at any moment. The README does not list known issues, but the WEP process implies that public behaviour changes are managed deliberately, which is a sign that breaking changes will come with documentation. Another limitation is the reliance on native rendering engines. The README boasts 'no embedded browser', but that means the app's appearance and capabilities depend on the webview provided by the operating system. On some platforms, that webview may lag behind the latest web standards, which can limit your frontend choices. The FAQ also says Wails is not a strict Electron alternative, so if you need the full Chromium feature set, Wails is the wrong tool. The README does not mention how the native webview handles complex CSS or WebGL, so you should test your frontend against the target platform before committing.
Alternatives: Electron and the traditional server approach
The README explicitly addresses Electron in the FAQ. Electron bundles Chromium, which gives you a consistent rendering engine across platforms but at the cost of binary size and memory. Wails uses native engines, so it is lighter but at the mercy of platform webviews. The other alternative is the traditional approach the README describes: run a built-in web server and open a browser. That approach is simpler to debug and works with any browser, but it requires the user to have a browser open and the app to manage a server lifecycle. Wails avoids both of those. The choice comes down to whether you need a single binary with native OS integration, or whether a server-based web UI is acceptable. If you need the full web platform, Electron is the safer bet. If you want a lightweight Go-native app, Wails is the path.
Maintenance and upgrade cost: MIT license and a structured proposal process
Wails is MIT licensed, which the README confirms. That means you can use it in commercial projects without licensing fees, but you should review the license text yourself for any conditions. The README does not include a changelog or upgrade guide, but the WEP process is the mechanism for public behaviour changes. That is a positive sign for maintenance: changes are proposed, reviewed, and documented, rather than made silently. The cost of upgrading from v2 to v3 is not described in the README, but the separate CLI tools suggest the APIs differ. If you adopt v3 now, expect to track beta releases and adjust your code as the API stabilises. The project is actively maintained, with a large contributor list that the README says is too big to show, and a Discord server for community support.
Editorial conclusion
Adopt Wails v3 beta if you are a Go programmer who wants a lightweight desktop app with an HTML/JS/CSS frontend and native menus and dialogs, and you can tolerate beta instability and API changes. Do not adopt it if you need production stability, a fully mature ecosystem, or if you prefer a server-based architecture. Before committing, verify that the v3 API and the WEP process cover the features you rely on, and check the v3 documentation for any breaking changes from v2. The project is under active development, with three beta releases in three days, so review the changelog and test your specific use case against the current beta before building anything critical.
Community notes