Using Other Frontend Frameworks

How to use a framework that doesn't have a built-in template by dropping your own Vite project into the frontend directory

Wails ships built-in starter templates for a deliberately small set of frameworks:

That doesn’t mean those are your only options. The frontend of a Wails app is just a
web project — anything that builds to static HTML/CSS/JS will work. If your framework
of choice (Solid, Preact, Lit, Qwik, SvelteKit, Angular, …) doesn’t have a template, you
can scaffold it yourself in a couple of minutes.

How the frontend/ directory is used

Wails does not care which framework lives in frontend/. It only relies on a small,
framework-agnostic contract:

• frontend/dist/ is what ships. main.go embeds the built frontend with //go:embed all:frontend/dist and serves it from the asset server. Your build must

  output a static bundle to frontend/dist/ (Vite’s default output directory).

• The build is driven by frontend/package.json. During wails3 build, Wails runs the frontend’s build script; during wails3 dev it runs dev and proxies the Vite

  dev server for hot reload.

• Bindings are generated into frontend/bindings/. Wails inspects your registered Go services and writes a type-safe SDK there. You import from it like any other module:

  jsCopy

  import { GreetService } from "./bindings/changeme";

• The dev server runs on a fixed port. wails3 dev proxies Vite on the port in WAILS_VITE_PORT (default 9245), so set server.port to it with strictPort: true.

  This is ordinary Vite config — no Wails plugin is involved.

• Optional — typed custom events. The built-in templates also register the @wailsio/runtime/plugins/vite plugin. It’s only needed if you use typed custom

  events: it injects your generated event-type definitions into the runtime and makes the

  build fail until bindings have been generated. If you only use the string-based

  Events.On("time", …) API, you can leave it out.

Everything else — components, routing, state, styling — is entirely up to your framework.

Scaffold any framework with Vite

The fastest path is to start from a built-in template (so you get main.go, the
Taskfile, build assets and a working Go service), then replace frontend/ with a fresh
Vite project for your framework.

wails3 init -n myapp
cd myapp

# From the project root — e.g. Solid, Preact, Lit, Svelte, Vue, React, Vanilla
rm -rf frontend
npm create vite@latest frontend -- --template solid

cd frontend
npm install @wailsio/runtime

import { defineConfig } from "vite";

export default defineConfig({
  server: {
    host: "127.0.0.1",
    port: Number(process.env.WAILS_VITE_PORT) || 9245,
    strictPort: true,
  },
});

import { defineConfig } from "vite";
import wails from "@wailsio/runtime/plugins/vite";

export default defineConfig({
  plugins: [wails("./bindings")],
  server: { host: "127.0.0.1", port: Number(process.env.WAILS_VITE_PORT) || 9245, strictPort: true },
});

wails3 generate bindings

import { GreetService } from "./bindings/changeme";

const greeting = await GreetService.Greet("World");

wails3 dev

Frameworks with their own scaffolder

A few frameworks aren’t created through Vite’s create templates and have their own
tooling. They still work — just scaffold them with their native command and add the
Wails plugin afterwards:

• SvelteKit: npx sv create frontend. Use the static adapter (@sveltejs/adapter-static) so it builds to a static bundle, and disable SSR.

• Qwik: npm create qwik@latest. Use the static (SSG) adapter.

• Angular: scaffold with ng new, set outputPath to dist, and point the build script at ng build.

The rule is always the same: produce a static build in frontend/dist/, keep the
@wailsio/runtime Vite plugin (or import the runtime directly), and import your Go
bindings from frontend/bindings/.