Nuxt at Scale with Daniel Roe

🎧 New Señors @ Scale Episode - Season 2 Premiere

This week, I spoke with Daniel Roe, the leader of the Nuxt Core team at Vercel and one of the most influential figures in the Vue ecosystem.

Daniel's journey is remarkable — he went from running a creative agency and building WordPress sites to becoming the lead maintainer of one of the most powerful JavaScript meta-frameworks. His path from user to contributor to core team leader is a masterclass in open source involvement.

In this episode, we explore the philosophy behind Nuxt's developer experience, rendering strategies for scale, the revolutionary Nitro server engine, and why understanding user pain points shapes every feature decision.

⚙️ Main Takeaways

1. Being your own target audience makes you a better framework developer

Daniel's journey from Nuxt user to core team leader gave him a unique advantage — he understood the real pain points because he experienced them firsthand.

• The approach: Rather than approaching framework development theoretically, approach it pragmatically by solving real problems you face.
• The benefit: You don't need to understand the entire codebase at first. Start from a clue (a bug affecting you) and trace it back like a detective.
• The insight: "I think it's easier if you want to get involved in open source to be your own target audience, because you know what it's like to use it."

2. The biggest gotcha: Re-implementing data fetching incorrectly

The most common mistake Daniel sees is when teams wrap Nuxt's data fetching in custom abstractions without understanding the request context lifecycle.

• The problem: useFetch and useAsyncData are context-aware composables meant to be called in component setup functions. When people create their own abstraction, the fetch can become detached from the request.
• The consequence: Data gets duplicated, requests happen when they shouldn't, and debugging becomes a nightmare.
• The solution: Understand the request lifecycle on the server before creating abstractions around data fetching.

3. Always go for the simplest rendering approach

Daniel's rendering strategy philosophy: start with the simplest option and only add complexity when needed.

• Static first: If you can render something once and reuse it for millions of requests, that's by far the best strategy.
• Pre-rendering extracts payloads: When you pre-render in Nuxt, any data fetching in that page will never be rerun — it uses the data fetched at pre-render time.
• Layer your strategies: You can pre-render marketing pages while dynamically rendering the app dashboard using route rules.
• No JavaScript if possible: For purely static pages, turn off JavaScript entirely for the best performance.

4. SSR is about when you render, not where

Nuxt's definition of SSR might differ from what you expect — it's about rendering HTML versus leaving the browser to do it.

• The clarification: A pre-rendered page is still "SSR" in Nuxt's terms unless you've deliberately turned it off.
• The user experience: Serving HTML that conveys information before JavaScript even processes feels faster to users.
• The benefits: SEO, Core Web Vitals, and perceived performance all improve when you render HTML on the server.

5. Nitro: The server engine that could be bigger than Nuxt

When rewriting Nuxt from v2 to v3, the team extracted shared pieces into separate libraries — Nitro being the most significant.

• The origin: Nitro started as "Nuxt Sigma," then "Nuxt Nitro," before being extracted into its own project.
• The capability: Nitro produces a fully compiled single folder that works anywhere — Cloudflare Workers, Vercel, Docker, Azure, and 30+ other providers.
• The reach: Nitro powers not just Nuxt but also Analog, SolidStart, and TanStack Start. Nitro v3 can run as a Vite plugin.
• The philosophy: Build once, deploy anywhere with zero config to different providers.

6. Bundling goes beyond just JavaScript

Daniel's approach to bundling integrates deeply with framework knowledge to optimize HTML and styles, not just JavaScript.

• Extracting async data: For pre-rendered pages, code that fetches data can be extracted into separate chunks since it won't run at runtime. This reduced JavaScript by 66% on nuxt.com.
• Inlining styles: If components are being rendered, their styles can be inlined in the HTML, eliminating external resource downloads and reducing layout shift.
• The principle: Use the bundler's power in ways that go beyond the normal JavaScript-only boundary.

7. Layers: Nuxt's native solution for micro frontends

Nuxt has a unique approach to code sharing called "layers" — any Nuxt project can be combined with any other Nuxt project.

• How it works: Teams can own projects separately (component libraries, auth, shopping cart) and combine them at deploy time.
• The difference from module federation: Instead of deploying separately, you deploy once with all layers pulled in at build time.
• The benefit: Only components that are used become part of your final bundle. It's opt-in and fully tree-shakeable.
• The future: Native module federation support is also in development for teams that need separate deployments.

8. Modules are Nuxt's killer feature

Modules empower the ecosystem by letting anyone add features without going through the core team.

• The power: There's nothing the Nuxt team can do that you can't also do as a user through modules.
• The inversion: Instead of the framework controlling everything, people can build and distribute whatever they want.
• The community effect: This empowerment is part of why Nuxt has such a great community — contributions come from everyone.

9. Use state sharing is magic (that works differently from React)

Nuxt's useState composable shares state between server and client, but it works differently from React hooks.

• The challenge: Vue doesn't have React's guaranteed hook order, so Nuxt needs a key to match state between server and client.
• The solution: Nuxt generates a key based on filename and position in the file (like "third composable in this file"), then uses that to match payload data.
• The pattern: For bigger apps, Pinia provides DevTools support, time travel debugging, and better state organization.

10. Contributing to open source is about joy and giving

Daniel's philosophy on open source contribution emphasizes doing it because you want to, not because you have to.

• The entry point: Open an issue, comment on someone else's issue, open a PR — there's no gate being kept.
• Beyond PRs: Reviewing other people's PRs, spotting doc issues, or helping on Discord all count as contributions.
• The mindset: "Do it because you want to, because you find it something that you want to do, not because you feel like you have to do it."

🧠 What I Learned

• It's easier to contribute to open source when you're your own target audience — you're solving real problems you face.
• The biggest Nuxt gotcha is re-implementing data fetching without understanding the request context lifecycle.
• Always start with the simplest rendering approach: static > SSR > client-side, adding complexity only when needed.
• Pre-rendered pages in Nuxt extract data at build time, so fetching never reruns at request time.
• Nitro is becoming bigger than Nuxt itself, powering multiple frameworks and working as a Vite plugin.
• Nuxt reduced JavaScript on nuxt.com by 66% by extracting async data code from client bundles.
• Layers are Nuxt's native micro frontend solution — any Nuxt project can extend any other.
• Modules invert framework control — you can do anything the core team can do.
• Nuxt generates keys based on file position to match state between server and client.
• Contributing to open source is about joy, not obligation.

💬 Favorite Quotes

"I think it's easier if you want to get involved in open source to be your own target audience, because you know what it's like to use it."

"A detective doesn't start from a knowledge of everything. They start from just a clue."

"Always go for the simplest approach. If you can render something once and reuse it for thousands, millions of requests, that's better."

"We really, really believe in freedom of choice. I will absolutely draw the line at favoring any provider from a Nuxt point of view."

"There's nothing that we as the Nuxt team can do that you can't also do as a user through the power of modules."

"Contributing to open source is about joy and giving. Do it because you want to, not because you feel like you have to."

🎯 Also in this Episode

• How Daniel went from Laravel and WordPress to becoming Nuxt Core Team leader
• Why Laracasts and Jeffrey Way's teaching style influenced his journey
• The common data fetching mistakes that cause server slowdowns
• Why BFF (Backend for Frontend) patterns are essential for performance
• How Nuxt's route rules enable mixing static and dynamic rendering
• The story behind Nitro's evolution from Nuxt Sigma to standalone project
• How extracting async data code reduced JavaScript by 66% on nuxt.com
• The difference between Nuxt layers and module federation
• Why Nuxt DevTools is one of Daniel's favorite features
• How useState generates keys differently than React's hook order
• What's coming in Nuxt 5 and Nitro 3
• The Vite environment API and what it means for development
• Why Nuxt isn't "part of Vercel" — it's an independent project
• Daniel's open chat policy at roe.dev/chat

Resources

More from Daniel:

• Nuxt Documentation
• Nitro Documentation
• Daniel's Open Chat
• Daniel's GitHub
• UnJS GitHub Organization

Book Recommendations:

• The Culture Map by Erin Meyer — Essential for cross-cultural teams
• The Book of the New Sun by Gene Wolfe — Fantasy with an unreliable narrator
• Murder at Gull's Nest — Detective story featuring a nun

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 54 minutes on Nuxt, Vue meta-frameworks, server-side rendering, and the philosophy of building developer-friendly tools.

If you're building with Vue, evaluating Nuxt for your next project, or curious about how modern frameworks are designed with developer experience at their core, this episode offers invaluable insights from someone shaping the future of Vue development.

Happy building,
Dan