# Wails: one repository, two CLI binaries, and a v3 that is still beta

> Wails wraps Go code and a web frontend into a single desktop binary instead of running a built-in web server, and the repository carries both a stable v2 and a beta v3 with different command names and different documentation sites. Nothing in it publishes a size, a benchmark, or a comparison against Electron or Tauri.

**wailsapp/wails** — Create beautiful applications using Go

- Repository: https://github.com/wailsapp/wails
- Website: https://wails.io
- Stars: 36,343 · Forks: 1,864
- Language: Go
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/wailsapp-wails

## Two versions, two binary names, two documentation sites

The install table is the most consequential thing in the file, because the two versions do not share a command name. The stable line installs as one binary:

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

and the beta line installs as a different one:

```
go install github.com/wailsapp/wails/v3/cmd/wails3@latest
```

Documentation splits the same way, with v2 pointing at wails.io and v3 at v3.wails.io, and the full installation instructions live on those two sites rather than in the repository. The consequence for a team is that a developer who follows a v2 tutorial after installing v3 gets a project that does not match the guide, and nothing in the file will warn them, because both commands are correct and both are listed in the same table. Decide the version first, then the guide, and keep the two out of the same PATH naming scheme in your own onboarding notes.

## v2/ and v3/ are both checked into the same tree

The repository root carries a v2 directory and a v3 directory side by side, plus a docs directory, a website directory, a tools directory, a scripts directory, an assets directory, a history directory, and a .release directory. The version split is therefore a directory split, not a branch split, and the default branch is master with both majors present in it at once. Supporting files tell you what the project considers its working surface: a Taskfile.yaml instead of a Makefile, a CHANGELOG.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, CONTRIBUTORS.md, an AGENTS.md, and a dedicated IOS_ARCHITECTURE.md document. The layout means a contributor reading the repository is looking at two products' worth of code, and a user picking a version by reading source rather than the table has no in-repo signal about which one is authoritative for new work.

## Beta tags landed on three consecutive weekdays

The three most recent releases are v3.0.0-beta.24 on 2026-09-20, v3.0.0-beta.25 on 2026-09-22, and v3.0.0-beta.26 on 2026-09-25, and the last push to the repository landed the same day as the newest tag. That cadence says the v3 line is being iterated on in public, at a rate of days rather than months, while v2 remains the one labelled Stable. Beta numbering also carries the implicit warning that identifiers may still move: a project that pins beta.25 is pinning something the maintainers themselves label unfinished. The practical consequence is a deployment decision: v2 is what you ship when the label matters, and anyone who wants v3 features should treat each tag as a moving target and read the changelog between upgrades rather than assuming the major version number is the risk.

## Behaviour changes arrive as WEP draft pull requests

There is a formal proposal mechanism, and it is unusual in one respect: new functionality and public behaviour changes use a WEP, a Wails Enhancement Proposal, and are submitted as a draft pull request rather than as a feature request issue. The proposal documents live under v3 in the repository at v3/wep/README.md, and the broader roadmap is maintained as a GitHub discussion rather than a file. The mechanism has a direct cost for a consumer. Because public behaviour changes are proposed in the same channel as features, the difference between a new capability and a breaking adjustment to an existing one is a review question, not a version number, and the version table will show you beta moving while an existing method changes shape. Read the WEPs for the areas you depend on before you upgrade, and treat the changelog as the only place the two are separated.

## No embedded browser, and no stated engine requirements

One line in the feature list carries most of the architectural weight: the project uses native rendering engines, with the emphasis that there is no embedded browser. Everything else in the list is a consequence of that choice. Frontend code is yours to choose, Go methods are callable from JavaScript, TypeScript definitions are generated for your Go structs and methods, and a unified eventing system carries messages in both directions. Native dialogs and menus, dark and light mode, and translucency and frosted window effects are listed as available. What the file does not state is which native engine backs which platform, what a target machine must have installed, or what the resulting binary weighs. The absence matters for the stated advantage: without a bundled browser, a lighter application is a reasonable expectation, but no number is published here to plan against.

## The FAQ answers the Electron question conditionally

Asked whether this is an alternative to Electron, the project answers that it depends on your requirements, and describes the goal as making it easy for Go programmers to build lightweight desktop applications or add a frontend to existing ones. It then adds that Wails does offer native elements such as menus and dialogs, so it could be considered a lightweight Electron alternative. That is the whole comparison: a conditional statement plus two named features. Aimed at a different question, the answer is sharper, describing Go programmers who want to bundle an HTML, JS, and CSS frontend with their applications without creating a server and opening a browser to view it. For an evaluation, the gap is what matters. The repository publishes no feature table, no binary size, no memory figure, and no benchmark, so any claim that it is lighter has to be measured by you.

## A Go framework carrying Prettier, Task, and Qodana configs

The root tells you what the maintainers automate, and the answer spans several ecosystems. A .prettierrc.yml and a .prettierignore format the web assets, which is why a Go project ships JavaScript formatting rules. Taskfile.yaml is the task runner, and mpress.yaml appears alongside it as a second automation file. Static analysis is configured in qodana.yaml, pull request review behaviour in .coderabbit.yaml, and the repository also carries a .replit directory for the hosted workspace and a scripts directory. With a tools directory and a .release directory for release work, the operational surface around the code is substantial. The consequence is that a contributor needs more than a Go toolchain to match the project's own checks, and the README explains none of these files, so a new contributor learns them by reading configuration rather than from a documented workflow.

## Twelve translated READMEs, and a credits page that moved off the repository

The entry point is duplicated in twelve languages: English, Simplified Chinese, Japanese, Korean, Spanish, Brazilian Portuguese, Russian, French, Uzbek, German, Turkish, and Indonesian, each as a separate README file in the root. That is a real accessibility asset, and it is also a maintenance surface, because every feature and version change has to be reflected across a dozen files. Contributors took the other path: the README states that the contributors list is getting too big to keep there, and points to wails.io/credits instead, with a CONTRIBUTORS.md also in the root. Two more documents are worth knowing about before you plan a port. IOS_ARCHITECTURE.md covers the iOS side on its own, and the project is described as multiplatform without a per-platform support table, so platform coverage is something you verify against the documentation rather than assume from the feature list.

## Conclusion

Pick Wails when you are a Go programmer who wants a desktop binary with a web UI and native menus and dialogs, and when you can accept tracking a beta for new work. Do not pick it because you want a published answer on how it compares to Electron, Tauri, Fyne, or Flutter, because the project answers that question conditionally and publishes no measurements. Before you commit, install the version whose status matches your risk appetite, read the WEP process to see how much a public behaviour change would cost you, and confirm on the platform documentation which native rendering engine your target desktop relies on.

## FAQ

### How does Wails work?

Instead of the traditional approach of a built-in web server, Wails wraps both Go code and a web frontend into a single binary, with tools handling project creation, compilation and bundling. Go methods are callable from JavaScript, TypeScript definitions are generated for Go structs and methods, and a unified eventing system carries events between the two sides.

### how to install wails cli

There are two active versions with different binary names. The stable v2 installs with go install github.com/wailsapp/wails/v2/cmd/wails@latest, and the beta v3 installs with go install github.com/wailsapp/wails/v3/cmd/wails3@latest, with full instructions on wails.io and v3.wails.io.

### What are the key differences between Wails and Electron?

The project answers that it depends on your requirements, and that it is designed to make lightweight desktop applications easy for Go programmers or to add a frontend to an existing application. It adds that Wails does offer native elements such as menus and dialogs, so it could be considered a lightweight Electron alternative, and no benchmark is published.

### what is wails

A way to build desktop applications using Go and web technologies, wrapping Go code and a web frontend into a single binary. It is aimed at Go programmers who want to bundle an HTML, JS, and CSS frontend with their applications without creating a server and opening a browser to view it.

### wails vs tauri

The repository makes no comparison with Tauri. What it claims for itself is standard Go on the backend, any frontend technology, native rendering engines with no embedded browser, native dialogs and menus, dark and light mode, translucency effects, a unified eventing system, and a CLI for generating and building projects.

## Sources

- [Official documentation](https://wails.io)
- [Official README](https://github.com/wailsapp/wails#readme)
- [Project repository](https://github.com/wailsapp/wails)
- [Release notes](https://github.com/wailsapp/wails/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wailsapp-wails