Working on Nuxt Full-Time: Daniel Roe on Open Source, AI, Vue & Web Development

Some people who lead major open-source frameworks may have a tidy origin story. Computer science degree, big tech job, framework born out of necessity, and so on. 

Daniel Roe's path to becoming Nuxt Core Team Lead looked nothing like that. He ran a communications agency. He started with WordPress. He picked up Vue because Taylor Otwell tweeted about it.

In this episode of Monte Talks, Jakub Andrzejewski and Szymon Licau from Monterail sit down with Daniel for a wide-ranging conversation that goes well beyond framework features. 

Daniel shares what it actually means to lead a global open-source project full-time. The exhilaration of a merged PR, the discipline of saying no to good ideas, and the frank conversations behind the scenes, including a candid account of working through tensions with Nuxt Labs over provider lock-in.

On the technical side, Daniel walks through:

• what he sees as Nuxt's real differentiator (spoiler: it's not the developer experience, it's the extensibility that creates the developer experience), 

• why Nitro is changing the JavaScript world beyond the Vue ecosystem,  

• and what Vue's closeness to plain HTML still means for developers today.

The conversation also covers AI's role in web development, and ends with an honest discussion about developer burnout: why it's usually not the developer's fault, and what managers can do about it.

Watch the full episode on YouTube by clicking this link.

About Daniel Roe: from Washington D.C. to Nuxt tech lead

Daniel: I'm a full-time open source developer. As you said, I lead the team building Nuxt, but I'm also involved in other projects, including in the UnJS ecosystem — I'm on the team building Nitro. I have a few projects of my own too. I live in the UK, in Scotland, where it's currently a nice afternoon. I'm not originally from here, though, as you might be able to tell. I'm originally from just outside Washington DC, where I grew up. I came to the UK for university and stayed ever since.

That was one of the biggest plot twists for me — when we were at Vue.js Live in London and you said you weren't originally from the UK!

Daniel: I promise I didn't try to change my accent or anything, but it did soften.

Story of Vue.js Live in London and Daniel's accent

Daniel: I think I do somewhere have recordings of me debating — I was very involved in debate in school. I have old debate rounds where I'm cross-examining my opponents and things like that, so I could probably find out what I used to sound like. But for myself, I can't hear any difference within my own head. You know, you can never tell these things — it's other people who tell you.

I think it's a very interesting question why people's accents change or why they don't. Is it to do with their identity, their perceived identity, their desire to fit in or to empathize? There are lots of different ways of reading these things. It could be a topic for another Monte Talks podcast!

Daniel: Who knows? Are you saying this one isn't about accents? Is that not what we're trying to talk about today?

It could be! But I'm afraid both me and Szymon might not be as experienced as you in terms of accents.

Daniel: Well, I guess you're drawing a line under it. Okay, carry on.

Why Vue won? From WordPress & Laravel to Nuxt

So, Daniel, you told us a bit about yourself, and I'm especially interested in what drew you to the Vue ecosystem. Right now, if you know JavaScript, you have a whole bunch of frameworks and tools you can join if you want to build open source and contribute. So, why Vue? Why Nuxt?

Daniel: I think there are two questions. One: what historically drew me to the Vue ecosystem? And two: why am I still in the Vue ecosystem?

The historical answer is that I had a small agency. We were building websites for people — though that wasn't our main job. We were a communications agency; we helped businesses figure out what they needed to say and helped them say it clearly and simply. One of the ways you help them communicate is through an online presence, so we built websites too. We came at it from the WordPress end because I had some experience tinkering with WordPress, and we gradually sought to add best practices. We looked to projects like Laravel, which were setting 12-factor methodology and best practices in the PHP world.

With both WordPress and Laravel, you're talking server-side rendered — you're writing PHP and have templates that mix HTML with dynamic rendering. JavaScript isn't the primary language. You're expecting a multi-page app by and large, and you can add a feeling of client-side rendering by doing something like Turbo and prefetching links, but it's not the same.

In the Laravel ecosystem, Taylor Otwell checked out Vue, thought it was very promising, and recommended it — I think probably just in a tweet — and the whole ecosystem got on board. I think one of the reasons is because of the PHP Blade syntax: it meant you could write Vue in your PHP files, pull in Vue itself as a runtime from a CDN, and Vue would discover the templates in the page. Since Vue is just valid HTML, those templates that persist in the page at server-side render become the declaration for what the interactive website is going to be, with data bindings and so on.

If you've ever loaded a page and seen curly braces in the HTML that flicker out as the app initializes, you might have come across a Vue app using this pattern. Obviously you want to cloak it — you shouldn't display it — but that might be a sign you're seeing one of these old-style Vue apps. This became very common in the Laravel world because you could carry on with your server-side rendering and just add bits of interactivity, a portion of the app hydrated by Vue.

That's why Vue originally adopted the terminology of "a progressive framework" — you could take whatever you were currently using to render your website and add Vue in. So that's what we did, with our Laravel or WordPress-based apps. At some point we even started building static HTML with Vue in it. And then at some point I was looking for a server-side rendering framework built for Vue, which was when I came across Nuxt and a number of others that I evaluated at the time. So I came into Vue very much from the...

Vue vs React: the real difference most devs miss

Daniel: ...direction of "I'm rendering HTML and I want to make it interactive" — which Vue is uniquely able to do. You can't do this with React; it's not valid HTML, you can't write it directly into your HTML. JSX isn't valid JavaScript either — it needs to transform. So Vue was, I think, unique in being very close to the primitives of the web, and it still is.

Even now, Vue single file components are written effectively in HTML, JavaScript, and CSS in separate blocks: a script tag, a style tag, and a template tag. That makes it so easy for people getting started with full-stack JavaScript, because you're not saying "create a user interface in JavaScript." You're saying "write this user interface in HTML and CSS," and then you can use the script tag or Vue directives to add data binding. But fundamentally, what you're writing is HTML, and you never get too far from that.

I hope people in the Vue ecosystem don't get separated from things like semantic HTML and using what the platform gives you.

From user to maintainer – how Daniel joined Nuxt Core Team

Interesting. So at this point — when you started with the agency, with WordPress, with communications — did you ever think or expect that a few years later you'd not just be using Nuxt but actually building it?

Daniel: No, not at all. I got involved in the Nuxt ecosystem in a similar way to how I tried to get involved in the PHP ecosystem — by helping out as I could. Mostly at first that was through Discord or GitHub issues. I'd often come with my own question or bug, someone would help me with it, and then I could help other people with the same thing. It's very much something I'd already received that I was then passing on.

And little by little I started making PRs to fix bugs or add features we needed. Honestly, there's nothing like the feeling of seeing a PR you submitted get merged — you get such a rush. Then the release notes for the next release come out and you're mentioned, and it's just amazing. You start to feel part of a community — you're building stuff together with people you look up to and respect, and then they say something nice about what you've built. So no, it was never something I was expecting or even trying to get.

Game changers in Nuxt: Nitro, Vite & what changed everything

So in terms of the evolution of the Nuxt framework — for the time you've been involved — you've seen many improvements over the years. Which features or improvements do you think have been the most significant since you joined the core team, and now lead it? What stands out the most?

Daniel: I think Nitro is a total game-changer in terms of what it's like to deploy a Nuxt app. Being able to deploy to so many places and have it be so performant is just a completely different experience. And Nitro is changing the JavaScript world, not just in the Nuxt ecosystem but also in the React ecosystem. Look at things like TanStack Start, or Angular's Analog.

I'd also point to Vite as another huge thing. The developer experience of having instant feedback as you type, and a lot of what the Vite ecosystem has pushed for — I think one thing people may not always mention is how easy it is to write Vite plugins and build on top of it. And that is really thanks to Rollup and the amazing plugin API that was developed for Rollup, which Vite inherits and has built on top of, adding its own hooks. It's a very simple object-syntax plugin — much simpler than a webpack plugin — and it's intuitive. Whereas webpack plugins, before an LLM could assist you, were incredibly painful to write if you didn't know how.

So Vite has really changed the game both for users and for people building on top of it — framework maintainers, library authors, or anyone who wants to add functionality. It started a kind of Cambrian explosion, a proliferation of libraries all around Vite. That's probably the second big one I'd point to. Between Nuxt 2 and 3 particularly we saw a lot of improvements, and I think post-version-3 there's been a focus on stability and reliability. I hope some of that has paid off too.

The one feature that makes Nuxt different from every meta-framework

You've kind of already dived into it a little — but if you could name one single thing that sets Nuxt apart from other meta-frameworks, imagine you wanted to sell Nuxt to React users. What would be the one big differentiator?

Daniel: I think Nuxt's extensibility is what I'd point to first. The fact that you have modules that can deeply integrate with Nuxt and how it works — it's not a black box. It's very much an extensible, hookable, modular build framework, a lot like Vite actually. If Vite were your full-stack framework, that would be Nuxt, because it's deeply customizable.

That means Nuxt has an enormous ecosystem of integrations. One of the reasons people pick a framework is knowing you have access to lots of different implementations and integrations — but also knowing you can build your own if one doesn't exist yet, because it's very possible to do that.

I don't know which is cause and which is effect, but there's a huge ecosystem of module authors. Jakub, you're one of them — your Nuxt Security module has a crazy number of downloads. There are lots of other key features that you might ultimately want in the framework, but there's never a bottleneck on the framework side because you can build it yourself. That means Nuxt isn't just a small core team — it's a much bigger, community-driven project.

I know that's a weird answer because a lot of people would talk about the developer experience first, but maybe the developer experience is good because it's community-focused — we all want to make the tool we use daily better. At the end of the day, I think it's the community that comes first.

Nuxt modules explained: how community features become core

I can completely agree with that. Even looking at our weekly ecosystem team meetings which Daniel usually runs on Fridays. When you have a core team of a framework, it's usually around 10 people — but if you look at the Nuxt ecosystem team, which I'm also part of, I believe it's around 30 to 40 people or even more. That just shows how huge the community is and how many people are actively working on it every day — it's not just five people.

And I really like what you said about modules as a pathway to shipping functionality into the framework itself. That's exactly what's happening right now with the content security policy feature, which is one of the key features of the Nuxt Security module. It has a lot of downloads, a lot of users — so even if not all of the module's functionality is relevant for every Nuxt user, CSP is something that could become part of the core framework. That's a really nice benchmark: if a module is heavily used, it's a candidate for core. For people who want to contribute but aren't sure whether a feature belongs in core — create a module, get feedback from the community, and if it's widely adopted, that's your signal.

But I wanted to ask one more question before we move to the open source topic...

Challenges in leading an open-source project

...about challenges. Building communities, maintaining open source — it definitely brings challenges. Do you have one biggest challenge you've faced over the last few years in Vue and Nuxt that you could share with us?

Daniel: That's a good question. What is the biggest challenge?

I think one of the central challenges is staying connected as a user. Whenever you build something good, it's usually because you've needed it yourself — you deeply understand what the user would want because you're solving your own problems, your own friction, your own needs. But as you devote more and more time to building the thing, you spend less and less time actually using it. And what happens then? You can potentially become further and further removed from your user. The code you write and the features you add might be intellectually satisfying, but are they actually making life better for the people using it?

So one of my biggest challenges is making sure I have enough contact with the cutting edge of Nuxt — actually using it. I try to build projects myself. Before joining Vercel, I contracted with companies, which was very helpful for seeing how things were being used. I'll also force myself occasionally to just take a moment and write a game or something, and then notice "that bit there is annoying, I need to change that." Giving talks where I demo things is helpful too — if there are rough edges, you start to see them.

The other challenge is saying no to good things that aren't quite in line with where you want to go. One of the things we deeply believe in the Nuxt project is the need for openness and user choice. And so it's been challenging at times.

Honest story about Nuxt Labs and conversations with Sébastien Chopin

Daniel: For example, Sébastien and Alex were the original creators of Nuxt — two brothers. Sébastien was also leading a company called Nuxt Labs, which was building some very cool products: Nuxt Studio, NuxtHub, Volta, Nuxt UI Pro, and more. The challenge was: I wasn't employed by Nuxt Labs, but I was leading the framework team — so how do you relate to a company that's building on top of it?

Sébastien's heart is fully in the right place. His desire is good; he's not looking to commercialize things in a way that makes life worse for users. But at the same time, something like NuxtHub was originally built with just one cloud provider. I understand that when you're building an MVP, you have to go with one provider to deliver a good experience. But being quite vulnerable here — Sébastien and I had some hard conversations about that. I was advocating for multi-provider support, and thankfully that's where things have landed now. NuxtHub now has great support for Cloudflare but will also support other providers, which feels like the right direction.

That's an example of the kind of thing I mean: there's nothing inherently wrong, but how do you decide which good thing to focus on? We want to grow in the direction of openness and choice — that's our priority. And that's always going to be a struggle for anyone leading anything. You always have to figure out where you're going to focus and what you're going to say no to. I'm glad openness and choice is what we're focusing on.

Why open source is really about people

There are a lot of interesting thoughts here, especially your perspective on how you approach open source. On that note — you've focused on the challenges — but what are the things you value most about working in open source?

Daniel: So much to love about open source. But primarily, I think the key thing is people. Open source at its core starts with "hey, look at this cool thing." And that's not something you say in a vacuum — you're saying it to other people. And then because it's open source, it's followed up with: "do you want to join? Do you want to do this together?" So it's all about the relationship between people. That's what it's all about, and that's also therefore what's most fun about it. It's also what's hardest — when you get further away from that, when you're focusing on chores and the boring stuff, that's when it gets more difficult.

But what's most fun is absolutely getting to work with other people and build amazing things with them, admire other people's work, receive appreciation in return. You also get to help people — people have questions, they need help, and you're able to make a difference. In a company you're limited in who you help on a daily basis. But when you're involved in open source, that's multiplied — you're helping people far beyond the numbers you could otherwise reach. It feels really great.

And then you get to meet them in person too. Just last week we were able to meet in person in Wrocław, which was amazing. I'd say it's all the people. Absolutely.

Just for the record — Daniel was in Wrocław for our Monterail Vue meetup last week, where he gave a really interesting talk about vibe coding in Nuxt. We'll be sharing it soon in this channel as well, so make sure to check it out.

You said it's about the people you can work with, the people you can help — and that's one of the core values of open source that I believe in too. But I also wanted to ask about collaboration between...

Can frameworks collaborate?

different frameworks. Obviously you can build things with other people, but frameworks themselves are usually these big entities that live by slightly different values, or are built with different technologies. Do you see opportunities for closer collaboration between frameworks in the future? I've seen that at some point you had — I'm not sure if it was a collaboration or a meeting — with the Qwik team. Do you plan to have something like that with other frameworks?

Daniel: I think it's always people. Even when you say "it's a framework," it's not — it's people. Particularly in open source, nothing happens just because "Nuxt is going to do X." Nobody on the core team or ecosystem team is going to do something just because we declared that Nuxt is going to do it. They'll only do it if they're personally interested, or if someone asks them personally, or if they get nerd-sniped into it — you know, "it's impossible to do that." "No it's not, let me show you."

As a framework, Nuxt is in a way a fiction. It's an idea that exists in all of our heads — a shared idea, like many things in society. So when you say "collaborating with other frameworks," I push back and say: it's always going to be people collaborating with people. The challenge is making sure you're talking to and working with people who are different from you. In this case, people working in different frameworks. But we could extend that to other kinds of difference too, because it's when you work with people who are different from you that you have the greatest opportunity to be creative and come up with things you'd never think of on your own. Maybe I'm totally in my Vue-centric head and I'd never think of something that would come up for someone with a React brain.

And the same is absolutely true in all kinds of other ways — gender, sexuality, geographical location, language, past experience — any number of things where someone will have an idea or perspective that I just never would. So yes, collaborating across those boundaries, with people who have different experiences, is absolutely something we need to do more of, and that's definitely true with people from different frameworks.

For me, one of the most helpful things is going to conferences — particularly ones that aren't just Vue conferences. You're talking to other speakers, listening to talks about different things, being asked questions from different perspectives. That's really helpful. Online, you always have access — you can DM people, you can talk to anyone. But the hard part is being prompted to think "huh, we should talk about that." You need that spark from someone.

AI will change web development (but not how you think)

It's also really important to try not to be close-minded, which is easy to become on certain topics — you have to actively battle it. And what you said about conferences is even more visible when you jump industries. I once had the pleasure of visiting a few game development conferences, and it was mind-blowing to see what's easy for them versus what's easy for us. Some things they have completely figured out, and some things that are easy for us are a huge pain point for them. There's definitely a lot of opportunity for knowledge transfer that unfortunately doesn't happen enough.

However, the question I'd like to ask now is more about the future — and it's definitely one you can't avoid nowadays: what do you think will be the role of AI in web development in the coming years?

Daniel: Yeah, it's a common question, and one we're all thinking about a lot. This is a new technology, a new tool available to us, and more than anything else, we're tool users — as people, as humanity. We use techniques and things that exist to achieve our objectives. The tools are constantly changing, and sometimes you have what feel like fundamental, revolutionary changes. Horse and cart to motorized vehicle, for example. A lot of people think AI is that kind of change. Some don't. Either way, it's a tool, so a lot of us should be trying it out and figuring out how to use it to achieve our objectives.

In the most optimistic view, AI makes it possible for us to be much more effective — maybe faster, or spending less time on the boring parts of our job, or gaining expertise in areas that would have taken much longer otherwise. Hopefully it will augment the power that we as individuals possess.

There are also more negative potential sides to LLMs and AI. But I think that more negative side is less in code and tech, and much more in other parts of society — AI-generated videos fooling people into thinking they're real current events, AI-generated text confusing people about what to trust. That kind of societal change is something I'm very worried about. In tech, things are much more positive — these are tools, and the models produce code of varying quality. Staying on top of how to use them most effectively is almost a full-time job in itself.

I don't think anyone who is using their critical thinking skills or who has embraced change is in any danger, because as with any tool, you always need people to evaluate and use the tool. Our job is to figure out new technology and use it effectively. Today that might be Vue, HTML, and JavaScript — but these things are changing all the time, both the languages and the tools. I remember before VS Code was a thing — there was a time when Atom was what you'd use. It was obvious, why would you use anything else. And then VS Code took over seemingly overnight. The tools change, and we love our tools as developers — we customize them, hone them, get rid of friction, set up our dotfiles. That's a great thing. But we're not stuck at any one moment. We're constantly iterating: how can I make my experience better? If that's you, you've got nothing to worry about.

How to grow Vue & Nuxt–what the community really needs

I can definitely relate to that. On the topic of dating myself — I use Vim, so I know a lot about tinkering. And one of the early challenges with the new AI era was that there wasn't great support for AI tools within it. I had to early on adapt my workflow and try to plug in other tools to it, with mixed results. But you've got to try and adapt — and if something doesn't work for you, that's fine too. The important thing is not to close yourself off and to try things yourself to build your own opinion.

Maybe one final question on this theme: what do you think the community could do best to support the growth of the Vue and Nuxt ecosystem?

Daniel: I think one thing is: build cool things and share them with people. Being able to point to projects built with Vue and Nuxt is great — there are so many. We don't always do a good job of promoting that. I know there are other frameworks and communities that really shout about every single site built with their stack, and I feel like we could be better at that.

I also think we could do more at the level of helping people find jobs. People come to me and say "the problem with the Vue ecosystem is it's so hard to find developers." And developers come to me and say "the problem with the Vue ecosystem is it's so hard to find companies hiring Vue developers." They should talk to each other! There's a perception that there's a much richer vein of jobs in the React ecosystem, and I'm not sure that's actually true — but clearly we're not doing as good a job communicating that. Maybe it's about the forums out there or the ways people look for jobs. It might also be that people who can use Vue can probably use React too, so they're often proficient in more than one thing. So if you're looking for a side project, something in that space might be worth pursuing.

How to start with Vue/Nuxt–beginner advice

And on top of that — if someone wants to start developing in Vue or Nuxt, what would be your advice? Say they've only ever used React or Svelte, or they have no framework experience at all — they've just heard there's this cool framework called Vue, and maybe an even cooler meta-framework called Nuxt, and they want to try it out. What's your first advice for them?

Daniel: One thing I'd say is try something like sfc.vuejs.org — you can actually write code in the browser and see what it produces, no build setup required. That's a great first port of call. If you're going through a tutorial, you can just write your code in the browser, see what it does, interact with it, and get errors if you do things the wrong way.

Then I'd say: write HTML. Really lean into HTML and write it in your SFCs. There are great courses out there — personally I learned Vue from Laracasts, given my own path into Vue. There was a free "Learning Vue" course there which I found excellent, but there are lots more. If you're someone who learns by building, try making something — a game, any kind of project — and look things up whenever you hit a question. That suits me very well. But whatever your style, try to use it and remove as much friction as possible. sfc.vuejs.org is a good start.

Sounds great. I remember my own beginnings — it was with Vue Mastery, with Adam Jahr, who was doing the course on Vue Socks. So I'm always saying "Vue sucks," you know, in my heart — but in general: find the course you can learn from, then build even a simple app, because it'll show you whether this is the right tool for you.

But apart from giving advice to others on how to start — I wonder, looking back at your own career and growth over the years...

Career regrets? Daniel's honest reflections

...do you have anything you would do differently? Do you look at your past self and think "I should have done this differently"? Or are you completely happy with where you are?

Daniel: I think I'm happy with where I am. I'm really pleased to be here, and my path has been a very winding one — not at all straightforward. And I fear that if I were to change too much about it, I might not get here. I might be somewhere totally different. So I'd keep it as it is. That doesn't mean I did everything right — I made a lot of mistakes — but the mistakes were also useful.

How devs burn out (and how to avoid it)

So maybe one related question: what do you think is the key to staying passionate and motivated as a developer?

Daniel: I think it's not necessarily your job to stay motivated and passionate — or at least, it's not entirely in your control. A lot of the things that drain your motivation or passion are not things you do, but things that are done to you. So I think the managers of developers bear more responsibility here.

In my experience, things that help are a sense of ownership and agency — the ability to do things that affect you. Think about where you receive value: from people saying "well done, that's great," from your salary, from a bonus, from the approval of your peers — whatever matters to you. Now, do you have any ability to influence that? To put in the work and get back something you find valuable?

When you can't influence that outcome — when a target is totally out of your control, or you're working on something that never gets deployed, or a project drags on forever and you never see the results — you're being detached from the feedback loop. You have no ability to receive value, and that leads straight to burnout. But that's not your fault. That's on your organization, on your manager.

There are things you can do to help, though. If you don't have those opportunities at work, you can find them outside of work — open source might be one, a side project might be another. Whatever it is, find something where what you do has an immediate, demonstrable, and valuable response — whether that's people telling you it's great, being able to share on social media, or just the pleasure of doing it.

And if you're not getting it at work, talk to your manager, talk to HR, figure out how you can find a different situation, because that's the kind of thing that will eventually lead to burnout. If you're not feeling motivated, that's not necessarily your fault.

I think that's something I can echo as a manager: reach out. People usually reach out to me too late, which is a shame — because commonly they either don't think the situation is resolvable, or they just don't see what actions are available to them. So yes, if you have a manager, definitely reach out.

Since we're almost out of time — is there anything else you'd like to share with the Vue and Nuxt community before we wrap up?

Daniel: No, just keep being amazing.

Where to follow Daniel Roe + final thoughts

Awesome. To end things up — where can our listeners find you online and follow your projects and what you're doing?

Daniel:I have a website at roe.dev where you can find out how to contact me. I also have an open diary if you want to book a call or a chat — I'm pretty happy to do that. I'm on social media as well, most networks. Bluesky is probably the best one to reach me on. But yeah, I'm always glad to see a DM or a message.