Most companies hiring a senior Vue engineer in 2026 have a codebase with history: Options API components from 2019, a Vuex store, maybe a Nuxt 2 app still running somewhere. "Have you migrated a large codebase" is a real question, and so is "Options or Composition, and why". The good answer is architectural, not stylistic.

Know

• Same reactivity, different organisation. Options API groups code by kind (data, computed, methods, watch); Composition API groups it by feature and lets you extract a feature into a composable. Both run on the same reactivity system; this.count and count.value are the same Proxy underneath.
• Why Composition wins at scale: logic reuse without mixins (mixins have implicit sources, name collisions and no types), full TypeScript inference without decorators or Vue.extend, better tree-shaking (unused APIs are not bundled), and <script setup> compiles to less code than a component options object.
• Options API is not deprecated in Vue 3, but Nuxt 5 turns Options API support off by default (__VUE_OPTIONS_API__: false), which removes its runtime from the bundle Nuxt 5 . Existing Options components in a Nuxt 5 app need the flag re-enabled or a migration.
• <script setup> macros: defineProps, defineEmits, defineModel, defineExpose, defineSlots, defineOptions, withDefaults. Top-level await makes the component async, which requires a <Suspense> ancestor; Nuxt pages have one.
• Vue 2 → 3 breaking changes worth remembering: createApp instead of new Vue; fragments (multiple roots) and therefore inheritAttrs matters more; v-model on components uses modelValue/update:modelValue and .sync is gone; the emits option; filters removed; $children, $on/$off (the event bus) and Vue.set removed because Proxies track everything; destroyed → unmounted; transition classes v-enter-from; v-if now has priority over v-for; key goes on <template v-for>; async components via defineAsyncComponent; Vuex → Pinia; Vue Router 4's createRouter and guard return values; IE11 dropped.
• Nuxt 3 → 4: app/ becomes the source directory, shared/ appears, useAsyncData/useFetch default data to undefined and are shallow-reactive, request deduplication changed (dedupe), route metadata and component names are normalised, compatibilityVersion: 4 on Nuxt 3.12+ let you opt in early. Nuxt 3 reached end of life on 31 July 2026. A codemod recipe (npx codemod@latest nuxt/4/migration-recipe) handles the mechanical parts.
• Nuxt 4 → 5 (estimated Q4 2026, gated on Nitro 3): server imports from nuxt/server, web-standard Request/Response in Nitro 3 and h3 v2, the Vite Environment API, Options API off, typed pages on by default, case-sensitive routing, callHook no longer awaited. The landscape section has the full list and the readiness plan.
• How a senior runs a migration: measure first (how many components, which patterns), build the safety net (E2E on critical flows, typecheck, hydration-warning test), migrate incrementally behind the same tests (strangler pattern, one route or one feature at a time), use compat builds and codemods for the mechanical work, and keep the business case explicit: end-of-life dates, hiring, performance, security releases.

How it works

The same component in both styles, which is the fastest way to explain the difference:

<script lang="ts">
import { defineComponent } from 'vue'

export default defineComponent({
  props: { userId: { type: String, required: true } },
  emits: ['saved'],
  data: () => ({ name: '', saving: false }),
  computed: {
    canSave(): boolean { return this.name.trim().length > 0 && !this.saving },
  },
  watch: {
    userId: { handler: 'load', immediate: true },
  },
  methods: {
    async load() { this.name = (await $fetch<{ name: string }>(`/api/users/${this.userId}`)).name },
    async save() {
      this.saving = true
      await $fetch(`/api/users/${this.userId}`, { method: 'PATCH', body: { name: this.name } })
      this.saving = false
      this.$emit('saved')
    },
  },
})
</script>

<script setup lang="ts">
const { userId } = defineProps<{ userId: string }>()
const emit = defineEmits<{ saved: [] }>()

// One feature, one block. Extractable into useUserName(userId) verbatim.
const name = ref('')
const saving = ref(false)
const canSave = computed(() => name.value.trim().length > 0 && !saving.value)

watch(() => userId, async (id) => {
  name.value = (await $fetch<{ name: string }>(`/api/users/${id}`)).name
}, { immediate: true })

async function save() {
  saving.value = true
  await $fetch(`/api/users/${userId}`, { method: 'PATCH', body: { name: name.value } })
  saving.value = false
  emit('saved')
}
</script>

A mixin becoming a composable, the migration people actually do most often:

// Before: a mixin adding `page`, `perPage`, `pageCount` and `next()` to any component,
// with no types and a silent collision if the component already had `page`.
export function usePagination(total: MaybeRefOrGetter<number>, perPage = 20) {
  const page = ref(1)
  const pageCount = computed(() => Math.max(1, Math.ceil(toValue(total) / perPage)))
  const next = () => { page.value = Math.min(page.value + 1, pageCount.value) }
  const prev = () => { page.value = Math.max(page.value - 1, 1) }
  return { page, pageCount, next, prev }
}

Exercise

Be able to say