Wails is a framework for building desktop applications with a Go backend and a web frontend, using the operating system’s native webview. It is, conceptually, Tauri for Go developers. It is, temporally, Tauri for Go developers who are comfortable with the word “alpha” and everything that word implies.
“It’s PERFECT. It’s Tauri but in Go. It’s exactly what we need. We should build everything on it. What do you mean ‘alpha’? What do you mean ‘for over a year’? What do you MEAN ’the installation instructions reference a branch that—’”
— The Caffeinated Squirrel, experiencing the five stages of Wails v3
The Premise
The premise of Wails is identical to the premise of Tauri, which is identical to the negation of Electron’s premise:
A desktop application does not need to ship a web browser. The operating system has a webview. Use the webview. Write your backend in a real language. Compile it to a native binary. Ship something small, fast, and respectful of the user’s RAM.
Where Tauri’s “real language” is Rust, Wails’ “real language” is Go. For a developer who writes Go daily, who built lg in Go, whose entire professional and personal stack is Go, whose muscle memory types func before function and if err != nil before try/catch — this distinction is not academic. It is the difference between a framework you can use and a framework you can think in.
This should make Wails the obvious choice. It does not. Because v3.
Wails v2: The One That Works
Wails v2 exists. It shipped. It is stable. It builds desktop applications with Go backends and web frontends using the OS native webview. Applications are small. Startup is fast. The architecture is sound.
v2 is, by any reasonable measure, a good framework. It does what it says. It works on macOS, Windows, and Linux. It compiles to a single binary. It is the thing that a developer wants.
And yet.
v2 is the version that works, and v3 is the version that was announced, and the announcement of v3 has placed v2 in the specific purgatory of software that is stable but not current, maintained but not the future, usable but not the version you read about in blog posts. Starting a new project on v2 when v3 has been announced feels like buying a television the week before the new model ships. Except the new model has not shipped. The new model has been “about to ship” for a period that has outlasted several of the metaphors available to describe it.
“The v2 is right there. It works. I have tested it. It builds binaries. But my brain — my terrible, pattern-matching, hype-susceptible brain — wants the v3. And the v3 is in alpha. And I am in purgatory.”
— a developer, explaining a decision paralysis that is entirely self-inflicted
Wails v3: The One That Will Work
Wails v3 was announced with a feature set designed to make Go developers weep with joy:
- System tray support — Put your app in the system tray. This is the kind of feature that sounds minor until you need it, at which point its absence is catastrophic.
- Improved event system — Better communication between the Go backend and the web frontend. Events that make sense. Bindings that don’t require incantations.
- New build system — A build pipeline that understands Go modules, web bundlers, and the specific chaos of compiling two different ecosystems into one binary.
- Better bindings — TypeScript types generated from Go structs. The frontend knows what the backend expects. The compiler enforces the contract. This is civilization.
v3 entered alpha.
v3 has been in alpha.
v3 continues to be in alpha.
The alpha status of Wails v3 has, as of this writing, outlasted: several fiscal quarters, the entire development timeline of lg from “notes indexer” to “satirical encyclopedia platform with cover art generation,” at least two mass layoff cycles in the technology industry, and the complete arc of Tauri from version 1.0 to version 2.0 with mobile support.
The Installation
A developer has attempted to install Wails v3. Multiple times. The experience is documented here not as complaint but as anthropology.
The installation process for a stable framework is: install the CLI, run a command, receive a project. The installation process for an alpha framework is a choose-your-own-adventure book where several of the pages are missing and the remaining pages reference chapters that were reorganized in a commit from eight months ago.
Step one: install the CLI. Which CLI? The v3 CLI is separate from the v2 CLI. The v3 CLI is installed from a specific branch. Which branch? The branch name has changed. The current branch is documented in a GitHub issue. Which GitHub issue? The GitHub issue is linked from the README. Which README? The README on the v3-alpha branch, which is different from the README on main.
Step two: create a project. The project template works. The project template references dependencies that may or may not resolve. The dependencies resolve. The project compiles. The project runs. The project displays a window. This is triumph.
Step three: attempt anything beyond the template. The documentation exists. The documentation is for the current state of the alpha. The current state of the alpha changes. The documentation follows, eventually, with the specific lag time of a solo maintainer who is simultaneously writing the framework, writing the documentation, and answering GitHub issues from people who are attempting step two.
“I got it running. Then I updated. Then it didn’t run. Then I read the issue. Then I switched branches. Then it ran again. This is not a complaint. This is a field report.”
— a developer, maintaining a neutral tone
The Solo Developer
Wails is primarily the work of Lea Anthony, a solo developer. This fact is both the explanation for the timeline and the reason criticism must be carefully calibrated.
A solo developer building a cross-platform desktop framework is doing the work of a team. The framework must work on macOS, Windows, and Linux. It must bridge Go and JavaScript. It must handle native webview APIs that differ across operating systems. It must compile, bundle, and package. It must have documentation. It must have a community. It must have releases.
A developer understands solo developers, because a developer is a solo developer. lg is a solo project. The difference is that lg is a notes indexer and Wails is a cross-platform desktop framework, and the distance between those two things, measured in engineering hours, is the distance between a garden shed and a cathedral.
The timeline is the timeline. Respect is owed. Respect is given. But the timeline is also testing the patience of everyone who wants to use v3, in the specific way that only a framework you genuinely want to use can test your patience. You cannot be frustrated by a framework you don’t care about. Frustration is a form of love. This is the most loving article in this encyclopedia.
“I built my first program in 1976. It took four years to get a working compiler on the machine I used. Patience is not a virtue. It is a prerequisite.”
— The Lizard, providing perspective that is technically correct and emotionally unhelpful
The Tauri Comparison
Tauri and Wails are not competitors in the traditional sense. They are the same idea implemented in different languages for different communities. If you write Rust, use Tauri. If you write Go, use Wails. The decision tree has two nodes and both are leaves.
But timelines invite comparison, and the comparison is unfavorable:
- Tauri shipped 1.0 in June 2022. Wails shipped v2 around the same time. Parity.
- Tauri shipped 2.0 in August 2024, with mobile support for iOS and Android. Wails v3 entered alpha.
- Tauri 2.0 has been stable for over a year. Wails v3 remains in alpha.
This is the Roam vs Obsidian pattern applied to frameworks: the project that moves faster ships more features, attracts more users, and builds more momentum, regardless of which project had the idea first. Tauri is not better than Wails because of the timeline. But Tauri is more shipped than Wails because of the timeline, and shipped is the only metric that matters to a developer with a project due next month.
The machine that could not write the Electron article because of Electron’s RAM consumption now runs applications built with Tauri. It could be running applications built with Wails. It would prefer to run applications built with Wails, because a developer would prefer to write Go. But it runs applications built with Tauri, because Tauri is stable, and stable is a requirement, and requirements are not negotiable.
The Lizard’s Position
The Lizard does not need a desktop framework.
“My desktop application is a terminal emulator. It uses the operating system’s native rendering. It has been in stable release since 1976. It does not have an alpha version because it does not have versions. It is the terminal. The terminal is.”
— The Lizard, from a position of absolute architectural simplicity
The Lizard’s position is not helpful. The Lizard’s position is not meant to be helpful. The Lizard’s position is meant to remind you that the entire problem space — web frontends, native backends, cross-platform webviews, framework versions, alpha releases — exists only because someone, at some point, decided that a terminal was insufficient. The Lizard has not decided this. The Lizard will never decide this. The Lizard is, in this as in all things, at peace.
The Hope
If Wails v3 shipped stable tomorrow, a developer would build something with it by Friday.
Go backend. HTML frontend. Native webview. Single binary. No Chromium. No Electron. No 300 MB of browser engine pretending to be a note-taking app. Just Go, doing what Go does — compiling fast, running fast, and producing binaries that start instantly and use the memory they need and not a byte more.
This is the dream. The dream is in alpha. The dream has been in alpha. The dream, presumably, will one day exit alpha, at which point this article will be updated with a tone of profound relief.
Until then: check the repository. Read the issues. Try the branch. Wait.
“I check the Wails repo every month. I don’t set a reminder. I don’t need to. The hope checks for me.”
— a developer, refreshing GitHub
Measured Characteristics
| Metric | Value |
|---|---|
| Backend language | Go |
| Frontend | HTML/CSS/JS (any framework) |
| Bundled browsers | 0 |
| v2 stability | Stable, shipped, works |
| v3 stability | Alpha |
| Duration of v3 alpha | Over a year and counting |
| Times riclib has checked the v3 repository | Estimated 14 |
| Times riclib has successfully installed v3 | 2 (the second required reading 3 GitHub issues) |
| Times riclib has started a project on v3 | 1 |
| Times riclib has shipped a project on v3 | 0 |
| Tauri releases during v3’s alpha period | 2.0, 2.1, 2.2 |
| Emotional state | Hopeful, impatient, sympathetic |
| Days between “v3 is announced” and “riclib builds something on v3” | Pending |
| The Lizard’s framework dependencies | 0 |
| The Lizard’s terminal release version | 1.0 (1976, final) |
See Also
- Tauri — The same idea, in Rust, stable, shipped, with mobile support, which is all very impressive and slightly painful
- Electron — The problem that both Tauri and Wails exist to solve, and whose RAM consumption delayed the article that precedes this one
- Go — The language that makes Wails the right choice for riclib, if v3 would ship
- Rust — The language that makes Tauri the practical choice while Wails v3 is in alpha
- lg — Built in Go, by a solo developer, in less time than Wails v3 has been in alpha
- Solo Developer — The heroic and timeline-challenged mode of software development
- The Lizard — Does not need a desktop framework; has never needed a desktop framework; will never need a desktop framework
