If you're building desktop apps with Go and Wails, you've probably hit this wall: how do you manage frontend state that stays in sync with your Go backend?

Most developers reach for React or Vue out of habit. But there's a lighter, faster approach that fits Wails perfectly — Alpine.js x-data stores.

The Problem with Heavy Frameworks in Wails

Wails renders your frontend in a native webview. Every kilobyte of JavaScript you ship adds startup latency to your desktop app. React's runtime alone is ~40KB gzipped. Add a state management library like Redux or Zustand and you're pushing 60KB+ before you write a single line of business logic.

Your users expect desktop apps to open instantly. Heavy JS frameworks fight that expectation.

Why Alpine.js Fits Wails Like a Glove

Alpine.js is ~15KB gzipped — runtime included. But the real win isn't size. It's the architecture:

// A global store that syncs with your Go backend
Alpine.store('notes', {
  items: [],
  async load() {
    this.items = await window.go.main.App.GetNotes();
  },
  async save(note) {
    await window.go.main.App.SaveNote(note);
    await this.load();
  }
});

<div x-data x-init="$store.notes.load()">
  <template x-for="note in $store.notes.items">
    <div x-text="note.title"></div>
  </template>
</div>

That's it. No build step gymnastics. No provider wrappers. No action creators. Your Go methods are called directly from the store, and Alpine's reactivity system updates the DOM automatically.

The Multi-Store Pattern

For production apps, you split concerns across multiple stores:

• Alpine.store('app') — global state (theme, sidebar, window size)

• Alpine.store('notes') — domain data bound to Go

• Alpine.store('settings') — persistent user preferences via Go's filesystem

Each store calls its own Go backend methods. The stores don't know about each other, but Alpine's reactivity means the UI stays consistent across all of them.

When This Breaks Down

Alpine.js x-data stores aren't perfect for every case:

• Complex computed dependency chains — Alpine's reactivity is simpler than Vue's. Deep nested computed values can get messy.

• Large lists with frequent updates — No virtual scrolling built in. For 10,000+ row tables, you'll need a complement.

• Team standardization — If your team already knows React, the productivity gain of Alpine may not offset the learning curve.

For most Wails desktop apps — dashboards, tools, utilities, CRUD apps — Alpine.js x-data stores are the sweet spot of simplicity, performance, and Go integration.

Going Deeper

I built an entire course around these patterns — from Wails fundamentals through multi-store architecture to shipping cross-platform builds. If you want the full playbook with production code, check out the course here at Wails Workshop.