The Future of Nuxt: Sébastien Chopin on Nuxt 4, Vercel & Next.js

In 2016, Sébastien Chopin gave himself a week-long challenge: build a Vue.js equivalent to Next.js. That prototype became Nuxt, one of the most popular frameworks in the Vue ecosystem. 

In this conversation with Monterail's Jakub Andrzejewski and Szymon Licau, Chopin reflects on that journey from his early days as a 12-year-old PHP developer to the recent acquisition of NuxtLabs by Vercel.

The discussion covers the technical decisions that shaped Nuxt, including how file-based routing and the .nuxt directory came to be, and why the nuxt generate command appeared just a week after the initial release. Chopin also explains Nitro's evolution into a standalone server engine, what "full-stack Nuxt" means in practice with tools like Nuxt DB and storage modules, and his long-term vision for a "Nuxt Assistant" that could help developers build applications through an embedded AI interface.

On the Vercel acquisition, Chopin addresses the questions many in the community have been asking: what changes, what stays the same, and how Nuxt will remain open, community-driven, and host-agnostic.

You can watch the full interview on Monterail’s YouTube channel, or keep reading for the full transcript.

Sébastien’s background and roots of Nuxt

Sébastien: Hey everyone, thank you for having me. I'm excited to be here and tell some stuff that maybe I haven't shared before. So, I'm Sébastien Chopin. I've been a web developer since I was 12 years old. I started with PHP and stopped around 19 when I discovered Node.js. Then I fell in love with JavaScript.

I was doing some JavaScript with PHP back then when I wanted to do Ajax scroll loading. I was a big fan of avoiding page reloads, and I think that ultimately led me to building Nuxt because I still hate seeing a page being reloaded. Even though I like the work from other frameworks, it drives me crazy.

Having server-side rendering and search engine optimization has been something that was very important to me when I was working on an e-commerce website. Being able to merge this SPA experience and server-side rendering for SEO was just a relief.

It happened in 2016 when I was working on an e-commerce website with Node.js and Vue.js 2 with server-side rendering, and it was working very well. I had to manage a Webpack configuration, which was actually very hard to do honestly. And I saw the announcement by Vercel about Next.js in October 2016. I was following Guillermo Rauch for his work on socket.io and Mongoose. I had a blog called atinux.fr back then where I was writing French articles—they're not there anymore—about Node.js, MongoDB, Elasticsearch, all this stack that was not popular in Europe back then. I liked to talk about socket.io and others.

So naturally I discovered Next.js and I just clicked with this history of PHP pages system, SPAs I was doing with Backbone.js before, then Vue, server-side rendering, e-commerce. I was like, "Yeah, let's do the same for the Vue community." And naturally, Vue, the "U," Next led me to "Nuxt," and it was available on npm and GitHub.

So I gave myself this challenge and a week later I had a first prototype working. Then people from the Vue community noticed it and started talking about it. And yeah, here we are today, nine years later talking about it. I was not expecting this and I'm happy about how it turned out.

First Nuxt prototype and file-based routing

What was Nuxt back then? What was included in that first version you considered ready for testing or early adoption, and what did you have in mind to build upon later?

Sébastien: I think you can find the commits—I think it was a week later, so end of October. My main goal was to have a CLI. It was good because I was inspired by Next.js, so the spec was simple: you need a command to run the dev server. Back then it was only the nuxt command, and you needed to have pages.

Luckily in the Vue community, we had Vue and Vue Router. So all I had to do was kind of read the file system. Since I had a background with Node.js, I was familiar with the Node.js API. I was reading the file system, and where it was tricky compared to Next.js—I read the source of Next and went in the opposite direction as them. For them, they had their own routing system.

I found the solution during the night: what if we read the file system, your directory structure, and we generate the final file that will be used and imported by the app? That's how we created this .nuxt directory. If you have a Nuxt project, I highly recommend you check out the .nuxt directory. You will find all the final files of your application. I was generating this .nuxt/router.js which was basically the Vue Router file generated.

So yeah—pages directory, no dynamic routes, index.vue, about.vue, server-side rendering, no Webpack config, just CLI. That was the first prototype where I was confident enough to share publicly.

Early community feedback & birth of nuxt generate

Do you remember the initial feedback you got from the community? Was it positive or did people feel it needed more polishing?

Sébastien: It was actually positive because the Vue community is so kind. I was so happy to get the first issue because that meant someone actually tested it. I think it was an idea, but I can't remember—I would need to check it out. But it was pretty positive and that's actually what kept us motivated in doing this project.

I remember my brother Alexandre Chopin was working on a static site generator. He was working with Hexo and for him, he was into static sites, checking websites, and he was like, "Oh, but could you also do this?" And I was like, "Yeah, I think it's going to be very easy. We have server-side rendering, so we kind of need to have a step where we run the server, call the page, take the HTML and save it as an HTML page."

And nuxt generate was born I think a week later. I remember we were at the Vue.js Paris meetup—I think it was the end of 2016. Evan You was there because he had a talk at the meetup, and he was at the front row. We presented Nuxt and then the nuxt generate command and he was like, "Interesting." And I think a few months later we had this VuePress documentation generator for static pages.

So I think we were definitely the first one being a static site generator based on the Vue file or component. I'm quite happy to have landed this feature early.

Static site generators & hybrid rendering

It's interesting that at some point there was a lot of movement around static site generators that were only static site generators—like Gatsby, or GridSome in Vue. But now both Next.js and Nuxt do it for you because they utilize server-side rendering. You somehow predicted the future of what would be popular from the beginning.

Sébastien: Yeah, GridSome. I kind of liked it, but for me, having the ability to have a server running was always going to be more powerful while still having the ability to serve static files. That's why I'm very excited about this hybrid rendering—being able to serve static if it's needed, but also being able to know that you may want to regenerate the page and always serve static files. But yeah, there were also great frameworks and we inspired each other.

Nuxt 4, Nuxt 5, and the future of the core

Moving towards current times and keeping in mind the recent Nuxt 4 release, what can we expect from Nuxt 4 going forward? Nuxt 4 wasn't such a big bang giant leap—it was more gradual. What can we expect now for Nuxt 5 and the future?

Sébastien: That's a good question and I'm quite happy that Nuxt 4 was not a big bang because Nuxt 2 to Nuxt 3 was painful. We want to have a major version that you want to upgrade and have a good feeling of upgrading.

We have many ideas and what I love the most about Nuxt is that we can work with these plugins we call modules—the ecosystem. The way we defined Nuxt core within Nuxt 2 and then Nuxt 3, a module can replace functionalities of Nuxt itself. So we can morph Nuxt into the framework we want based on modules.

It depends because we're a core team and we all have different projects, and even you, Jakub, have a module. We're experimenting through modules and based on the popularity of them and the usage, we're thinking of making them a core module or directly part of the framework by default.

On my side, I'm working on the full-stack part of Nuxt. As I told you, I used to do a lot of Node.js, MongoDB, database work. I want to push this far. I don't want it to be like Laravel because Laravel is for PHP. I love the way they do stuff, but I don't feel it's that natural, at least on the Nuxt side.

Full-stack vision: Nuxt DB, storage & AI modules

Sébastien: Right now I've been working on NuxtHub which was allowing you to create full-stack applications on Cloudflare. Since the acquisition with Vercel, my goal is to make the Nuxt modules agnostic so you can have a database working outside of Cloudflare, same for the blob storage, etc. 

And the last weeks I've been working on extracting the database part that is going to be Nuxt DB. Same thing—it will be a module that you can use with almost zero configuration. You just choose your dialect. We're integrating the migration through Drizzle Kit, but you have a CLI: nuxt db migrate, nuxt db generate, and we run the migration before pushing to production, same in development. Very exciting—I cannot wait to finish the documentation and announce it.

It will be the same for the blob part, probably Nuxt Drive. We're still thinking about the naming. So giving this full-stack part as plugins to see how people can use them.

On the side, we have Nuxt Hints that was released today if I'm not mistaken, or yesterday—I was off yesterday, it was a holiday in France. That helps you have better performance. So we're testing and seeing what's best by keeping Nuxt core light and giving these extensions for you to try out.

And of course, AI—I need to say the word many times now because we're in the AI phase. We have this LLM modules that allows you, if you have documentation or a website, to create these llms.txt files. We have a Nuxt MCP module in the works. We're thinking of having this agent system, but we're going step by step with testing it internally within apps and trying to give, on the Nuxt directory structure, the Nuxt way of building full-stack apps and AI apps. This is definitely where we're working on, but the community is also working on stuff, so it's impossible to predict. But it will stay relevant for most developers because we're building it together.

Nitro: why it exists & how it changes full-stack dev

I completely agree. I'm glad you mentioned Nuxt Hints because I also participated in part of its development. It's built with the community—not only the core team, not only NuxtLabs, but all of us contributing in one way or another. You mentioned full-stack development, and this probably wouldn't be possible without Nitro, which we don't always mention but Nuxt uses under the hood. Nitro was introduced with Nuxt 3. How in your opinion does Nitro change full-stack development, not only for Nuxt but also for other frameworks?

Sébastien: Yeah. We started Nitro a long time ago. Nitro had so many names. At one point it was called Sigma Workstation. It started with a pain point—it always starts with a pain point.

The pain point was when you had a Nuxt 2 application and you wanted to create API routes, you had to restart the whole Nuxt server. Meaning the server is fine, but the build of Webpack for the client and the server part of the app—wow, I mean you don't want to create API routes with Nuxt 2.

So we started working on something called Workstation with Pooya Parsa. We were able to have a different worker just for your server code, for your API routes. It's tricky when you say Nuxt because you have an app, a Vue app, which also works on the server. So there is a server part of your app, but there is also the whole server being capable of having your API routes and then serving your Vue app.

So we wanted to have this distinction where your API routes could be hot module reloaded without having to restart the whole Webpack system. We worked on this Workstation project on Nuxt 2. We almost had it working, but then we started working on Nuxt 3.

I also gave the challenge to Pooya: "Okay, I want Nuxt to be able to work within Cloudflare Workers." And that was a big challenge because it had to be—I think back then it was almost one megabyte, the size of the app. So this means, okay, now on top of having a server being able to have hot module reload on the server, we also need to bundle the app plus your server—the whole Node module tracing. So the final output is like a binary. It's a minimum output directory that can be deployed in several platforms.

Nuxt 2 was not supporting the serverless platform that well because every time you started the server, we were loading the bundle of your application. Sometimes if you only need to call an API route, you don't want to load the bundle of your app just to serve an API route, mostly on serverless where you restart every time. So Nitro was also bringing code splitting at the server level. Every API route is code-splitted, so it only loads the required JavaScript to serve a route. And then when it serves your app, the app also has code splitting. So it's like performance bundling for the serverless and edge, and hot module reload on the server.

So it's a big project. We had it as part of Nuxt, and as our team loves to give to the community and to other frameworks—I think we're starting to be known for this with the different projects. UnJS is also a nice project of all the small utilities we had in Nuxt. We extracted them, made them a library that can be used elsewhere.

And then we have Nitro that we decided to also use as a standalone project, but serving Nuxt at first because that's where it was created. And now it became an amazing project that's used by other web frameworks. So we're collaborating all together on this.

It now can be used as a Vite plugin with Nitro v3. So if you have a Vite app and you want to start adding SSR, you want to have API routes, you can add the Nitro Vite plugin and you're good to go. So yeah, it's another new framework we have and it serves different purposes. It's very exciting and we benefit from it as well at Nuxt.

It's led by Pooya, who was the creator of Nuxt 3 at that party. We worked crazy on this and now it's led by Daniel Roe who is doing an amazing job. So I'm lucky to have found these amazing people and amazing community like you guys. So I hope I answered for Nitro.

Extracting Nuxt tools for the wider ecosystem

It’s also amazing that as a part of developing something that solves one problem, you haven't just said, "Oh, we have solved this problem. This is our product. It's under our license and if you want to have the same you have to copy it and build it yourself." You decided to extract those smaller—sometimes bigger—parts like Nitro, but there are also some much smaller packages for configuration, for merging objects, for hooks, or for other things that you can just use in basically any kind of framework. UnJS is a good example.

Sébastien: Exactly. Because we worked on Nuxt 3, we had to support Vite and Webpack. So we had to put a generic way of creating Vite and Webpack plugins. Just a small note—sometimes it's great. I mean, we gave a lot to the community and everyone being able to use these libraries. Sometimes it was also difficult for us because someone had a great idea for a library we use and we didn't notice that they actually created a bug because we didn't use it in the way we didn't expect that library to do this. Sometimes it was slowing us down, but I think in the long term it was for the best to give all of these tools to everyone.

Vercel acquisition: why join forces

Let's move on to the Vercel acquisition, which was quite an announcement a few months ago—a very hot topic. People who are not from the Vue or Nuxt community often say, "Oh, I heard that Vercel bought Nuxt. What?" So can you share some light on it? We've seen too many people misunderstanding it. What actually happened? What does it mean for the framework? And what made you think that this partnership would work? What made you think it's a good direction for the company and Nuxt in general?

Sébastien: That's a lot of questions, but good questions I need to answer. It actually came from an idea of joining forces with them. Guillermo Rauch contacted me and said, "Hey, would you be interested?" And I took weeks to think about this possibility—what it would mean to the community, what would be my terms and our terms as a team within NuxtLabs to make sure that we don't want to denature Nuxt. We want a way to reassure the community and reassure ourselves about the vision.

We've seen things about Vercel and Next.js. As I was running NuxtLabs, it's very tricky because you want to do open source, you love open source—that's what makes me motivated every day—but you also need to pay the people to work on open source. So there is this balance to find.

We didn't want to call the company Nuxt. At one point we renamed it to NuxtLabs and we tried to create products that are not required for you to make an amazing website but save you time. It's not easy to be sustainable when you need to pay developers because developers are quite expensive, and amazing developers are quite expensive as well. And developers are not the ones that are willing to pay the most for products. So how can you do it when you do developer tools? You need to pay developers that are expensive, but they don't want to pay. Developers don't want to pay for open source. So we need to find the right balance for this.

I was quite happy about the products we had at NuxtLabs. We had revenues, we were almost profitable, but at one point it was hard to focus on one thing, which was at the end the framework. I don't want to split into too many projects.

We were discussing with Guillermo. I've seen back then SvelteKit, how they evolved, how they stayed agnostic. And I think this, on top of honestly admiring Vercel's vision on tech—like I said, I was following socket.io, Mongoose, their developer experience, and even Next.js. I don't care about the last version of Next.js, the App Router—I don't use it—but the developer experience, their marketing, their design, it's top-notch. And I was like, I think it will also help us become better in terms of marketing, documentation, because it's about explaining well your project and understanding.

So collaborating with these people could be nice. And AI—I need to talk about AI also. v0 is an amazing product and I think we wanted—I want at a certain level to start going deeper into the AI landscape, either for code generation or for code understanding, like AI understanding Nuxt. So being able to be in touch with teams working on AI often would definitely level up our gain in the AI landscape.

So we started chatting and I was like, okay, let's see what would be the benefits and drawbacks. And I was actually convinced and the team were convinced as well about their open web vision—the fact that they want to put Vercel in a way that it's an agnostic hosting platform and not only the Next.js platform. And it fits into this vision. We wanted to keep our autonomy and being able to keep our roadmap a community-based framework. And I think SvelteKit is a great example. I had the chance to talk with Rich Harris beforehand and at the end we all decided let's go on this adventure. And Vercel is well known for all these open source projects and so far I'm very happy about this choice.

What changes (and doesn't) for Nuxt developers

That makes sense. Most developers have a more solid grasp now about everything that happened and everything that also didn't happen. But people will be looking with more scrutiny and trying to gauge the decisions and understand them better. So maybe with a few quick words from you, what should or will change for Nuxt developers and what won't change for Nuxt developers going forward?

Sébastien: Nothing would change for them, honestly. And I think we proved it the last three months. Vercel doesn't want us to change anything. What they want is to be able to have our knowledge of developer experience to be applied also on their platform.

We've been chatting with them on the runtime cache feature and they were thinking about what could be the best approach for framework authors to use this runtime cache. Then we talk with the different framework authors and saying, "Oh, this I like, this I don't like," and then they go back to work and ask us, "What do you think about this?" It's this proximity for them that helps them create the best platform. Then it's your choice to decide if this is the best platform or not.

What you can expect is, of course, as we are collaborating with them and helping them have a great platform—and I always used Vercel since even before I created Nuxt, as I was following Zeit—so I really like that platform. We want to make sure that Nuxt on Vercel is a great platform to host Nuxt apps. So this leads to improvements like the Workflow package. So if you use Vercel, you're going to be happier because the things we didn't support, we are supporting them or we're going to support them very soon. So you're going to enjoy it.

If you're not using Vercel, nothing will change for you. And if you are using Cloudflare, it's the same. Just the nuxt-cloudflare package will keep working, but you will be able to deploy on different providers. So we stay agnostic and we will include the deployment experience on Vercel.

Relationship between Nuxt & Next going forward

How do you see the relationship right now between Nuxt and Next.js? Does it mean that the frameworks will use best practices from each other? Do you see, for example, Next.js using certain features from Nuxt?

Sébastien: Yeah, I'm considering adding the App Router to Nuxt. I'm kidding.

I don't know about this, but no, I think we have a lot of work on our plates. What we do is mostly discuss about their process, maybe their best practices—how do they document their work, what are their processes, maybe on the design part, how can they gather feedback from enterprise, something we were potentially lacking at that high level.

Because I think feature-wise, we used to inspire each other a lot, but now we are at a stage where on the full-stack side it's different. We plan to have this RPC server functions, but we can read documentation and we can invent features on our own.

What we can collaborate more on could be on the Nitro part because maybe one day we can have Vercel and Next.js using Nitro, but this will take a while. But it might be more on lower-level packages, like how can we share common packages between us—might be at that level. I think on the feature side, it's very oriented Vue and React so far.

But who knows? I would love to have Nuxt Content being able to work on Next.js as well, as well as Nuxt Studio, Nuxt DB. It would be quite awesome to import Nuxt DB in a Next.js project. But that's of course not the top priority for me. Nuxt users, Nitro users—we see they have already great solutions on their own. So the Vue community is something that I have in my heart only for a while.

Maybe a small comment because I think this is very important to realize, especially for people who are skeptical or afraid of what happened with this Vercel acquisition. This is also probably the biggest chance to have more direct collaboration or planning, or especially maybe even shaping the way we work with the web going forwards. Because basically, while everyone knows it and just as you also have said, Sébastien, the frameworks have been inspiring one another—we already did that, that's how open source goes—but there wasn't direct collaboration, not like the teams sitting at one table maybe approaching a certain new feature or a specification for the web. So I think that there is a big opportunity here.

Sébastien: I agree. And there is room for collaboration and we will save us a lot of time. It can be frustrating like, "Oh, I don't have enough time right now, I have thousands of issues." But if you take just one or two meetings to sit down, at the end we will save time in the future because we'll be collaborating on one library that we can reuse. And it's been only three months we're there, but I'm confident that in the next year we'll be able to start having shared libraries.

Nuxt in Vercel's broader AI & backend strategy

So one last question from my side about the Vercel part. How do you envision Nuxt's place in the overall Vercel strategy? Because Vercel is not only about Next.js, it's not only about hosting, it's also about v0. So how do you envision Nuxt in the broader strategy of Vercel?

Sébastien: I'm working on the framework team at Vercel, so I'm not directly related to the products. But of course, as I was also running a business, I'm interested in this. And I like the shift to the AI cloud, which means that they want to support more backend frameworks, and we can see this with the latest announcements.

I'm also excited by the Workflow support because that's one of the most painful things when you need to do backends. We used to have a product named Volta where we had to deal with webhooks, GitHub webhooks, and then you need to have a queue system and, oh god, you need to retry. They found a nice way to make it simple but still kind of bulletproof and in a way that it can be also self-hosted, which I also like their direction.

For me, as long as it saves me time—because the race of AI, building apps that you throw away and you create another one, it's going to be more and more. So I like the way they frame this.

So talking about AI cloud, more backend frameworks—I want AI to be able to ship Nuxt apps. But for this, I want AI to be able to ship full-stack apps and being able to give this option for AI to build full-stack applications that can be deployed on Vercel or other providers. But for me, if I have a one-click deploy that supports database, workflow, AI gateway—and I have to say that I'm very excited by the AI gateway they built because you can add AI easily to your app—yeah, that's quite exciting.

I still don't have many ideas about what AI apps I can build so far, but at least giving people the ability to create their next AI app idea with Nuxt is what excites me the most.

Long-term dream: "Nuxt Assistant" & AI-built apps

About the future of Nuxt, we've already talked about it a bit in terms of the Vercel stuff, Nuxt 4, Nitro. But if you could name one thing that you are excited the most about that could come to Nuxt in, let's say, two or three years from now—not something that you work on today and will be released tomorrow, but something in the long run that we as a community can wait for and anticipate.

Sébastien: What I would love to see is an assistant.

So a way where you have, and you should be able to start locally with local AI models. So you should be able to select a model that could run locally or in the cloud using the AI gateway for instance, or OpenRouter or any others. And then you have, similar to what you can have with Cursor, but an assistant to help you build the app.

But I wish to have kind of a chat interface from day one, like the Nuxt welcome app we have. But then you have a prompt and you can start talking to it. You move it to the left or to the right like Nuxt Studio. So it's a web component and you can chat and morph your application. This will be possible once we have a full-stack framework with a CMS, database, and then it creates you the website. It's more like an embedded v0 or Cursor.

I don't know if it's a good or bad idea, but "Nuxt Assistant" being able to tell you, "You have these hints," but suggesting you one-click to update if not doing it for you, respecting best practices. So we make sure to have the best, most performant websites.

But yeah, I don't know yet how to properly train AI. We try to do RAG, but I know things. I'm staying open to see this, and once it will click in my brain, that might be the time to do this. But yeah, Nuxt Assistant. But I want you to enjoy coding before it's gone.

Actually I planned to ask you more about AI and the future of Nuxt, but it seems like I don't really need to. You are already kind of guiding it towards that way. But also on the note of this Nuxt Assistant idea, I can already picture modules being able to expose themselves to that. So it's all beautiful and painless to make it work together, but of course someone has to first make it.

Sébastien: Yeah, Atinux is working on an MCP module. I'm working on a DB module that is extendable with modules. So you can have a Nuxt CMS module that is using the Nuxt DB, or a Nuxt Auth module that is using the Nuxt DB to create its database tables. You can have the Nuxt MCP module that creates tools to communicate with your authentication layer. So you can list your users, and then you just have this interface.

We have Nuxt UI, which actually no other frontend frameworks have—the UI library. So we are adding more AI tools. We also have the editor coming. Yeah, we're going into this direction.

Like when I was doing e-commerce websites with Node.js SPAs, I loved doing this. Who knows? In three years maybe we'll be like, "Yes, of course you were working on this. It was made for this vision." But I don't know this vision yet, but probably it will make sense in a few years.

Yeah, a few years from now it will all look like a very detailed, planned action.

Sébastien: It was my master plan. Yeah, it was all planned.

Yeah, but at the end it's community feedback. It gives you an idea. It clicks with your personal history. Create a new idea. We will build it together.

Message to the Vue & Nuxt community

Is there anything you would like to share with the Vue and the Nuxt community before we wrap up?

Sébastien: Thank you. Thank you for the time, all the energy, for being there since the beginning—for a few years, just a few weeks maybe. Keep pushing, keep using, keep giving us feedback. Keep building.

It means a lot to me that these projects exist and having such a big community. I do think Vue will get more hype soon. But maybe that will be other news I will share later.

Where to find Sébastien online?

How can the listeners find you if they want to? Should it be X? Should it be Discord or LinkedIn or anything else?

Sébastien: They can find me on X, on Bluesky, on YouTube even though I don't post that many videos, on Discord, and it's always with @atinux. I also have atinux.com which has all the links. Also atinux.com has my email, but feel free to send me a message on X—I think my DMs are open—so happy to chat.