When to Use What

The What framework is an HTML-native, server-rendered full-stack framework. It's a deliberate fit for a specific class of apps — and an honest mismatch for a few others. Here's how to tell the difference before you commit.

A great fit

CRUD apps and internal tools — forms, lists, dashboards, admin panels. The parts What makes trivial (server state, forms, validation, auth, per-record ownership) are exactly what these apps are made of.
Content & marketing sites with dynamic bits — a mostly-static site that also needs a contact form, a search, or a members area.
Lightweight SaaS and customer portals — sign-in, per-user data, a few dashboards, billing views. Multi-tenant scoping and authorization are declarative (see Authorization).
Prototypes that might become real — ship something deployable in an afternoon without a build pipeline, then grow it in place instead of throwing it away.
AI-generated apps — see below; this is where What is structurally different, not just simpler.

Built for the AI-agent era

A What app is a directory of .html files plus one what.toml. There is no bundler, no client framework to wire up, no separate API layer, no package graph to resolve. That small, explicit surface is far easier for a coding agent to generate, inspect, and repair than a modern JavaScript stack with components, API routes, a database schema, auth middleware, and client state to keep in sync.

Pair that with the built-in test runner — plain-text .what assertions an agent can write and run as its own feedback loop — and you get apps that an agent can build and verify end to end. See For AI Agents for the machine-readable reference.

Not the right tool

Reach for something else when the app is fundamentally client-first:

Rich offline or real-time-collaborative apps — editors, design tools, anything that keeps a large, authoritative state in the browser. What keeps the server as the source of truth; that's the wrong shape here.
Highly interactive SPAs — complex client-side view state, drag-and-drop canvases, games. You can drop to JavaScript for a widget, but if most of the app is client state, a client framework will serve you better.
Native mobile front-ends needing a pure JSON API — What returns HTML by design. If your primary client is a mobile app, build an API-first backend.

Rule of thumb: if the server can be the source of truth and most screens are "render data, submit a form," What will save you an enormous amount of glue. If the browser must own complex live state, it won't.

Versus the alternatives

The honest short version: less client complexity than React/Next, more batteries included than an htmx-style stack you assemble yourself, and less backend code than Rails/Laravel for this class of app. For a detailed head-to-head (htmx, Astro, Hugo), see the comparisons guide.