Getting Started

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 starter, start the development server, and verify the production build.

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.