Where to Go Next

Vue's ecosystem has a property worth appreciating before you dive in: the core pieces are official. Router, state management, dev tools, and the meta-framework all ship from the Vue team or its inner orbit, documented in one voice, designed to fit together. Less decision fatigue than some neighborhoods of the frontend world - but the same rule applies: adopt each piece when its pain arrives, not because a list said so.

What you can already build

Phases 1-7 cover components, reactivity, forms, composition, and data fetching - a complete single-view application skillset. Build two or three real things with exactly this before adding tools: a expense tracker, a recipe box, a small dashboard against a public API. The pains you hit (or don't) are the syllabus for everything below.

The map: pain → tool

Two notes on the big ones:

Pinia, sized fairly. A Pinia store is close to something you already know: a composable with hoisted state (phase 5's "refs at module scope" aside, formalized). If provide/inject plus a composable is holding up fine, you're not behind - Pinia earns its place when shared state grows update logic, needs DevTools history, or is touched from many corners.

Nuxt, sized fairly. Nuxt is to Vue what Next is to React: rendering on a server for SEO and first paint, file-based routing, and a data-fetching layer - plus more convention (auto-imports, directory structure) than base Vue. The reasoning in our Next.js guide's opening phase - what a SPA costs you and when a server fixes it - transfers to Nuxt nearly word for word. Same decision, Vue vocabulary.

Options API code in the wild

You will inherit components written in the older dialect - data(), methods:, computed: as object sections, this.count everywhere. Translation is mechanical once you know both sides: data fields are refs, methods are functions, computed: entries are computed(), lifecycle options (mounted()) are the on* hooks, and this.x becomes the direct reference. No rewrite crusades required - the two dialects interoperate component-by-component, and understanding old code is cheaper than churning it.

Additional resources

• vuejs.org - the official docs, among the best-written in frontend; the tutorial track mirrors this guide's arc with runnable examples.
• pinia.vuejs.org - short, worth reading even before you need a store, for its state-design opinions.
• VueUse - browse it once to calibrate what composables can be; read a few sources - they're compact masterclasses in phase 5's pattern.

Recap

1. Router, Pinia, Nuxt: official, documented together, adopted separately - each on its own pain.
2. Pinia ≈ composables with formal shared state; skip until sharing hurts.
3. Nuxt is the Vue answer to the SPA costs our Next guide's phase 1 lays out - same trade, same reasoning.
4. Options API is legacy dialect, not legacy framework: read it fluently, migrate opportunistically.

[
  {
    "q": "An app's theme, current user, and a 40-line cart with add/remove/discount logic are all shared via provide/inject. Which piece most clearly wants a Pinia store?",
    "choices": [
      "The theme - it's read everywhere",
      "The cart - shared state with real update logic and history worth inspecting",
      "The current user - it's the most sensitive data",
      "All three equally"
    ],
    "answer": 1,
    "why": [
      "Widely-read, rarely-changed, no logic: the provide/inject sweet spot - moving it buys nothing.",
      null,
      "Sensitivity is an auth concern, not a state-tool concern - a store adds no security.",
      "Theme and user are fine where they are; migrating them is churn without payoff."
    ],
    "explain": "Stores earn their keep where shared state meets update logic - actions, DevTools history, many writers. Simple broadcast context stays happily in provide/inject."
  },
  {
    "q": "When does moving from Vue+Vite to Nuxt become the right call?",
    "choices": [
      "Once an app exceeds roughly twenty components",
      "When you need what a server adds: SEO-ready HTML, fast first paint, server-side data access",
      "Nuxt is the current default; new Vue projects should start there",
      "When you want to use composables"
    ],
    "answer": 1,
    "why": [
      "Component count measures size, not architecture - a 200-component dashboard behind a login is still a fine SPA.",
      null,
      "For public content sites that's arguable - but as a blanket rule it ignores the SPA cases where a server buys nothing.",
      "Composables are core Vue - available everywhere, framework or not."
    ],
    "explain": "Nuxt is the server-in-front decision, Vue edition: adopt it for the SPA costs it eliminates (blank first paint, crawler-invisible content, exposed data layer), not as a default."
  }
]

← Phase 7: When Vue Breaks · Guide overview