Choosing an Application Mode

Choose between SPA, SSR, SSG, and full-stack delivery — and see why the choice is a boot-file change, not a rewrite.

Example

Create a readable starter, run it unchanged, and make one small production build after the first route works.

npx @askrjs/cli@latest create startkit my-app
cd my-app
npm run dev
npm run build

`createSPA` from `@askrjs/askr/boot` mounts the app client-side against an explicit route registry — no server rendering step, so the first paint happens after JavaScript loads. Use this for internal tools, dashboards, or anything where SEO and first-paint latency aren't primary concerns; it's also the simplest mode to reason about since there's no hydration mismatch to worry about.

SSR

Server-side rendering uses `@askrjs/askr/ssr` — `renderRouteRequest` or `resolveRequest` resolve a URL against your route registry and render to HTML on every request, then `hydrateSPA` takes over in the browser. This is the right choice when pages need fresh data on each load or when you need real SEO with dynamic content; it costs a running Node server and more moving parts than SPA or SSG.

SSG

`createStaticGen()` from `@askrjs/askr/ssg` renders your route table to HTML files ahead of time, writing to an `outputDir` with a `metadata.json` describing the run. It supports incremental regeneration keyed by `changedKeys` or changed route paths, so a CI rebuild only re-renders what actually changed. Routes with `auth` requirements or runtime `policies` are treated as runtime-only and skipped during prerendering — they need SSR instead.

Full stack and startkit

The `full-stack` template pairs SSR-capable pages with backend API routes in the same project, useful when your frontend and API are developed and deployed together. `startkit` is the broader opinionated starter — more conventions and structure pre-wired — and is generally the safest default if you're not certain yet which rendering mode you'll end up needing; you can still layer SSR or SSG entrypoints on afterward.