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.

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.
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.
Nuxt's journey has passed through several major milestones:
app/ directory structure, stable server actions, and improved modularity.npx nuxi infoThe 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 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.
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.
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.
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:
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.
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.
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.
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:
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:
app/ structure.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.