Wails: Go backends and web frontends in one desktop binary, across two stable major versions

One binary replaces the built-in web server

The usual way to put a web interface on a Go program is to start an HTTP server inside it and send the user to a browser. Wails drops that arrangement. It wraps the Go code and the web frontend into a single binary, and its tooling handles project creation, compilation and bundling so you are not assembling those steps by hand.

The target audience is Go programmers who want to bundle an HTML, JS and CSS frontend with an application without creating a server and opening a browser to view it. That covers new desktop apps and existing Go programs that need a UI added. Because nothing listens on a port, there is no local server for the user to reach in a browser tab, and no address to document or firewall. The backend stays standard Go, and the frontend can use whichever web technology you already know, with pre-built templates to start from.

Go methods called from JavaScript, with TypeScript types generated for you

The bridge between the two halves is where Wails does most of its work. Frontend code can call Go methods directly from JavaScript, and Wails auto-generates TypeScript definitions for your Go structs and methods. When a Go struct gains a field, the generated definitions carry that change to the frontend, so the compiler on the TypeScript side catches mismatches that would otherwise surface at runtime.

For communication that is not a simple call and return, there is a unified eventing system shared by Go and JavaScript, so either side can emit and listen for the same events. On top of that, Wails exposes native dialogs and menus, native dark and light mode support, and translucency and frosted window effects. These are the pieces that make a webview window behave like a desktop application rather than a page in a frame.

No embedded browser means the operating system renders your UI

Wails uses native rendering engines and does not embed a browser. That is the basis of its claim to be lightweight, and it is also a constraint you inherit. Your frontend is drawn by whatever web engine the host platform provides, not by a single engine you ship and control.

The practical result is that a layout or a JavaScript feature that works on your development machine has to be checked on each operating system you distribute to, since you are not guaranteed the same engine everywhere. If your product depends on identical rendering across all platforms, or on a specific browser feature, that is a reason to look harder before committing. The README's own answer to whether Wails replaces Electron is that it depends on your requirements, and that with native menus and dialogs it could be considered a lightweight Electron alternative.

v2 and v3 are both stable, with different CLI names and docs sites

Wails has two active versions, and both are marked stable. They install as different commands. Version 2 installs a CLI called `wails`:

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

Version 3 installs a CLI called `wails3`:

go install github.com/wailsapp/wails/v3/cmd/[email protected]

The documentation is split too: v2 lives at v2.wails.io and v3 at wails.io. The repository keeps both trees side by side in `v2/` and `v3/` directories. For a new user, this means the first decision is not how to install Wails but which Wails to install, and search results or tutorials you find may be written for the other one. Check which documentation site a guide belongs to before following it, because commands for one CLI name do not apply to the other.

The v3 install line is pinned behind the latest release

The two install commands are not pinned the same way. The v2 command uses `@latest`, so it follows new v2 releases. The v3 command is fixed at `@v3.0.0`. Meanwhile v3.1.0 was published on November 1, 2026, and nightly builds tagged v3.2.0-nightly appeared on November 1 and November 2.

If you copy the v3 command as written, you get v3.0.0, not the newest stable v3. That is a reasonable default for reproducibility, but it is easy to miss, and a bug report or a doc page written against v3.1.0 may not match what you installed. Decide which v3 release you want, change the version suffix on purpose, and record it in your build scripts. Treat the nightly tags as previews of v3.2.0 rather than releases to ship on.

Multiplatform is claimed without a platform list on the front page

The feature list says Multiplatform but does not name which operating systems each major version targets, and installation details are sent to the v2 and v3 documentation sites. The repository does carry an `IOS_ARCHITECTURE.md` file at the top level, which tells you mobile work is at least being written about, but that file name is not a support statement.

The consequence for anyone planning a release is that the target list has to come from the versioned docs, not from the README. If you need a specific platform, especially a mobile one, confirm it in the documentation for the exact version you pinned before writing code, since v2 and v3 are separate codebases and an answer for one does not carry over to the other.

Feature changes go through Wails Enhancement Proposals

Wails does not take feature requests as ordinary issues. New functionality and public behaviour changes go through a WEP, a Wails Enhancement Proposal, submitted as a draft pull request. The roadmap sits in GitHub discussion 1484. If you want a capability added, the expected path is to write the proposal, not to open an issue and wait.

Documentation for v3 is written with M-Press, and the contributor guide for it covers downloads, installation, preview and submitting a PR. The repository also includes `CONTRIBUTING.md`, `SECURITY.md`, a `CHANGELOG.md`, translated READMEs in eleven languages beyond English, and a `Taskfile.yaml` at the root. The most recent push landed on November 2, 2026, the same day as the latest nightly tag. The name comes from Webview on Rails, and it is also a homophone of Wales, the author's country.

Editorial conclusion

Wails fits Go programmers who want a desktop UI written in familiar web tooling without running a local server or shipping a bundled browser, including teams adding a frontend to an existing Go program. It fits less well if you need one rendering engine across every platform, or if a framework with two stable majors and daily nightlies is more churn than your team can absorb. Before starting, pick v2 or v3 deliberately, check that the version pinned in your install command is the one you want, and confirm your target operating systems in that version's docs.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes