Askr documentation
Getting Started

Overview

What the Askr runtime owns, what your application owns, and which published packages the docs are written against.

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

What Askr owns

The runtime owns reactivity (`state()`, `derive()`, `selector()`), the JSX runtime, app startup (`createIsland`, `createSPA`, `hydrateSPA` from `@askrjs/askr/boot`), routing (`@askrjs/askr/router`), async resource loading with cancellation (`resource()` from `@askrjs/askr/resources`), and the server-side entrypoints for SSR and SSG. It also ships a scoped lifecycle model — `defineScope()` and `readScope()` — for values that need lexical ownership rather than component-local state.

What your application owns

Everything else: your components, your route handlers, your data fetching logic, and how you compose features into pages. Askr doesn't impose a store, a fetch client, or a styling system — `@askrjs/ui` and `@askrjs/themes` are optional packages you opt into for component primitives and theming, not part of the core runtime. Your app decides how state is grouped and where side effects live; the runtime just gives you the primitives to do it deterministically.

Published package baseline

The framework itself is `@askrjs/askr`, with subpath exports for `/boot`, `/router`, `/resources`, `/data`, `/ssr`, `/ssg`, `/components`, and others — each maps to its own declaration entrypoint, so import from the subpath that owns the feature you're using rather than the root barrel. Scaffolding and static builds come from `@askrjs/cli`; component and theme packages (`@askrjs/ui`, `@askrjs/themes`) are separate, versioned independently.