Nuxt & Vue for the React Developer

I've spent my frontend career in the React world — React, Next.js, TypeScript, TanStack Query, Zustand, the whole ecosystem. Recently I started migrating my projects to Vue and Nuxt, and I'm learning it the way most React developers do: constantly asking "okay, but what's the Vue equivalent of X?"

If you know React, Next.js, and TypeScript, you already know about 80% of Vue and Nuxt — you just know it by different names. This post is the dictionary.

First, the ecosystem map. Almost every tool you use in the React world has a first-class counterpart in the Vue world — and notably, most of the Vue counterparts are official, maintained by the core team, rather than community picks:

The deeper difference isn't the tools — it's the philosophy. Two things separate these stacks at the core:

1. Re-render vs. fine-grained reactivity. React's model: state changed, so re-run the whole component function and diff the output. Your function body executes on every render — which is why you need useMemo, useCallback, and React.memo to opt out of work. Vue's model: your component's setup code runs once. Vue wraps your state in proxies, tracks exactly which piece of the DOM depends on which piece of state, and surgically updates only that. Optimization is the default, not something you add.

2. Library vs. framework, à la carte vs. batteries-included. React ships a rendering library and lets the community fight over everything else. Vue ships the router, the state manager, and the docs to glue them. Nuxt goes further than Next — auto-imports, built-in data fetching with SSR-aware caching, a server engine (Nitro) that deploys anywhere, and an official module ecosystem for images, fonts, SEO, auth, and content.

Everything below teaches Vue/Nuxt by mapping it onto what you already know. Each topic shows the React version first, then the Vue version, then the gotchas. Work through it in order — the concepts build on each other.

In React, a component is a function that returns JSX. In Vue, a component is a .vue file with three blocks: <script setup> (your logic), <template> (your markup), and optional <style>. Same component, both worlds:

Things to notice, because they generalize:

This is the heart of Vue, so let's be precise. Vue gives you two primitives:

import { ref, reactive } from "vue";

// ref: for ANY value (primitives included).
// Access/write via .value in script code.
const count = ref(0);
count.value++;              // write
console.log(count.value);   // read

// reactive: for objects only. No .value — but you
// lose reactivity if you destructure or reassign it.
const state = reactive({ name: "Daksh", score: 9 });
state.score = 10;           // just mutate

Why does ref need .value? JavaScript proxies can only intercept property access on objects — you can't proxy a bare number. So Vue boxes your value in an object with a .value property it can watch. In templates, refs are auto-unwrapped — you write {{ count }}, never {{ count.value }}.

Now the derived-state and side-effect mappings:

Read that again, because it's the single biggest quality-of-life difference: there are no dependency arrays in Vue.No exhaustive-deps lint rule, no stale closures, no "why is my effect firing twice." Vue records which reactive values a computed/watchEffect actually reads, and subscribes to exactly those. The entire class of bugs where you forgot a dependency — gone.

Props flow down in both frameworks. The difference is the upward direction: React passes callbacks down; Vue components emit events up. Fully typed, both directions:

<SearchBox
  placeholder="Search blogs..."
  @search="(q) => runSearch(q)"
/>

Three template mechanics worth pausing on:

:placeholder — the colon binds an attribute to a JS expression (shorthand for v-bind:). Without the colon it's a literal string, like HTML.

v-model — two-way binding. In React, every input is a controlled-component ceremony: value={query} onChange={(e) => setQuery(e.target.value)}. In Vue, v-model="query" does both. It also works on custom components — defineModel() gives you a two-way-bound prop in one line.

@keyup.enter — event modifiers. .enter, .prevent (preventDefault), .stop (stopPropagation), .once. The e.preventDefault(); if (e.key === "Enter") boilerplate is just... gone.

This is the part React developers resist most, so let me map it directly. JSX uses JavaScript for control flow; Vue templates use directives:

Two honest notes. First: yes, you're learning a DSL, and for the first week you'll miss "it's just JavaScript." Second: the DSL is whyVue can optimize so well — because templates are statically analyzable, the compiler pre-computes which parts of the DOM can ever change and skips the rest entirely. JSX's full flexibility is precisely what React's compiler struggles against. And if you truly need dynamic render logic, Vue supports JSX and render functions too — it's just rarely needed.

React's children prop is Vue's default slot. React's "multiple children sections" pattern (passing JSX via props) is named slots. Render props are scoped slots:

Same power as render props, but declarative and with less nesting. This pattern is everywhere in Vue UI libraries, so it's worth internalizing early.

Lifecycle first — the mapping is nearly one-to-one:

Custom hooks become composables — same idea (a function using reactive primitives, returning reactive state), one huge difference: the Rules of Hooks don't exist. Because setup runs once and reactivity lives in the values (not in call order), you can call composables conditionally, in loops, wherever:

Pinia is Vue's official store, and if you've used Zustand it will feel like coming home — minus the selector functions, because Vue's reactivity makes components auto-subscribe to exactly the fields they read:

Notice the store is literally a composable — the same ref/computed primitives you just learned, registered globally. No actions/reducers split, no immer, no useSelector memoization. Pinia also has devtools with time travel and full TypeScript inference out of the box.

Now the meta-framework layer. Nuxt is to Vue what Next is to React, and the mapping is direct:

The two ideas that genuinely differ and deserve explanation:

1. Data fetching: useFetch. Next App Router splits your world into server components (fetch directly) and client components (TanStack Query et al). Nuxt has one primitive that does both jobs:

It's SSR-aware, deduplicated, cached by key, typed end-to-end (the return type of your server/api handler flows into data automatically), with refresh(), lazy variants, and reactive keys — refetch when the route param changes, no dependency array.

2. The server side: Nitro. Nuxt's server engine is a standalone thing. Any file in server/api/ becomes an endpoint:

export default defineEventHandler(async (event) => {
  const slug = getRouterParam(event, "slug");
  const post = await db.post.findUnique({ where: { slug } });
  if (!post) throw createError({ statusCode: 404 });
  return post; // type flows into useFetch on the client
});

And auto-imports, the most controversial Nuxt feature: components in components/, composables in composables/, and all of Vue's primitives (ref, computed, watch) are available without import statements. Feels wrong for a day, then you stop missing the 15-line import blocks at the top of every Next page. It's fully typed — TypeScript knows exactly what's in scope.

Everything that actually bit me, so it doesn't bite you:

If you know React and Next, you are two honest weekends away from productive Vue and Nuxt. The component model, one-way data flow, file-based routing, SSR mental model — it all transfers. What changes is the cost structure: Vue's fine-grained reactivity means the performance work React makes you do by hand (memoization, dependency arrays, selector tuning) simply doesn't exist, and Nuxt's conventions mean the stack decisions Next leaves to you (data fetching, state, imports) come pre-made and official.

Learn ref and .value, embrace mutation, let go of dependency arrays, and read your compiler errors — the rest is renaming things you already know.

• ↗Composition API FAQVue.js docs — the why behind the reactivity model
• ↗Nuxt Documentationnuxt.com — start with Getting Started, then Data Fetching
• ↗Pinia Core Conceptspinia.vuejs.org — setup stores, the composable way