You Are Sleeping On Nuxt, Nitro and Vue w/ Daniel Roe

Welcome to Syntax. Today, we have a great one. We're talking Nuxt and Nitro with Daniel Roe. It's gonna be really awesome because Wes and I have just about zero knowledge on some of these things. I go occasionally to the Nitro website or even the Un.js website, and I look around and say, oh, wow. There's a whole lot of stuff here. So, hopefully, Daniel, you'll be able to demystify all of these things and more for us. So, Daniel, welcome to the show. It's, it's a pleasure to be here. Thank you for having me. Yeah. Yeah. We, this JS by popular demand. We've had

bunch of suggestions over the years to to have you on. And, on Blue Sky recently, everyone's like, have Daniel on. Have Daniel on. And it's Sanity, like, we cross paths at one of the conferences. What conference was that? A couple of months ago.

GitHub Universe. You were at that one as well? That's right. Yes. Absolutely.

There was another another conversation I had with someone at at the Syntax meetup there that yielded a ski trip.

It was, it was super cool. So, I mean, this is clearly clearly was the meetup to be at. So just a word of advice to anybody. If you see a Sendax FM meetup, in your in your city or at a conference, you should just go.

And, who knows who knows what will happen? Skiing, traveling cars. We filled that pizza place. There was, like, a good amount of people in there. We we just, just totally kicked everyone out pretty much. We're all but just the entire restaurant. Together.

I'm I'm still having good dreams about that pizza. It was it was that pizza was so good. I I've never had that. What was it what was it what kind of pizza was it again? Well, I it's it's going to actually make me Node upset. It's Detroit style pizza, but it it's not really Detroit style pizza. That pizza was good. I'll tell you that because I was trying to explain this to my wife. The pizza was good, but it's like if somebody made Detroit pizza by, like, playing a game of telephone. Because everybody there was like, oh, how is this? How Scott, how you know, does this hold up to the real thing? And it Wes like, yeah. It's not really close, but it was Scott from Michigan. So he knows the the legit stuff. Yeah. It was good. Yeah. Yeah. It was good. Alright. So, Daniel,

introduce yourself. Who who are you? What do you do? All that good stuff. I'm a full time open source contributor.

So I I lead the the team, maintaining Nuxt, which is a framework for building full stack web apps. I didn't create it.

I joined the core team a few years ago and, started leading leading it, in January 2024, I think, just after the release of of Nuxt Nuxt three. I also have some other open source projects I'm involved in. But before that, I I really had a totally probably a totally random career path, not not one that you would expect would end up in full time open source, which is what I'm what I'm doing now. But but yeah. So I've I've done lots of different things. That's awesome. And you also work on Nitro, which is the,

like, server toolkit. It's part of on JS?

Exactly. So Nuxt is a is a is a bit like Next. JS, but for Vue. Yeah. So it was released the day after it, back back some Scott time quite a long time ago. It was created by, Sebastian and Alex Chopin. And just by the name, you can tell it's going to be an amazing framework. Right? You feel like, oh, the Chopin brothers have created this. It'll be melodic. It will be be incredible.

They grew up in the Pyrenees, which is where the mountains of the Nuxt logo comes from.

So very, very home home brewed.

And, but we we rewrote it totally from scratch for Nuxt three, and which was, by the way, a very interesting, experience, to do on an open source project. I don't necessarily recommend it, but one of the things that we did was rewrite it for a serverless world, and for for the idea of a non a potentially non node world. So what what what about other runtimes? At the time, really, it was only Cloudflare.

Since then, we've had Bos and Deno and, you know, who knows? In doing that, we rewrote what was originally we called it Nuxt Sigma.

And Nuxt Sigma was our our rethought, Nuxt server.

And then we we this part of the whole process, we we decided, actually, rather than building parts of Nuxt, why don't we go the true open source way and make them small composable reusable packages that can be built on by other people.

I I always think, personally, that it it might take longer if to collaborate and work, with other people to build something, but you always go you always go further. You always build something that's better. And so that's what we've been trying to do with Nitro, which is, originally the server engine for Nuxt, but now, it has a considerably broader scope. It powers tan stack start, solid start, analog, which is an Angular meta framework.

And I I hope it will power others because a lot of us, meta framework authors and even people who are just building their own APIs, we have similar needs. We want to deploy to lots of different providers.

We want to work on different run times.

And rather than reinvent, like, invent these things over and over and over again, it's better to have a a common base where we all pitch in and and, you know, can talk about our goals. So that's Wes Nitro is. It's the brainchild, I should say, of Puya Parsa, who Wes the the previous team lead of of the Nuxt core team, and who who now spends his time focusing on this js GitHub, org you mentioned, which is dedicated to all of these packages that we created to be, part of a broader ecosystem, not just for Nuxt.

And

I I hope that's that's that's what they are. Yeah. Yeah. So that answers a lot of my Wes, like, what came first? Was it, like, Nitro that came first and then Nuxt? But it seems like you said it was originally Nuxt, Sigma.

And you mentioned on JS being this collective of different compatible packages and and various things. So we have Nitro, which is part of on JS, but how how what's the connection there to Nuxt, or is there a connection?

So I think other than the story of us wanting to take some of the things that we're building that we needed to build Nuxt into a place where they were could be used more broadly. So I could tell you stories about lots of those libraries, but but apart from the origin of many of them, there is no, one to one connection.

A lot of people contribute to NUXT who have nothing to do with Nuxt. The NUXT libraries are used in lots of places that are not related to Nuxt. For example, they're used in Tailwind CSS. Jty, is used to run, to pass the Tailwind config file for a specific purpose.

It's, something we Node also. So we you know, it's used to pass the Nuxt config file, like to execute TypeScript, CSS, MJS, all these different possible extensions in a a straightforward way without any dependencies.

And so it does that very well for Nuxt. It does that for for Tailwind and hopefully in other places too. So many. The the whole on JS ecosystem

is is so cool. I I did a talk at a conference a couple of months ago about all these different run times, you Node. Like, we have you said, like, there's BUN and Deno, but then there's there's Cloudflare.

And, like, Cloudflare, a couple months ago, announced, like, 98% Node. Js compat, and it's because of one of the on JS packages called unenv, which just essentially polyfills all of the Node APIs so that they just just work everywhere. And it's just like a massive set of primitives that are allowing people to to build amazing things. Like like, you look at something that rivals Next. Js because they're, like, standing on these massive projects like, like Nitro.

I mean, I think that's the the whole joy of open source, isn't it? That you basically I mean, zooming back a bit. I mean, it was the UNIX philosophy to have all these little programs that sort of worked, and you could chain them together. I don't know if you're a sort of, Linux user.

I I should know that, but I'm not sure I do. I'm Scott. But, you know, you We get it. Let's the do one thing and one thing well. Right? Yeah.

And I and I think, you know, there's there's so many projects that do this well these days, like Vite, for example, which is omni capable.

You know, they could have gone in a very different direction. They could have gone in the direction of being, like, the bundler, like, the framework, and they didn't. They chose to work really well with a lot of, teams building on top of Vite. And, you know, I think I think when you see that, when when it's like maintainers and and packages, libraries, it welcome collaboration and contribution and and lift, you know, each other up, then you really get this wonderful sort of ecosystem benefit that you're talking about. So, you know, TanStack Scott, hopefully, is able to get going a lot faster because they don't have to reinvent the wheel. Hopefully, that means they can also give it their own flavor, you know, with the the router and, you know, the the amazing stuff, Tom is doing with with types and, you know, and make something that's that's very cool very quickly. I'm wondering about with un JS. Like, what makes something in un JS package specifically,

rather than just, like, a miscellaneous Node or JavaScript package?

That's a good question. And, I mean, I should say that that, you know, the best person to talk about that would be would be Puya. Yeah. I've been DMing with him. We're gonna have him on because he's he's next level.

He is. He's great. Puya's great. I think the kind of things that we we look for are things that are universal.

So anything that is highly specific to Node, for example, is probably not pnpm package because we want something that will be, runnable everywhere. That doesn't mean it can't have a Scott like a specific node implementation, but we use the winter CG now renamed to a a slightly different name. We use the sort of universal keys for the different run times, which means that we can have packages which run equally well in lots of different ones. So it doesn't mean you can't be specific, but we we do try think for things to be universal.

I think there's a strong focus on trying to reduce the number of packages.

So I, for example, have currently three font related packages in on JS.

And, actually, I'm gonna try and merge those into a monorepo because it feels like that's it's starting to get a little font heavy.

So things that are that somehow are are universal somehow have a sort of adapter pattern for easy extensibility or a sort of coming up with a generic API, that's also a good indicator.

So for example, Unifont allows you to connect any font CDN and get font data back. So it's it's something that can be used by, like an a font integration. And I think and another good question would be that, is this a an essential building block for a framework? Might be another another thing. So I think the the idea of something being essential or a key building block for building other things on top of that that that's what I would say. But, obviously, Puya will be he'll he'll give the, like, the full full and, authoritative answer on that. Totally. So there's nothing that makes nitro. Let's, like, even say nitro specifically.

There's nothing preventing anyone from just picking up just nitro and using just nitro by itself. Right? No. No. Absolutely not. Nitro itself does use, quite a few of the other packages under the hood, like, for example, was originally created to enable Nitro to build servers for CloudFlare, for example, or other non node environments.

There There was even I think that I'm not even sure this exists anymore, but there was even an experimental preset, worked quite Wes, that allowed you to build a server for a browser service worker.

So as soon as the browser service worker, was, installed, you had server rendered HTML Yeah. From the browser. From the browser. Yeah. Which you might say to me, why why would you do that then? And the answer is because it was there.

Yeah. That's a that's a that's a possible target. So, yes, Nitro uses these things under the hood, but, really, if all you need is to create a quick, API, you don't need any framework, you don't need any integration, I absolutely would pick Nitro up. It is fast. It has a lovely, very economic approach, and it's fully type safe end to Deno. So you get a lot of of nice things, out of the box.

So that sounded a lot like a sales pitch. No. That's good. No. I would I would I would I would definitely use Nitro as I was saying.

Yeah. And and so Nitro, I mean, like you said, comes with a lot of stuff out of the box. And I guess we can get into some of those things because there's a key value storage, there's a SQLite, there's tasks and WebSockets.

What is the goal for including things? And, like, where do you see it going with what will be included in Nitro?

So one of the inspirations for, for me, for Puya, and some of the other members of the team are frameworks like Laravel, for example, which have this beautiful story of integration, Wes things are thoughtfully laid out, where you have adapters to, like, hook into different providers, for example, different authentication providers, different databases.

And so La Lavelle gives you everything you need to build a a server rendered app or API.

And Nuxt originally started as a pure as really a front end framework, which had server rendering.

So you had some server components to that, but there was there was you know, it wasn't really a full stack framework.

Because although you could do some things in those server roots, things like authentication, databases, KV, there'll be a lot of things that we're missing from that. And so I think that's that's what we're looking for for Nitro to provide JS everything that you would need to build a full stack app. For Nitro to provide all of the back end that you need and then a framework like Nuxt or TenseDEX Scott to provide all of the front end and back end integrations on top of that that you that you would need.

So I think I would I would like to see that you don't need anything else besides Nitro.

Obviously, you you you can. You you can always, decide, hey. We're not gonna handle the WebSocket stuff ourselves. We're gonna use this provider for that. We're not going to handle the, you know, the notification levels. We're not gonna handle the cron jobs. We're going to do something else for that. But Nitro should provide integrations in a provider agnostic way for all of these things, which, of course, is is the aim. So the tasks API, for example, it's still quite early days.

Platforms like CloudFlare provide cron syntax.

So you it triggers so you can have tasks that run sort of in parallel there. Targets like AWS also have, the idea of background tasks that can run.

So figuring out the right API to make that work seamlessly across all the deployment targets, some of which don't have support, that's that's the tricky thing. I mean, the whole the whole concept is no lock in. Right? So the whole thing that that Nuxt is about as well JS Wes we are, you know, we're built by the community. We are independent. I I want to have a great integration story on every provider. And people often asks ask me, you know, what's the best place to deploy Nuxt? And if my answer is any Node limits or directs people to deploy somewhere should be the feature set of that deployment provider rather than something in Nuxt that directs people one way or another.

Getting that right isn't isn't always easy because zero configuration is the best possible experience, for example.

But then there are there are there's always pros and cons. So for example, some, provider support image optimization as a native primitive, which is great. But often there's a cost associated with that. So on the Nuxt level, for example, we have our Nuxt image integration.

What is our zero config deployment strategy for people? And, how do we how do we look after and give people good defaults so they don't end up with massive bills, but still have great sort of integration with providers? So we Wes have to juggle that and figure out what the best the best choice is. But, yeah, we we want to be working lots of places and and and working really well. One of the things I I love is that wherever we have this provider a path, I've mentioned that. It means for something like Nuxt fonts or Nuxt image or Nuxt scripts or Nitro itself, you can say, you know, we want this preset. I want to use Cloudinary or I want to use, you know, bunny, fonts or whatever.

But you can also also write your own. You just can provide a path to your own implementation.

And we try and make it easy to write those as well. And that's often a way people can build their own integration and then later make a PR to Nuxt or Nitro or or whatever because extensibility is is really something I'm looking for whenever I use a platform.

I mean, if it's zero config for me, that's better. But if it isn't and I want to to to do my own thing, I want to be able to do that. Can I ask you to get a little bit opinionated

about some of these, like, places to deploy something? Because let's say I ask you to build a full stack app. You know, you need you need server JavaScript.

You need, obviously, front end. You need images. Maybe you need a key value store, and you're gonna need a database.

There's lots of different ways you can go about it. Right? You could build your own with AWS. You can go all in on, like, the cloud for Flare versions of all of that. You could just deploy the whole thing to Vercel.

There's lots of different avenues to go at, and they all obviously, they all have their their ups and downs.

And I'm I'm curious your opinion on these types of things, because some people are like, oh, just stick with Node, and it will be fine. And just deploy it to a regular old server. And a lot a lot of people are like, just everything on Vercel, it's a little bit more expensive, but I I wanna I don't wanna have to mess with it. If you were building an app today, what would you choose?

You're you're asking if I am building an app. Yeah. So a full time open source maintainer is building a side project.

And that is gonna give you a different answer to if I am launching a Scott up on a thing. It's not a side project. It is what I'm doing, and it's gonna give you a different answer if I'm leading an established team.

And so but because a lot of these platforms and I'll I'll go into I'll I'll get opinionated.

But it really does it really does matter, and I I know you know this. But, like, I for example, I I love hardening Linux VPS. Like, it's so much fun.

But the moment you have I have so I mean, I've I've I've hosted websites for clients. I've maintained their service for them. And let me tell you, there JS something about being on call and knowing that if their website goes down, I have to fix it, and I have to fix it ASAP. That means that I appreciate the serverless serverless offerings and the whole concept of that because, yes, it might be more expensive, but I absolutely value not being the the the one on the line when the website is down. Right? So picking serverless, just as an example, I I almost always you know, I I I almost always would. But I pick that because I don't want to have to think about the the server because I've been there. I know how to do it. I'm I'm fully fully able to do that, but I don't want to I don't want to. I I I want to have, you know, peaceful evenings. I don't like, I I don't so so, yes, I I I can absolutely host everything in a $5 VPS, and and I'll be fine, but I'm not going to pick that for my for either my side project or my startup or my established company.

Like, I I I'm I'm picking something that lets me scale and lets me have, have a good night's sleep. I'm picking something probably if I'm starting from scratch that has really decent billing, and caps. I don't want I don't want worries. I've never had an issue, by the way.

I'm I've been on hobby tiers for Vercel and Netlify and Cloudflare Deno. Maybe you say that's just Daniel because you've not been very successful. That might be the case. That's the hack. But don't build good stuff. Exact I I I wouldn't go all in on Vercel's platform. I what I found was that I very, very quickly exceeded their free tier on stuff like the analytics.

So it was it was a beautiful dashboard, but but, I mean, I Wes I'm talking my my personal blog, you know, and I'm I don't I don't get income from that. You know? I just wanna I just wanna know, are people visiting it or not? And so there is no way I'm, you know, paying pro pro fees for that. So so I I first self hosted a Plausible, which Plausible is amazing.

And I only Yeah. Self hosted it after I ran out of their free tier as well. So I might might have a problem in general with analytics. And then I I moved to CloudFlare Analytics, which ended up being, sort of more affordable.

But, again, these are the sorts of decisions that a lot of people aren't like, I I I'm a company JS not gonna care about that level of Scott, whereas I'm I'm I'm caring about it just because of of who I am. I'll tell you, Cloudflare is a very attractive proposition right now because it of the insane cost value like, value of the the services.

Yeah. The DX of their dashboards is really quite poor.

Yeah. And I I I just I I feel like there are times when I would be employed by Cloudflare. You you know, when when you sort of you go in, you're like, I'll I'll I'll take a job. I'll fix the things, and then I'll and then I'll leave. I feel like I would do that for some things. Why? And I'm just gonna go on a a little rant. If anyone from Cloudflare JS listening, please fix this.

Every time I click, you know, I have a CloudTrail pages site or something JS deploying on GitHub, it says, you know, view logs, view build logs. Okay. I think, oh, I'd like to view those build logs. Click. Oh, I have to log in again. Somehow, the login I had earlier today is no longer valid. I log in again. Okay. Two factor authentication. Okay. I'm finally in. Now it asks which account I want to, like, to view the logs through. You should know this. I've clicked a direct link to view the logs. And once I select it, then it takes me to them. But I feel like I shouldn't have to do this. I have had to do so much clicking just to view these logs. Something like this Vercel, they have nailed DX. Yeah. Totally. Vercel are incredible.

I mean, whoever is in charge of that team, whoever is involved in that team, they should be patting themselves on the back because it doesn't get smoother.

It really, really I'm I haven't used a single platform, I think, that is not a better experience from the point of view of dashboards, of logs, of everything. It is just gorgeous.

And, you know, I I I've I've used myself for my personal website for years, and it's, until recently.

And it's it's been it's it's I just think it's amazing.

Sorry. One more one thing I wanna say real quick is I'm very much on the same page as you with the very bullish on CloudFlare.

And somebody somebody who said on Twitter the other day that you with Cloudflare, you pay with your time, which is is often true. It's just these random things come up. They're like, how do I approach this? And it's always a little bit different. But and then the Vercel, it just works, you know? And, I'm still I'm trying to put a Next. Js app on Cloudflare right now, which is, working fairly Wes. But, of course, you you pay with your time a little bit.

Yeah. I don't think I'd be able to set up a Cloudflare tunnel, without some sort of step by step guide. Like, just clicking through the UI. Like, oh, I wanna do this. Let me click through it. No. You you'd just never be able to figure out where you're supposed to click or what you're supposed to do. And Vercel, I yeah. The CloudFlare

dashboard is larger than that. They're very receptive to it as well, though. Every time I've got a a minor ache or pain, I send a little screen recording over to somebody and, like, they're they're very, very responsive to it. So, anyway, sorry. Go ahead, Daniel.

No. I I I totally I totally agree.

They are. And I think sometimes things like this, people encounter, DX problems with AWS as well, for example. And I think I'm guessing both AWS and Cloudflare have a similar cause, which is that they they have empowered teams to act as almost independent almost independently.

So they can move quickly. They can build stuff out. They're in charge of their own fragment of the dashboard, which has the negative potential consequence of stuff doesn't necessarily integrate that well because it's it's not driven from a I mean, I'm speculating.

I don't know how Cloudflare JS sort of made up internally until I get that job and, you know, to try and do the stuff that I want to do. And I might discover it's a little harder than I than I think. Yeah. Right. Yeah. But I I I I wonder if part of it is that. And sometimes maybe it's the the consequence of having that the sort of the velocity at the team level. So NuxtHub, which by the way is not, it's not Nuxt. It's a a separate company also started by the creator of Nuxt has created that. And he's basically building, if you ever used Laravel Vapor, which the serverless it basically integrates with your AWS or at least when I used ESLint, integrates with your AWS account, configures it for Laravel, and then gives you, like, a dashboard view of it and manages the deployment. But it's still your account, and it still uses resources on your account. So Sebastian and, and his team have built something very similar for CloudFlare for Nuxt and Nitro projects, which actually also works, like, SolidStart and CanstackStart as well. So I I wouldn't be surprised to see maybe a rename coming because it feels like it's maybe more Nitro GitHub than it is.

But anyway, he's he's building that. And I think that kind of thing, or if someone wants to do this at something more generic, that there's just sort of a wrap around CloudFlare that basically gives you a a better DX.

That kind of thing, I think, would would be would make a killing because it's just it's using the primitives that are there. It's using API that's there, but it's it's giving you the integration that it's giving you the seamless Mhmm. Flow that Cloudflare isn't.

I mean, it's also a very risky,

strategy because if CloudFlare improve things, people might say, not see the need for it. Yeah. So it's AWS has not done that, though. That's we always wonder, like, why does AWS don't Node make a Vercel? You know? Like, why don't and that's the whole thing we want cloud we want Cloudflare to be the, like, raw cost of AWS, but we also want it to be the Vercel experience.

And it's worth saying that, you know, the whole you pay with your time thing, it's a reason why you might not go for the thing that is technically the lower cost. Mhmm. So, you know, I mean, I've I've worked with teams that that are, building Next. Js sites, deploying on Vercel. I have recommended Vercel to to companies in that kind of situation because of the seamless flow.

People understand how it works. They find debugging super easy. The preview, deployments and the ability to add comments to them, it all works really, like, really, really well.

And, you know, the velocity you can get with that is is worth worth quite quite a Scott, you know. If people say, oh, you know, the markup is twice as much or Yeah. Whatever it is. But it's not it's not about necessarily raw numbers. I mean, the there's a lot going in. You know, you paid developers quite a lot as well. You know? It's it's it's not a not a cost Wes endeavor.

And if you want to see all of the errors in your application, you'll want to check out Sanity at century.i0/syntax.

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on over to century.i0/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

It is interesting, but cleft flare is so cheap. Have have you checked out SST at all?

I have. Yes. So, it was, again, much like by the way, I got the impression I'm sure this isn't what you meant, but I got the impression that, basically, you've been resisting, haven't you? You've been like, we don't we don't want to happen. People are asking that they shouldn't get Deno on the show, and then, basically, your hand was forced at the last minute by Blue Sky. Oh. That's that's the that's what I'm I'm No. No. That

I'm I'm Scott inaccurate. That is not accurate. Yeah. To Wes to come on the podcast is we have a bazillion of them, and we have to balance them. Because sometimes we have guests lined up for two months straight and, oh, man, We all kinda overdid it.

Well, basically, people were ask warp doing the same for us with SST.

So people people were saying, oh, when will Nuxt come for SST? When? Why why is Nuxtbot available for SST? And so, it was it was Dax and I basically had a very long running back and forth on, on when Nuxt would come to SST. But it is it is now it's now, shippable on SST. So I I I I I Node it. And SST is it's, I've seen that sort of back and forth, in terms of the underlying infrastructure and how it deploys.

And, obviously, I have a lot of time for for for Dax's, brand of humor, which I find.

Yeah.

Yeah. He's a good Node. Yes. So yeah. Yeah. I've come across Sanity. But I guess sorry. You were you were saying something about it. Oh, no. I I'm just, you know, relevant to our our conversation about, deployment.

Wes you where you deploy. Yeah.

So SSD, interestingly, it's it's sort of a little different from a lot of the providers because so for example, we have, like, an AWS Amplify provider Wes everything is at the the underlying level, and you have image optimization and Lambda and CDN and so on. And the same is true for, you know, Netlify and all the we've got we've got so many. We have me I have 30 plus providers, I think. Wow. Jeez. And for most of those, Nitro, Nuxt JS responsible for producing an output that gets consumed directly by the provider. And so Nitro will say, you know, hey. These are the CDN assets and, you know, this is a a JSON file with information on how to configure the image optimization. And, you know, this is the, this Vercel endpoint. This is how you're going to render stuff. And and everyone has different different output format. So Cloudflare, you know, also Node the JSON with rewrites, so you don't have a dot HTML at the end of your any prerendered routes that you have, for example. So there there's lots of stuff that happens behind the scenes to give a zero config actual final deployment. Meaning users don't have to have a Netlify TOML file.

They can set header for example, they can set their headers and their redirects in a Nuxt format, and it will work whether they deploy to Vercel. It produces a Vercel dot JSON. Warp Netlify, it produces, like, an underscore headers, underscore redirects, or whether they deploy to Cloudflare. It also produces, underscore headers, but a different format. But so they have all of these, slight tweaks. The thing about SST is that rather than Nuxt to Nitro being the thing that generates all the config for that provider, it is like a part of a of a config which the user is writing instead.

So it's it's a it's a different level.

So it's not really, it's not operating in the same way as the other providers.

So it it basically slightly reduces the scope of of Nitro in that and Nuxt in that context. They can do less. So they're slightly less capable.

But on the other hand, you know, the user is is is doing that. So it will therefore involve more configuration from the user, which is why I wouldn't necessarily go straight for that, not meaning anything negative about the the the target, or about SST either, which I think is really exciting.

But it's it reduces Nuxt and Nitro a a little bit, I think, in terms of the capability.

So it started Nuxt started off JS, like, a Next. Js for Vue. JS, like you had mentioned. But that was a while ago, and it's 2025.

And it does feel like they've diverged a bit. What makes Nuxt better in 2025?

So for a Scott, see, Europe, we definitely have diverged. We're definitely different.

And I'll tell you what I I love about Nuxt that is not there for for Nuxt. But I I do think Nuxt is also a good good framework. So Tell me why you hate Next. Js. Exact so this is the real reason.

I think, Nuxt has an amazing community.

So it's very much community built and led. So we don't have a VC backed company Scott of driving the direction of where Nuxt goes. The direction of Nuxt comes from the community.

And so it matters a very, very great deal. Wes we're, you know, we're we're smaller than Nuxt, I think, because Vue is is smaller than than React. We're still pretty big, but it means we don't we have a slightly different feel in terms of what the the people who, who are involved in the project are like and the difference that people make to where we go as a project. We're also very, very customizable and extensible.

So Nuxt has the concept of modules.

So you can basically add anything or do anything to Nuxt, either in your own project or by creating a reusable module.

We expose hooks at every stage of the build process. Almost everything is swappable. Even the bundle we use, Vite by default, you can use Webpack. You can use RS pack. Mhmm. And so there's lots and lots of scope for customization.

We have and even at the level of TypeScript really anything, you can you can you can do almost anything with with, modules, which means we have a whole library of over 200 modules that people have created. That's all in in an API.

You can add your own module to the list. People can discover it and use it. I think that's pretty unique, with Nuxt. I haven't come across a framework that has a similar kind of thing. We also have a very, very strong, ecosystem value for that reason. These are you can spot the thread between the three of these things. Mhmm. We have an ecosystem CI.

When we have change breaking changes, for example, we try Node, Vercel three onward.

We try and make sure that everyone is, has a backwards compatible, forwards compatible approach.

I will go ahead and I'll open PRs to modules, for example, that solve their problem that they might encounter when we do upgrade to that version in advance because it's very much a case of Wes need to go together.

I don't want to break people's projects.

And, thankfully, there there are tools like Ecosystem CI, which, was originally came from the Vee project, which help us do that, help us go together and move together. And I think maybe the fourth thing is the our very, very strong value on agnosticism.

So we obviously want best practice to be built in, like any meta framework.

But we really have a very strong value on letting user be ultimately in charge. You Node, pick your own KV store. Pick your own database. Pick your own ORM. Those are all possible to do.

Your own image provider, your own deployment provider, that is totally within your control, and we want you to have a good experience of all of that. It really has a downside.

The downside is I mean, if you're if you if you are a Next. Js and you are targeting Vercel, so you basically have, like, a node preset where you which you can run on a VPS or you can on a a Docker image or you have Vercel, which has a lot of capabilities as a deployment platform.

You can obviously, as a team, spend a lot more time getting those great.

But if any, you have a Nuxt, and we support 30 deployment providers, and we support, you know, 20 image providers, and we support, you know, so, like, the number of things we have to support JS many is is a lot is a lot more.

And and it's not surprising Wes are dependent on the community to drive bug bug reports and pull requests, you know, features and fixes.

But I do I would rather it that way. I would absolutely rather have the control and have the ability to to customize stuff. And that means for most people, they don't have to. So they get the zero config or they they just install a module, and it does everything they needed to do. But, yeah, those are four things.

Yeah. I I like all that. I mean, it's such a a theme of openness and community and just all those those things that I don't know. A lot you Node, some frameworks can feel closed off, and this kinda feels the exact opposite besides the fact that you have to use. That's like the big that's the big one thing. Right? Yeah. But Vue JS great. So yeah. Do you know we do support JSX.

There's there's some differences. Like, you don't use class Node. You just use class.

But other than that, it might be the JSX that you you know and love, except that it will look it will feel a little bit more like solid because it doesn't it doesn't rerun in the same way. Like, it has a setup function that happens at the beginning and only once. And then after that, you do but you could write JSX if you wanted.

You know that that that site you're deploying to Cloudflare Wes that you've been spending all that time on? We should we should talk. I'll I'll give you a a nutshell. Cool. Because, like, I I spent all this time moving it from Gatsby

to Next. JS, and then I I got about, like, 90% of the way through. I'm like, should I have done this on Astro? I hit, like, five or six, like, one of the those annoying Next. Js bugs Wes it's just like, well, that's just the way it JS. Or, like, I I felt myself screaming, am I the only one that has this problem? Several times.

Oh. That's the worst place to be, by the way. That's the worst you just feel completely like, I must be doing something very wrong. Yeah. Wes I'm the only person And then I also got all kinds of, like, MDX issues all the way down. Like, the

the MDX community is or even the markdown community is just is is very much like the maybe I don't know if it's like the N. JS ecosystem, but it's lots of pieces, and you Scott have all the pieces in in the right order. Otherwise, things break, and that sucks to debug.

Yeah. Tell me. The MDX ecosystem is incredible. So I think it's mostly maintained by Titus. Yep. W Warp. B w o r m. Yeah.

And and he has he has so many packages that I'm pretty sure he has I think he told me he had an automation to manage them, like, just to to manage working through them and, like, updating dependencies and releasing them because there are so many and they're they interlock and depend on each other in what what I'm sure is a beautiful work of art. But, a little intimidating if you don't and this is also a a criticism of of Andreas as well. If you don't know where something is coming from, having a network of packages that work together can be harder to contribute to or debug, if you're new new to it.

But yeah. Like, it's the unified the unified ecosystem. Right? Like, so it's It's Remark. That's the GitHub org. And Yeah. There's Node there's one more. It's for, like like basically, all these plug ins are abstract syntax trees that you loop over and and add exports and remove them and, like, some pretty smart people are writing these things. I wrote a couple myself, and I thought, I think I need a computer science degree. Yeah. Same.

Yeah. It gets rough. You know, the hardest part is that I think they changed the names of some things around too. So then you get blog posts where things are in different orders, and you're like, what which ones am I supposed to use? What's the order? So, yeah. Daniel, how do you deal with stuff like that, given that you're working on a couple of, projects that have big old audiences? You got old documentation. You got people like me and Wes who made tutorials about it five years ago and are still, you know, giving people the raw, like, noncurrent information.

Is there a strategy there to giving people up to date docs and making sure that that stuff doesn't get in the way?

Do you know this is even more relevant today with LLMs providing information to people Yes. Yeah. Drawn from those old tutorials.

So, I mean, the thing is that people and I like, I because I think it's it's true going forward. If you draw a line, even with the creation of of, or the broad adoption of LLMs, and you say, like, now going forward, if you're going to change your APIs, the consequences are gonna be a lot worse than they have been up until now. Because up until now Mhmm. It's just been tutorials in your docs. That's a limited subset. But now people are learning from LLMs. People are having LLMs write code their entire thing. So it's not just that they Yarn reading tutorial and then starting to try it out and noticing immediately that something isn't working. No. They are having an entire project built on the assumption that that's the API.

I think, basically, you have to be very conservative from this point onward about changing any API.

And therefore, you have to be right the first time or you have to, when you change the API, you have to change it in such a way that you have a, forward and backward compatible approach. So for example, you'd you'd very reluctant to change, much more to add.

So for example, if you have a an option and it's a Boolean, now it also might have a string.

And, you know, now it might also have an option. And, you know, but it's gonna handle all the the Those, like, the Vercel cases.

Very reluctant to remove them as valid valid options.

So from my point of view, I'm also looking at this from a Nux two to Nux three move. And it was the most painful migration you can think of because it was it was rewritten. The framework was rewritten, so it was not a a move. Also, the framework had to be rewritten. So that there were there were good reasons for for doing that, but at the same time, it was insanely painful. And I know there are people who don't use Nuxt today because they experienced that and thought Yeah. There's no way I'm ever risking that again.

So right now, we're we're well, actually, for quite a while, we've been on the verge of releasing Nuxt four. We're we're actually rely awaiting for the the major release of Nitro so that we don't have two major bumps in a row, and that's delayed us a bit. But all the breaking changes have been done in Nuxt, and you can actually opt into them with a a single flag.

And my whole my whole aim for that this version, bump, major versions in Nuxt are going to be totally.

In other words, they're only about breaking changes, not about features.

So which I it doesn't really play well with the whole hype driven development. And people are you know, it's it's easy to say, hey. What's new with Nuxt four? What what are the great new things that it's gonna offer? I'm afraid it's only going to offer break breakage. That's that's it.

But that is the solution for you on that. Oh, tell me. You give your devices or your your, feature releases fancy nicknames. This is the Avocado release. This is Nuxt Avocado, and it's incredible.

But it still can be Scott there. It's just got a a fun name. You can get a little Scott, I think the first one might be Tolinski release. That's a great idea. The t zero release. Off the tongue. Yeah. Everybody has no problem saying it or spelling it. Yeah.

We're gonna have the t zero stuck. That's gonna that's gonna be the new thing with nuts.

Oh, yeah. I'll take it. But, basically, I I'm spending a lot of my time thinking about about this, about breakage, and about how to reduce it, and how to enable people to opt in early to it, and how to, provide whether code mods or good error messages or warning logs to help people do stuff like linked docs.

You know, there there's a lot of a lot of DX to be done on this kind of edge, which otherwise would be really, really unpleasant. And I'm not saying that we've got that right so far, but I I really want to nail it. What I'm just curious why the design of everything in

the Vite, Nuxt, Un. Js, this whole ecosystem, all the stuff Ant Foo does, it seems like everyone's, like, really good designers.

The the I'm just looking at the Nuxt website, and this blue and green, it makes me wanna just use this framework so much. Yeah.

Is is there somebody who works on that, or is it just a general good taste?

Lea lean in, Wes. Lean in to what the colors are telling you. Blue is blue is my color, man, so it's kill it's making me wanna come in.

So I think there's no one consistent thing. So Node, Anthony Foo is incredible, and his design sense is just is pure self. He is just has an incredible design sense. And so when whenever he creates anything, it it it is just great. And that that's him.

Yeah. There's a lot to learn from him about a lot of different things, but that is definitely something.

Some of the other things like, like Vite and Vite had an amazing website for quite a long time. It's been recently redesigned as part of Void Deno, the company.

And, actually, the designer who did the Vit website also did the Nuxt website.

Mhmm. That was actually when he was working at Nux Labs. He, created I I believe he was the one at the time he designed it. Do you know do you know his name? The Nux website. The Nux.com website. His name is Vercel, and I think he is but on on social media, I think you'll find him as the r moon.

If you're on blue sky, it's r-moon.bsky.social.

Mhmm. And I think it's very, very similar on Twitter.

Arman, got him. Oh. A freelance designer available for projects.

Get on this, folks. Wow.

So there you go. Rodriguez, that's his surname. Yeah. Awesome. I was I was wondering that. That's good. Thank you. But, I mean, that's that's not the whole it's not the whole ecosystem. This is one guy. But but he has he has a lovely, lovely design sense. I I will say that there are some other designers in the in the ecosystem who just produce some lovely stuff. I've got to say, it transforms. You can write a you can write great code, really solid code, does exactly what you want, but someone puts makes a button that has a shiny edge, and goodness me, it it totally changes it. I want to click that shiny button. I don't know. It's I just my lizard brain or something like that. You know, it's what the the fact that it's good tech is is great, but it doesn't take me all the way there. I Node need the be the shiny button. Totally. It's great. We didn't talk too much about Vue, which I think people are gonna be mad about because they always say, can you please talk more about Vue? I'm I'm just curious about your your opinions in general. Like, why

is Vue awesome? Or I assume you're a a large Vue proponent.

I am. I love Vue.

Both of you. But, the, that was a joke. That was, really, that was that was that was a joke. It was not not a very good joke, but, you you you you you joked.

You chose you chose not not to laugh.

Right. Yes. That that that is there was no there was no impulse to laugh. It was, it was just, an experience.

So there there are several things that you can look at in terms of a framework like this. So one is your experience as a developer in writing it. What is it like? And I think there's some great things about Vue there. So the Vue single file component, if you use that rather than JSX, is a very ergonomic way of, of writing because you're writing a bit which is HTML, a bit which is Big fans of that. We're, we're a CSS. Website over here, so we love that.

It's it's great. So I I think I particularly think it's it's really good for people who are new, who don't who do not have they not coded in a JavaScript framework before.

And you can say write write some HTML here for me. Yeah. Write some CSS for it. Now, of course, these days, maybe it's all tier one CSS.

But I think one of the reasons people have, love tier one CSS so much is that, you know, in a React world, the alternative is, you know, a CSS file, like, like, alongside it. It's not even in the same file. You lack type safety in terms of your classes, for example. Whereas, you have all of that in a VueSFC type safety in your classes if you're using modules or even Scott styles. And so you have a lot of really nice, tooling alongside these three primitive languages of the web. So I I think that is a very nice thing. One thing I I really like about Vue is and someone asked me the other day why I thought that Evan was so good at creating projects.

Because if you look, he obviously created Veet. He created Vue.

I think there are a couple of things there. I think one is he is, willing to reconsider things.

So he's not satisfied exactly. So Veet, for example, had a Leo totally rewrite.

Oh, this is my cat. You'll have to see my cat. Alright. Yeah. But she won't let me talk. I'm in the

head. She's Wes, yeah.

Here JS cat. This is Barley.

Wow. She is very, sweet, but she does demand to be fed when the occasion demands.

Yeah. And so Veet had a full rewrite, really, totally changed its approach and how it worked.

And Vue has seen several of those. Actually, in the previous minor release, there was a total rewrite of Vue's reactivity system.

Can you imagine that? In Node And there's another one coming. Breaking it. So There is a a library created by, Johnson, Chu, who was the author of or is the author of the, language tooling for Vue.

For goodness sake.

I had to move my dogs in the into my house. Yeah. Because they were barking right before we were recording this. They're just, like they're guaranteed the moment you press record.

So Johnson created the, like, the Vue language tooling in in Versus Node, also a language server which works in Vim and JetBrains and so on, and and also powers, other languages like Astro. He abstracted it away into a core library.

And, he created something called alien signals.

Actually, it was originally called native signals.

And, there was a big firestorm on Twitter that came for him with people saying, how dare you? This is not the Native Signal implementation proposed by proposed to February.

Yeah. And

he was really not meaning he wasn't pretending that it Wes. He wasn't in his mind that that's what it meant, but he renamed it, alien signals. And it it powers I think he needed it for some of what he was doing with editors.

And it Node, has been brought into view, and it is, as I understand, the fastest signals implementation of of any that are out there at the moment. And so this is about to land probably in the next few minor.

And I think that that kind of thing, like chasing faster performance, better implementation, is something that Evan is he he does. And I think that is another thing I like Vue for, the idea that it is very it's not afraid to rethink things. Svelte also is like that. Right? Because the latest, Svelte release that that moved much more in the direction of, you know, with runes, for example, and exportable stores, those are big changes to happen Yeah. To Svelte. And I I think I I like that in a in a framework, the idea that you're willing to rethink things and move in what you hopefully feel is a better direction. I'm curious.

You said you're a full time open source author.

So how how do you make money doing that? Or or do you?

Oh, yeah. I that is important. So, yeah, I'm a full time open source developer, and I'm sponsored.

So I have, I have a retainer arrangement with a couple of companies. I have individual people and individual companies who sponsor me, and I do a tiny amount of consultancy as well. But one thing that's very important for me is that all of my sponsorships, there's nothing in return.

So, there's no I don't have any kind of prioritization of requests or or anything along those lines. Because for me, open source is about giving.

So the reason I enjoy it and value it is because there isn't a monetary value attached to what I do with my time. So I like the fact that people buy into that and say thank you to me and and support me. But what I'm very much not wanting is a hundred bosses, if I'm that fortunate. I don't have any sponsors.

But what I'm not after is, like, lots of people who are telling me what to do or people who are wanting, you know, prioritize support because that's a different world. You know? That's that's maybe an agency world, but that's Sorry about this cat.

She is extremely insistent. Cat. Yeah. She is extremely insistent.

So, you know, that that's not that's not what I'm up for. So I'm but I'm I'm very, very grateful to be Okay. So my main sponsor is Nux Labs, for example. But by by by no means, my only Node.

And I would be doing this if I were not sponsored.

So if if I didn't if I didn't have I would I would still be it's what I was doing beforehand.

So I'm I'm grateful that I don't have to pursue consultancy to the extent I would have to do otherwise.

You know, I'm grateful that that I that I'm set free in terms of time, but it it is very important to me that that it is not

a Totally.

That it's not a a directive, employment

kind of situation. That you are, like, able to to do that and to be such as like, a force in the community that you can bring enough people on to obviously support you as as a job, but also not have to, like, shill for something or or implement features based on that.

Well, this has been awesome. It's been very illuminating.

It just definitely revealed to me just a lot lot of the confusion I had about some of these things, especially when, like, you get to see just such a big ecosystem that you're not a part of. So it it's been really awesome to to really demystify that. So this is the part of the show where we do sick picks and the shameless plugs. A sick pick is something that you're just enjoying right now. Could be anything, podcast, movie, product, whatever.

And then shameless plug, anything you wanna plug away.

My sick pick is something I I came across recently called Deskpad.

Don't know if you heard of that.

It is a an app on macOS that is becomes a monitor.

So if you have a large monitor, which I I I do, not super large, but a bit larger than if I want to share my screen with somebody, I don't wanna share the whole of it. Yeah. I often just want to share a part of it. Deskpad lets you do that. So you have, basically, can drag windows into it.

They Yarn on that as a window, and that can be the screen that you share. It's like a like a virtual monitor. We were talking about this the other day because I opted monitor. Yeah. I wanna share my screen, but I don't wanna share everything on it. I also I don't wanna share a single app because that's also annoying when I wanna switch between multiple apps.

Exactly.

So, I mean, it's true because, like, Chrome, you're like, you can't Node a tab. I'm sorry. That's not good enough. An app isn't good enough because, you know, you want the pop ups on top of it, or if you're streaming, you want maybe the terminal as well as anyway, this solves all of that. It's free. It's a great app. Thick pick. I'm just selling it right now. Yeah. That's my sick pick.

Dick. And shameless plugs, what would you like to plug to the audience?

My shameless plug.

I'm tempted to say, you know, come here and pick up my cat. No. My my shameless plug is is, of course, on my building called React To Nuxt.

And the idea is it's going to be for React developers. How do you build stuff in Nuxt? You're you're you're skilled React developer. You know how that stuff works. Next. Js is, second nature, but what what do you do if you wanna get going with Nuxt? We'll be starting this, it's it's currently just sign up for to be notified. But if you, if you're interested, I'm gonna be be starting to produce videos and stream them out to a early cohort.

Nice. Who will all give me feedback, hopefully, and, keep me going in the right direction. So that's coming soon this year. So we'll we'll put a link to that in the show notes. The domain is react-2-nuxt.com.

You can sign up with your GitHub on there. And, sick. I'm really looking forward to that.

Well, thank you so much for coming on. That was awesome. Glad we could finally and finally chitchat. This is really fun. Anything else to add, or should we wrap it up? It's been such a pleasure. Thank you for having me on. It's been a lot of fun. Awesome. Alright. Thank you.