const projectsShipped = useState<number>( 'projectsShipped', () => 36, )
Stack Innovations
Start a project
Most "isomorphic" Vue sites pick one rendering mode and pay for it
everywhere. Nuxt 3 lets you decide route by route — SSG for
marketing, ISR for content, SWR for catalogues, SSR for dashboards,
Edge for auth. We tune routeRules, wire Nitro for the
right runtime, auto-import the composables, and ship.
Each stat is an SSR-safe Nuxt composable. Hover any to see the useState declaration. Counters scrub with scroll — same primitives we use in production.
const projectsShipped = useState<number>( 'projectsShipped', () => 36, )
const rulesAuthored = useState<number>( 'rulesAuthored', () => 2800, )
const presets = useState<number>( 'presets', () => 9, )
const defaultBuilds = useState<number>( 'defaultBuilds', () => 0, )
Click the panel on the left — the active capability opens in the Nuxt DevTools-feeling editor. Each pane is a working pattern we've shipped.
Same Nuxt project, every route picks the right runtime. Marketing pages prerender at build. Long-tail content uses ISR. Catalogues use SWR. Dashboards SSR. Auth at the edge. Configured in one routeRules block, deployed by Nitro to wherever the runtime fits.
prerender: true · static at buildisr: 3600 · on-demand + revalidateswr: 60 · stale-while-revalidatessr: true · fresh on every requestexperimental.componentIslandsNuxt's auto-imports turn every composables/ file, every components/ file, every utils/ helper, and every Nuxt + Vue + VueUse function into a globally available identifier with full TS types. We tune the import paths, type the composables to spec, and lint against direct manual imports.
composables/ · typed return shapescomponents/ · lazy + island.nuxt/server/api/*.ts — one file is one endpoint. server/middleware/* for cross-cutting concerns. server/routes/* for non-API routes. Built on H3, served by Nitro, deployable to any runtime. We model auth, rate-limiting, validation (Zod), and response caching uniformly.
defineEventHandler · typedreadValidatedBodydefineRateLimitnitroApp.hooks · lifecycleThe Nuxt modules ecosystem is its moat over hand-rolled Vue. We curate a tight stack — image, content, pinia, vueuse, i18n, sitemap, schema-org, security, fonts, OG images — vet them for maintenance, and write our own for what's missing. Modules pin themselves to compatible Nuxt versions.
@nuxt/image · AVIF/WebP/responsive@nuxt/content · Markdown / YAML@pinia/nuxt · SSR-safe state@vueuse/nuxt · auto-imported@nuxtjs/i18n · locale routinguseFetch for HTTP, useAsyncData for arbitrary async, useState for shared SSR-safe state, Pinia for app-wide stores. We pick the right primitive per use case and avoid the hydration footguns that bite naive Vue 3 + SSR setups.
useFetch · key-cached, hydrateduseAsyncData · lazy + transformuseState · SSR-safe refNitro is Nuxt's server engine. The same nuxt build output ships to Node, Vercel, Cloudflare Workers, Netlify, Deno Deploy, Bun, AWS Lambda — preset is a one-line config change. We pick the runtime per project (or per environment) and never get locked in.
nitro.preset: 'vercel-edge'NITRO_PRESETThis is what makes Nuxt 3 itself: every route picks its own render mode. Click a mode pill on each route — the deployment topology on the right rebuilds, build time and average TTFB recompute, and the JSON for routeRules updates live. anime.js spring on toggle, Mo.js burst on deploy.
Same framework, two very different ways it ends up shipping. Eight criteria your team will actually feel — in plain English, with the receipts.
Default config, ships ~400 KB of JavaScript. Mobile devices feel every byte of it.
Lighthouse 100s as a starting line. CI fails the build on any regression.
One render mode for every page. Pay for it on the marketing pages too.
Static for marketing, on-demand for content, server for dashboards, edge for auth.
Editors guess at when stale content clears. Support tickets do the rest.
Cache rules tagged per content type, revalidated on publish, purged on demand.
Bolted on as a follow-up engagement. The "we'll get to it" version of SEO.
Sitemaps, structured data, hreflang, Open Graph images — live on day one.
Switching providers later means rewriting deploy pipelines and parts of the app.
Same code ships to any of them. Switching runtimes is a one-line config change.
You move the content yourself. Links break, search rankings drop, editors hate you.
Source plugin, migration script, redirect map, dry-run, cutover. SEO holds.
"Good luck with the admin." Editors learn by trial and error in production.
Editors leave training feeling fluent. First publish goes through without a Slack ping.
Hand-off, then silence. Six months later you're two majors behind on Nuxt.
Monthly version bumps, perf monitoring, real Slack channel. Features, not tickets.
Nitro is Nuxt's server engine. The same nuxt build output ships to six different runtimes — click any target to "redeploy". The runtime swaps, edge regions update, the cold-start metric changes. No code changes anywhere.
The Nitro engine compiles the same nuxt build source to runtime-native output. No platform-specific code in the app — the only difference between deployments is one environment variable.
Inventory every route. Classify SSG / ISR / SWR / SSR / Edge per route. Lighthouse + TTFB baseline.
Nuxt 3 + TypeScript, modules wired, routeRules drafted, design tokens, Pinia, VueUse.
Pages, layouts, components, composables, server routes, validation (Zod), auth, content collections.
Image pipeline, prefetch tuning, JSON-LD, sitemap, OG images. Per-env Nitro preset, edge regions pinned.
Content migration, redirects mapped. nuxt build against the target preset, deploy, DNS cutover.
Nuxt + module upgrades, routeRules tuning per analytics, perf monitoring, monthly review.