Wails - Desktop Apps That Don't Eat RAM

Look, if you're tired of Electron apps eating your RAM like a hungry hippo, Wails might be worth your time. It's a desktop app framework that lets you build apps with Go backends and web frontends, but without the Chrome-bundling bullshit that makes Electron apps so bloated.

Wails has been around since 2019 and sits at around 30k GitHub stars - decent traction in the Go community. The project is actively maintained, and they've been working on Wails v3 in alpha, which finally adds multi-window support (thank god).

How It Actually Works

Instead of shipping an entire Chrome browser with your app, Wails uses whatever webview is already on the user's system:

• Windows: WebView2 (Edge-based)
• macOS: WebKit
• Linux: WebKit via GTK

Your Go code handles the backend stuff - database connections, file I/O, system integration - while the frontend is just regular web tech. The magic happens at the boundary where Wails auto-generates TypeScript bindings for your Go structs, so you can call Go functions from JavaScript without the usual serialization dance.

Why You Might Give a Shit

File Size Reality Check: My last Wails app was 23MB. The same functionality in Electron would've been 150MB+. That's not theoretical - I actually built both versions to compare. The framework comparison data confirms this: Wails ~10MB vs Electron ~306MB for equivalent apps.

Memory Usage: A basic Wails app uses 40-80MB RAM versus Electron's 150-300MB baseline. Your users will thank you when their laptop fan isn't constantly spinning.

Development Speed: Once you get past Go's learning curve, the type-safe bindings are genuinely useful. No more wondering if that API call will work until runtime - if it compiles, the frontend/backend communication works.

But let's be honest about the downsides: you need to know Go, the ecosystem is smaller than Node.js, and debugging native crashes requires actual debugging skills, not just console.log spam.

Type-Safe Bindings (Actually Pretty Nice)

When you change a Go struct, Wails regenerates TypeScript definitions automatically. This is genuinely useful - no more guessing what your backend API looks like or getting runtime errors from typos.

type User struct {
    ID    int    `json:"id"`
    Name  string `json:"name"`
    Email string `json:"email"`
}

Becomes:

class User {
    id: number;
    name: string;
    email: string;
}

Here's where it gets messy: Complex nested structs? The TypeScript gets weird as hell. Keep your API simple and you'll be fine.

Hot Reload (Works 80% of the Time)

When it works, hot reload is great. When it doesn't, you'll be doing Ctrl+C and wails dev again. The Node process memory leak issue on Windows is particularly annoying - RAM just keeps growing until you restart.

Pro tip: If hot reload stops working, restart the dev server. Don't waste 20 minutes trying to figure out why your changes aren't showing up.

Multi-Window Support (Finally!)

Wails v3 adds proper multi-window support, which was a massive pain point in v2. You can now create window hierarchies and manage them independently without hacky workarounds.

Still in alpha though, so don't bet your production app on it yet.

Framework Support Reality

Yes, Wails works with React, Vue, Svelte, etc. But here's what they don't tell you:

• React: Works great, but complex state management patterns can be tricky with the Go bridge
• Vue: Solid choice, especially Vue 3 with the Composition API
• Svelte: My personal favorite for Wails apps - lightweight and plays nice with the Go backend
• Vanilla JS: Don't be a masochist unless you're building something tiny

The Development Experience Truth

What's Good: The CLI is solid, cross-compilation mostly works, debugging Go code is standard.

What Sucks:

• WebView debugging requires platform-specific tools - Safari dev tools on Mac are clunky as hell, Edge DevTools on Windows work better
• Native crashes give you cryptic error messages like "signal 11" with zero context
• Hot reload breaks when you have circular imports between Go and JS - spent 3 hours on that one
• Windows builds can randomly fail with dependency issues, especially with CGO
• The docs assume you already know Go well

Time to Productivity: If you know Go, maybe a day. If you're learning Go, budget 2-3 weeks to get comfortable with the language first.