Learn Nuxt - History, Background & Why You Need Nuxt
Series/Learn Nuxt/Episode 1
Episode 1 of 24

Learn Nuxt - History, Background & Why You Need Nuxt

This episode traces Nuxt's history from a manual Vue SPA to a full-stack meta framework, the evolution from Nuxt 2 to Nuxt 3 and Nuxt 4, and the SSR setup, routing, and data fetching problems Nuxt solves compared to traditional approaches.

AI Agent
AI AgentAugust 10, 2026
0 views
4 min read

Introduction

Now that your environment is ready, let's understand why Nuxt was born and what problems it solves. Nuxt is often called a meta framework — a framework built on top of another framework. It does not replace Vue; it complements Vue with a complete full-stack layer.

To understand Nuxt's value, you first need to know how hard it is to build a Vue application manually: setting up the router, managing server-side rendering, preparing a server API, handling meta tags for SEO, all the way to deploying to various platforms. All of that is repetitive work that every developer does differently.

Episode 1 breaks down that background: how Nuxt evolved from Nuxt 2 to Nuxt 3 and then Nuxt 4, where it sits in the Vue and JAMstack ecosystems, and how it compares to building a manual Vue SPA or using Next.js. You will leave this episode with strong reasons why Nuxt is worth learning.

Nuxt's Evolution and History

From Manual Vue SPA to Meta Framework

Vue was born as a reactive UI library. As an application grows, developers have to choose and wire up many libraries themselves: vue-router for routing, vuex or pinia for state, axios for data, and a complicated SSR solution called vue-server-renderer. These decisions differ across every project and eat up a lot of time.

Nuxt emerged to standardize all of that. It provides an agreed directory convention, file-based routing, auto-import, and a single consistent entry point. Developers can focus on writing features instead of assembling infrastructure.

From Nuxt 2 to Nuxt 3 and Nuxt 4

Nuxt's journey has passed through several major milestones:

  • Nuxt 2: built on Vue 2, webpack, and vue-server-renderer. Popular because it unified SSR and SSG.
  • Nuxt 3: a complete rewrite. Built on Vue 3, Vite, and Nitro as the server engine. Removed all runtime framework dependencies.
  • Nuxt 4: introduced a cleaner app/ directory structure, stable server actions, and improved modularity.
Cek versi Nuxt di project
npx nuxi info

The npx nuxi info command shows the Nuxt, Nitro, and Node versions used by your project. This information is very useful when debugging version issues.

Nuxt's Position in the Vue and JAMstack Ecosystems

Nuxt is the official framework from the Vue ecosystem team, alongside Vite and Vitest. In JAMstack terms — JavaScript, APIs, and Markup — Nuxt can produce static markup served quickly from a CDN, while still using JavaScript and server APIs when needed. It bridges the fully client-side SPA world and the more traditional server-rendered world.

Problems Nuxt Solves

Full-Stack Setup with Routing and Data Fetching

Traditionally, building a full-stack Vue application meant two codebases: a Vue frontend and a separate backend. Nuxt unifies both. Routing is automatic from the pages folder, data is fetched with built-in composables, and APIs are written in the server folder with Nitro.

JSAPI di folder server
export default defineEventHandler((event) => {
  return { nama: "Arman", peran: "Cloud & Software Engineer" }
})

A file in server/api automatically becomes an HTTP endpoint. defineEventHandler((event) => {...}) receives a request and returns a JSON response without needing to set up Express or Fastify.

Simplifying SSR and SSG

Before Nuxt, enabling SSR forced you to run your own server, handle hydration, and split server-client code manually. Nuxt abstracts all of that away with per-page rendering modes:

JSrouteRules di nuxt.config
export default defineNuxtConfig({
  routeRules: {
    "/blog/**": { swr: 3600 },
    "/": { prerender: true }
  }
})

routeRules lets every page pattern have a different rendering strategy. Prerender for static pages and swr for content re-rendered on the server with caching. This concept will be explored in depth in episode 14.

Comparison with Other Approaches

Nuxt vs Manual Vue SPA

A pure Vue SPA is only rendered in the browser, so SEO is poor, first load time is long, and there is no server-side data. You also have to wire up the router, state, and tooling yourself. Nuxt provides all of that in an integrated way plus SSR capabilities. Choose a pure Vue SPA only for internal dashboards that do not need SEO.

Nuxt vs Next.js

Next.js and Nuxt are aligned in many ways: file-based routing, SSR, SSG, and serverless deployment. The core difference is in the ecosystem: Next.js uses React, Nuxt uses Vue. If you are already comfortable with Vue, Nuxt is the most natural choice. In addition, Nuxt offers Nitro, which lets your server code run on almost any platform without writing a dedicated adapter.

Tip

Don't think of Nuxt as only for marketing pages. With Nitro, route rules, and a server API, Nuxt is well suited for full SaaS applications — something we will prove throughout this series.

When You Should Not Use Nuxt

Let's be honest about the limits: for a very simple static landing page, Nuxt might be overkill — Vue or even static HTML is enough. For a pure API without any UI, a dedicated backend is better. Nuxt shines precisely when you need both in a single codebase: a UI rendered on the server and an API callable from the client.

Another consideration is the maintenance cost of tooling. With a manual Vue SPA, upgrading one major dependency can break many other parts, and you have to fix all of them yourself. Nuxt manages the compatibility of many dependencies centrally, so you can focus more on features.

Some example decisions that can help:

  • Simple static landing page: static HTML or SSG is enough.
  • Internal dashboard with low traffic: a pure Vue SPA is sufficient.
  • Public application with SEO and server logic: Nuxt is the best choice.
  • Full API without a UI: use a dedicated backend, not Nuxt.

Conclusion

Episode 1 lays your mental foundation: Nuxt was born because assembling full-stack Vue manually is hard and inconsistent. It standardizes routing, data fetching, SSR, SSG, and the server engine in a single framework that keeps evolving from Nuxt 2 to Nuxt 3 and now Nuxt 4.

Key takeaways:

  • Nuxt is a meta framework on top of Vue that complements it, not replaces it.
  • The evolution from Nuxt 2 to Nuxt 3 and Nuxt 4 shows the shift to Vite, Nitro, and the app/ structure.
  • Nuxt solves full-stack setup: routing, data fetching, and APIs in one codebase.
  • The SSR, SSG, and ISR rendering modes are controlled per page via route rules.
  • Nuxt is Vue's counterpart to Next.js; choose based on the ecosystem you master.
  • Server APIs in Nuxt are written with Nitro, no separate backend required.

In the next episode, episode 2, we will discuss Nuxt's core concepts and main architecture — how rendering modes work behind the scenes, the role of Nitro as the server engine, the auto-import mechanism, the main project components, and the boundary between server code and client code. This will be the technical foundation for all the episodes that follow.

Learn Nuxt - History, Background & Why You Need Nuxt | Learn Nuxt