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

Wes and Scott talk with Daniel Roe about Nuxt and Nitro, demystifying the UnJS ecosystem, serverless deployments, open-source sustainability, and the future of full-stack web development. Show Notes 00:00 Welcome to Syntax! 02:52 Daniel’s work with Nitro Nitro 06:01 What’s the connection between Nitro and Nuxt? Nuxt 09:23 What makes something an UnJS package? UnJS 12:55 Nitro’s built-in features 18:21 What would Daniel use to build an app today? Cloudflare Vercel Netlify 28:01 Brought to you by Sentry.io 28:36 Nuxt and SST SST 32:25 Nuxt vs. Next.js in 2025 Next.js 40:06 Keeping docs up to date 44:46 Who is behind the fantastic design of the Nuxt website? Anthony Fu Rmoon Vite 47:27 Why is Vue awesome? Vue alien-signals 52:47 How do you make money in full-time open source? 55:32 Sick Picks + Shameless Plugs Sick Picks Daniel: DeskPad Shameless Plugs Daniel: React to Nuxt Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Welcome to Syntax. Today, we have a great one. We're talking Nuxt and Nitro with Daniel Rowe. 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 UnJS 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.

• 0:27Speaker 01

  It's a pleasure to be here. Thank you for having me.

• 0:30Wes Bos?

  Yeah, yeah, we, uh, this was by popular demand. We've had a bunch of suggestions over the years to have you on. And, uh, on Blue Sky recently, everyone's like, "Have Daniel on, have Daniel on." And it's funny, like, we crossed paths at one of the conferences. What conference was that? A couple of months ago? GitHub Universe. You were at that one as well?

• 0:51Speaker 01

  That's right. Yes, absolutely. There was another, another conversation I had with someone at the Syntax meetup that yielded a ski trip. It was, uh, 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 Syntax FM meetup, uh, in your, in your city, or at a conference, you should just go. And, uh, who knows, who knows what will happen. Skiing.

• 1:16Wes Bos?

  That's hilarious.

• 1:17Scott Tolinski?

  We filled that pizza place. There was, like, a good amount of people in there. We, we just, uh, just totally kicked everyone out, pretty much.

• 1:25Wes Bos?

  Brought all the devs and San Francisco together.

• 1:28Speaker 01

  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?

• 1:38Scott Tolinski?

  Well, I, it's, it's going to actually make me not 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 is, Scott, how, you know, does this hold up to the real thing?" And it's like, "Yeah, it's not really close." But it was still delicious.

• 2:04Wes Bos?

  Scott's from Michigan, so he knows the legit stuff. Yeah, it was good.

• 2:07Scott Tolinski?

  Yeah. Yeah, it was good.

• 2:09Wes Bos?

  All right. So, Daniel, introduce yourself. Who, who are you? What do you do? All that good stuff.

• 2:14Speaker 01

  I'm a full-time open-source contributor. So I lead 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 it in January 2024, I think, just after the release of Nuxt 3. I also have some other open source products I'm involved in, but before that, I really had a totally, probably a totally random career path, not one that you would expect would end up in full-time open source, which is what I'm doing now. But yeah, so I've done lots of different things.

• 2:53Wes Bos?

  That's awesome. And you also work on Nitro, which is the like server toolkit. It's part of UnJS?

• 3:00Speaker 01

  Exactly. So Nuxt is a bit like NextJS, but for view. So it was released the day after it, back sometime, 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 will be melodic. It will be incredible. They grew up in the Pyrenees, which is where the mountains of the Nuxt logo comes from. So very, very homebrewed. But we rewrote it totally from scratch for Nuxt 3. And which was, by the way, a very interesting experience to do on an open source project.

• 3:42Speaker 01

  I don't necessarily recommend it, but one of the things that we did was rewrite it for a serverless world. And for the idea of a potentially non-node world. So what about other runtimes? At the time, really, it was only Cloudflare. Since then, we've had Bun and Dino and, you know, who knows? In doing that, we rewrote what was originally, we called it Nuxt Sigma. And Nuxt Sigma was our rethought Nuxt server. And then this part of the whole process, we decided, actually,

• 4:15Speaker 01

  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 always think personally that it might take longer 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 Tanstack Start, Solid Start, Analog, which is an Angular meta framework. And I hope it will power others because a lot of us meta framework authors and even people

• 4:59Speaker 01

  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 runtimes and rather than reinvent these things over and over and over again, it's better to have a common base where we all pitch in and can talk about our goals. So that's what Nitro is. It's the brainchild, I should say, of Puyia Parsa, who was the previous team lead of the Nuxt core team and who now spends, has time focusing on this UnJS 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 hope that's what they are.

• 5:42Scott Tolinski?

  Yeah. Yeah. So that answers a lot of my questions, like what came first? Was it like Nitro that came first and then Nuxt? But it seems like, like you said, it was originally Nuxt Sigma. And you mentioned UnJS being this collective of different compatible packages and various things. So we have Nitro, which is part of UnJS, but how, what's the connection there to Nuxt? Or is there a connection?

• 6:09Speaker 01

  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 UnJS who have nothing to do with Nuxt. The UnJS libraries are used in lots of places that are not related to Nuxt. For example, they're used in Tailwind CSS. Jit is used to run, to pass the Tailwind config file for a specific purpose. It's something we needed also. So we, you know, it's used to pass the Nuxt config file, like to execute

• 6:52Speaker 01

  TypeScript, CJS, MJS, all these different possible extensions in a straightforward way without any dependencies. And so it does that very well for Nuxt. It does that for Tailwind and hopefully in other places too.

• 7:06Wes Bos?

  So many. The the whole UnJS ecosystem is is so cool. I did a talk at a conference a couple of months ago about all these different runtimes, you know, like we have, you said, like there's Bun and Dino, but then there's there's Cloudflare. And like Cloudflare a couple of months ago announced like 98% Node.js compat, and it's because of one of the UnJS 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 you look at Tansack Start, small

• 7:49Wes Bos?

  team of developers are able to create something that rivals NextJS because they're like standing on these massive projects like like Nitro.

• 8:02Speaker 01

  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 should know that, but I'm not sure I do.

• 8:20Wes Bos?

  I'm not, but we get it. It's the do one thing and one thing well, right?

• 8:25Speaker 01

  Yeah, and I think, you know, there's so many projects that do this well these days, like Veet, 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 Veet. And, you know, I think when you see that, when it's like maintainers and packages, libraries, it welcome collaboration and contribution 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, TanzStack Start hopefully is able to get going a lot faster because they don't have to reinvent the wheel.

• 9:11Speaker 01

  Hopefully that means they can also give it their own flavor, you know, the router and, you know, the amazing stuff that Tanz is doing with types and, you know, and make something that's very cool very quickly.

• 9:23Scott Tolinski?

  I'm wondering about with UnJS, like what makes something an UnJS package specifically, rather than just like a miscellaneous node or JavaScript package?

• 9:34Speaker 01

  That's a good question. And I mean, I should say that the best person to talk about that would be Pooja.

• 9:40Wes Bos?

  Yeah, I've been DMing with him. We're gonna have him on because he's next level.

• 9:44Speaker 01

  He is, he's great. He is great. I think the kind of things that we look for are things that are universal. So anything that is highly specific to node, for example, is probably not an UnJS package because we want something that will be renable everywhere. That doesn't mean it can't have a like a specific node implementation, but we use the winter CG now renamed to a slightly different name. We use the sort of universal keys for the different runtimes, 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 do try for things to be universal. I think there's a strong focus on trying to reduce the number of packages.

• 10:26Speaker 01

  So I, for example, have currently three font-related packages in UnJS. And actually, I'm going to try and merge those into a monorepo because it feels like that's starting to get a little font-heavy. So things that are, that somehow 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 something that can be used by like a font integration. And I think another good question would be, is this an essential building block for a framework? Might be another, another thing.

• 11:08Speaker 01

  So I think the idea of something being essential or a key building block for building other things on top of, that, that's what I would say. But obviously, Puyo will be, he'll, he'll give the, like, the full, full and authoritative answer on that.

• 11:22Scott Tolinski?

  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?

• 11:33Speaker 01

  No, no, absolutely not. Nitro itself does use quite a few of the other packages under the hood, like Unen, for example, was originally created to enable Nitro to build servers for Cloudflare, for example, or other non-node environments. There was even, I think that, I'm not sure even if this exists anymore, but there was even an experimental preset, worked quite well, 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 from the browser.

• 12:05Scott Tolinski?

  From the browser, yeah.

• 12:06Speaker 01

  Which you might say to me, why, why would you do that? And the answer is because it was there. As 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-end. So you get a lot of nice things out of the box. That sounded a lot like a sales pitch.

• 12:39Scott Tolinski?

  No, that's good.

• 12:39Speaker 01

  No, I would, I would, I would definitely use Nitro.

• 12:43Scott Tolinski?

  Yeah. And so Nitro, I mean, like you said, it 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 SQL light, there's tasks and web sockets. What is the goal for including things and like, where do you see it going with what will be included in Nitro?

• 13:02Speaker 01

  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 where things are thoughtfully laid out, where you have adapters to hook into different providers, for example, different authentication providers, different databases. So Laravel gives you everything you need to build 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.

• 13:46Speaker 01

  Because although you could do some things in those server routes, things like authentication, databases, KAVs, there'd be a lot of things that were missing from that. And so I think that's, that's what we're looking for, for Nitro to provide is everything that you would need to build a full stack app. For Nitro to provide all of the backend that you need, and then a framework like Nuxt or Tensdaxdot to provide all of the frontend and backend 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 can, you can always decide, hey, we're not going to handle the web socket stuff ourself.

• 14:29Speaker 01

  We're going to use this provider for that. We're not going to handle the, you know, the notification levels. We're not going to 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 the aim. So the tasks API, for example, it's still quite early days. Platforms like Cloudflare provide Kron syntax, so 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 the tricky thing.

• 15:13Speaker 01

  I mean, the whole concept is no lock-in, right? So the whole thing, that Nuxt is about as well, is we are, you know, built by the community, we are independent. I want to have a great integration story on every provider. And people often ask me, you know, what's the best place to deploy Nuxt? And if my answer is any one provider, then I'm really failing at my job. Because the whole aim is that the thing that 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 always

• 15:56Speaker 01

  easy. Because zero configuration is the best possible experience, for example, but then there's always pros and cons. So for example, some providers 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 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 have to juggle that and figure out what the best choices. But yeah, we want to be working lots of places and working really well. One of the things

• 16:40Speaker 01

  I love is that wherever we have this provider path, I 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 Cloud Nary, 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 whatever. Because extensibility 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 do my own thing, I want to be able to do that.

• 17:25Wes Bos?

  Can I ask you to get a little bit opinionated about some of these 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 going to need a database. There's lots of different ways you can go butter. You could build your own with AWS. You can go all in on like the cloud 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 curious your opinion on these types of things. Because some people are

• 18:08Wes Bos?

  like, oh, just stick with node and it will be fine. And just deploy it to a regular old server. And a lot of people are like, just everything on Vercel. It's a little bit more expensive, but I want to I don't want to have to mess with it. If you were building an app today, what would you choose?

• 18:24Speaker 01

  You're asking if I am building an app today?

• 18:26Wes Bos?

  Yeah.

• 18:27Speaker 01

  So a full time open source main container is building a side project. And that is going to give you a different answer to if I am launching a startup on a thing. It's not a side project is what I'm doing. And it's going to give you a different answer if I'm leading an established team. And so because a lot of these platforms, and I'll go into I'll get opinionated. But it really does. It really does matter. And I know you know this, but like, for example, I love hardening Linux VPS. Like, it's so much fun.

• 18:58Speaker 01

  But the moment you have, I have, I mean, I've hosted websites for clients. I've maintained their service for them. And let me tell you, there is 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 service offerings and the whole concept of that because yes, it might be more expensive, but I absolutely value not being the one on the line when the website is down, right? So picking serverless, just as an example, I almost always, you know, I almost always would, but I pick that because I don't want to have to think about the server because I've been there. I know how to do it.

• 19:42Speaker 01

  I'm fully, fully able to do that, but I don't want to, I don't want to. I want to have, you know, peaceful evenings. I don't, so, so yes, I can absolutely host everything in a $5 VPS and I'd 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'm picking something that lets me scale and lets me 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, zero.

• 20:27Speaker 01

  Maybe you say that's just Daniel because you've not been very successful. Might be the case.

• 20:31Wes Bos?

  That's the hack. Don't build good stuff.

• 20:34Speaker 01

  Exactly. 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 was, 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 want, I just want to know, are people visiting it or not? And so there was no way I'm, you know, paying pro, pro fees for that. So, so I first self-hosted a plausible, which plausible is amazing. And I only self-hosted it after I ran out of their free tiers also. I might have a problem in general with analytics. And then I moved to CloudFlare analytics, which ended up being sort of. More affordable.

• 21:18Speaker 01

  But again, these are the sorts of decisions that a lot of people aren't like, I, I'm, a company's not going to care about that level of cost. Whereas 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, their services. The DX of their dashboards is really quite poor.

• 21:43Wes Bos?

  Yeah.

• 21:44Speaker 01

  And 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, then I'll leave. I feel like I would do that for some things. Why? I'm just going to go on a little rant. If anyone from CloudFlare is listening, please fix this. Every time I click, you know, I have a CloudFlare pages site or something is deploying on GitHub. It says, oh, you know, view logs, view build logs. Okay. I think, oh, I'd like to view those build logs. Click. Ah, 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.

• 22:28Speaker 01

  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 Vessel, they have nailed DX.

• 22:43Wes Bos?

  Yeah.

• 22:43Speaker 01

  Vessel 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 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, uh, you know, I, I, I've, I've used myself for my personal website for years and it's, um, and until recently. Um, and it's, it's been, uh, it's, I just think it's amazing.

• 23:16Wes Bos?

  Yeah. Sorry, one more, I wouldn't think I want to 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. Order the day that you with Cloudflare, you pay with your time, which is is often true. There's just these random things come up. You're like, how do I approach this? And it's always a little bit different, but and then the Versal, 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 well, but of course you pay with your time a little bit.

• 23:53Scott Tolinski?

  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 want to do this. Let me click through it. No, you just never be able to figure out where you're supposed to click or what you're supposed to do. And overall, I, yeah, that Cloudflare dashboard is largely that way.

• 24:12Wes Bos?

  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

• 24:24Wes Bos?

  very responsive to it. So anyway, sorry, go ahead, Daniel.

• 24:27Speaker 01

  No, 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 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 is sort of made up internally until I get that job and, you know,

• 25:11Speaker 01

  do try and do the stuff that I want to do. And I might discover it's a little harder than I, than I think.

• 25:16Scott Tolinski?

  Yeah, right. Yeah.

• 25:17Speaker 01

  But I, I, I wonder if part of it is that. And sometimes maybe it's the consequence of having that, the sort of the velocity at the team level. So Nuxed Hub, which by the way, is not, it's not Nuxed, it's a separate company, also started by the creator of Nuxed 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 use it, 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 his team have built something very similar for Cloudflare for Nuxt and Nitro

• 26:02Speaker 01

  projects, which actually also works like solid start and TansTech start as well. So I wouldn't be surprised to see maybe a rename coming because it feels like it's maybe more Nitro hub than it is Nuxt hub. But anyway, he's building that. And I think that kind of thing, or if someone wants to do this, something more generic, that there's just sort of a wrapper around Cloudflare that basically gives you a better DX, that kind of thing, I think 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 giving you the integration, that it's giving you the seamless flow that Cloudflare isn't. I mean, it's also a very risky strategy because if Cloudflare improved things, people

• 26:47Speaker 01

  might say, not see the need for it.

• 26:49Wes Bos?

  Yeah. AWS has not done that though. That's, we always wonder like, why does AWS not just make a Vercel, you know? Like, why don't, and that's the 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.

• 27:06Speaker 01

  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. So, you know, I mean, I've, I've worked with teams that, that are building next year sites, deploying on Vercel. I have recommended Vercel 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, really, really well. And, you know, the velocity you can get with that is, is worth, worth quite, quite a lot, you know? People say, oh, you know, the markup, it's twice as much or whatever it is.

• 27:50Speaker 01

  But it's not, it's not about necessarily raw numbers. I mean, the There's a lot going in. You paid developers quite a lot as well. It's not a costless endeavor.

• 28:02Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io/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 sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 28:27Scott Tolinski?

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

• 28:32Speaker 01

  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 having me. You've been like, we don't want to have people asking that. They shouldn't get Daniel on the show. And then basically your hand was forced at the last minute by Blue Sky.

• 28:49Scott Tolinski?

  Oh.

• 28:50Speaker 01

  That's the impression.

• 28:50Scott Tolinski?

  No, no. That is not accurate. That is not accurate.

• 28:55Wes Bos?

  The thing about requests 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. Oh, man, we kind of overdid it.

• 29:09Speaker 01

  Well, basically people were asking, were doing the same for us with SST. So people were saying, oh, when will next come for SST? When? Why is next not available for SST? And so it was, it was Dax and I basically had a very long running back and forth on when next would come to SST. But it is, it is now, it's now shippable on SST. So I know it. And SST is, it's, I've seen the sort of back and forth in terms of the underlying infrastructure and how it deploys. And obviously I have a lot of time for Dax's brand of humor, which I find.

• 29:46Scott Tolinski?

  Yeah, yeah, he's a good fellow.

• 29:48Speaker 01

  Yes. So yeah, yeah, I've come across SST, but I guess you were you were saying something about it.

• 29:52Scott Tolinski?

  Oh, no, I I'm just, you know, relevant to our our conversation about.

• 29:56Speaker 01

  Ah, yes.

• 29:57Scott Tolinski?

  Deployment.

• 29:57Speaker 01

  About where you where you deploy.

• 29:59Scott Tolinski?

  Yeah.

• 29:59Speaker 01

  So SST, 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, where 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 of the, we've got so many, we have, I have 30 plus providers, I think.

• 30:24Scott Tolinski?

  Wow, geez.

• 30:25Speaker 01

  And for most of those, Nitro and Nuxt is 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 JSON file with information on how to configure the image optimization. And, you know, this is the, this is the server endpoint, this is how you're going to render stuff. And and everyone has different different output formats. So CloudFlare also needs a JSON with rewrites. So you don't have a dot HTML at the end of your, any pre-rendered routes that you have, for example. So 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.

• 31:09Speaker 01

  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 VSL, it produces a VSL dot JSON. Or Netlify, it produces like an underscore headers, underscore redirects, or they deploy to CloudFlare, it actually also produces a 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.

• 31:52Speaker 01

  So it basically 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 little bit, I think, in terms of the capability.

• 32:25Scott Tolinski?

  So it started, Nuxt started off as 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?

• 32:42Speaker 01

  So for start, so 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 next. But I I do think next is also a good good framework, so.

• 32:54Scott Tolinski?

  Tell me why you hate next JS.

• 32:56Speaker 01

  Exactly. So this is the real reason.

• 33:00Speaker 01

  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 sort 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. We're we're we're smaller than next. I think because view 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 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.

• 33:44Speaker 01

  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 bundler we use, Veit by default, you can use Webpack, you can use RSPack. And so there's lots and lots of scope for customization. We have, even at the level of types or 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 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.

• 34:29Speaker 01

  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. You can spot the thread between the three of these things. We have an ecosystem CI. When we have change, breaking changes, for example, we try now, version three onward. We try and make sure that everyone is, has a backwards compatible, forwards compatible approach. I will go ahead and now open PRS to modules, for example, that solve the problem that they might encounter when we do upgrade to that version in advance. Because it's very much a case of we need to go together. I don't want to break people's projects.

• 35:13Speaker 01

  And thankfully, there are tools like ecosystem CI, which was originally came from the VIT 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 we 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 know, 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 and all of that. It really has a downside.

• 35:52Speaker 01

  The downside is, I mean, if you're, if you, if you are an next JS and you are targeting Vercel, so you basically have like a node preset, which you can run on a VPS. Or you can, or in 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.

• 36:15Speaker 01

  But if any, you have a NUX and we support thirty deployment providers and we support, you know, twenty image providers and we support, you know, so like the number of things we have to support is many, is a lot, it's a lot more. And, and it's not surprising. We are dependent on the community to drive 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 um, yeah, those are four things.

• 36:55Scott Tolinski?

  Yeah, I like all that. I mean, it's such a theme of openness and community and just all those, those things that, I don't know, a lot, you know, some frameworks can feel closed off and this kind of 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 if you use great, so yeah.

• 37:15Speaker 01

  Do you know, we do support JSX. There's, there's some differences. Like you don't use class name, 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 just, but you could write JSX if you wanted. You know, that, that, that site you're deploying to CloudFlower West that you've been spending all that time on. We should, we should talk. I'll, I'll give you a NUX.

• 37:48Wes Bos?

  That'd be kind of cool. Cause like I, I spent all this time moving it from Gatsby to NextJS. And then I got about like ninety percent of the way through. I'm like, should I have done this on Astro? I hit like five or six, like one of those annoying NextJS bugs where it's just like, well, that's just the way it is. Or like, I, I felt myself screaming, am I the only one that has this problem several times?

• 38:17Wes Bos?

  Oh.

• 38:18Scott Tolinski?

  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.

• 38:24Wes Bos?

  Yeah.

• 38:25Scott Tolinski?

  Or I'm the only person using this.

• 38:26Wes Bos?

  And then I also had 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 NJS ecosystem, but it's lots of pieces and you gotta have all the pieces in, in the right order. Otherwise, things break and that sucks to debug.

• 38:50Scott Tolinski?

  Yeah, totally.

• 38:51Speaker 01

  The MDX ecosystem is incredible. So I think it's mostly maintained by Titus.

• 38:57Wes Bos?

  Yeah. V W O R M. Yeah.

• 39:00Speaker 01

  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 manage working through them and like updating dependencies and releasing them. Because there are so many and 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 criticism of, of NJS 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 to it. But yeah, like it's the unified, the unified ecosystem, right? Like so it's,

• 39:43Wes Bos?

  It's remark, rehype and there's one, there's one more. It's for like, like, basically all these plugins 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.

• 40:05Scott Tolinski?

  Yeah, same.

• 40:07Scott Tolinski?

  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 I, yeah, Daniel, how do you deal with stuff like that? Um, given that you're working on a couple of, uh, 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 non-current 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?

• 40:43Speaker 01

  Do you know, this is even more relevant today with L L M's providing information to people. Yes. Drawn from those old tutorials. So, I mean, the thing is that people. And I like, because I think it's it's true going forward. If you draw a line, even with a creation of of or the broad adoption of L L M's. And you say now, going forward, if you're going to change your A P I's. The consequences are going to be a lot worse than they have been up until now. Because up until now. Mm hmm. Uh, it's just been tutorials and your docs. Now, that's a limited subset, but now people are learning from L L M's. People are having L L M's write code their entire thing.

• 41:24Speaker 01

  So it's not just that they are 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 A P I. Uh, uh, I think basically you have to be very conservative from this point onward about changing any A P I. And therefore you have to be right the first time. Or you have to, uh, when you change the A P I, you have to change it in such a way that you have. A uh, forward and backward compatible approach. So, for example, you you're very reluctant to change, uh, 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.

• 42:08Speaker 01

  And, uh, you know, and now it might also have an option and, you know, but it's going to handle all the the backwards. There's like the worst 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 NUX today because they experienced that and thought. 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 NUX four.

• 42:53Speaker 01

  We're we're actually relying, waiting 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 the, this version bump, major versions in Nuxt are going to be totally Semva. 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 4? What are the great new things that it's going to offer? I'm afraid it's only going to offer break, breakage. That's, that's it.

• 43:34Scott Tolinski?

  I have a solution for you on that.

• 43:35Speaker 01

  Oh, tell me.

• 43:36Scott Tolinski?

  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 Semver. It's just got a, a fun name. You can get a little mascot in there.

• 43:52Speaker 01

  I think the first one might be the, the Talinsky release. That's a great idea.

• 43:55Wes Bos?

  The T zero release.

• 43:57Scott Tolinski?

  Rolls off the tongue. Yeah, everybody like no problem saying it or smelling it.

• 44:00Wes Bos?

  The ST zero.

• 44:02Speaker 01

  Yes, we're going to have the T zero stack. That's going to, that's going to be the new thing with nuts.

• 44:09Scott Tolinski?

  Oh yeah, I'll take it.

• 44:11Speaker 01

  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.

• 44:46Wes Bos?

  What? I'm just curious why the design of everything in the Veet, Nuxt, UnJS, this whole ecosystem, all the stuff Ant Fu does. It seems like everyone's like really good designers. The, the, I'm just looking at the Nux website and this blue and green. It makes me want to just use this framework so much.

• 45:08Scott Tolinski?

  Yeah.

• 45:09Wes Bos?

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

• 45:15Speaker 01

  Lean in Wes, lean into what the colors are telling you.

• 45:18Wes Bos?

  Blue is my color, man. So it's killing, it's making me wanna come in.

• 45:23Speaker 01

  So I think there's no one consistent thing. So one, Anthony Fu is incredible and his design sense is just, is pure self. He is just, has an incredible design sense. And so whenever he creates anything, it is just great. And 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 Veet and Veet had an amazing website for quite a long time. It's been recently redesigned as part of Void Zero, the company. And actually, the designer who did the Veet website also did the Nuxt website.

• 46:03Speaker 01

  That was actually when he was working at Nuxt Labs, he created, I believe he was the one at the time who designed.

• 46:10Wes Bos?

  Do you know, do you know his name?

• 46:11Speaker 01

  The Nuxt website, the nux.com website. His name is Vincent. 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. And I think it's very, very similar on Twitter.

• 46:34Scott Tolinski?

  R moon, got him.

• 46:35Wes Bos?

  Ooh, a freelance designer available for projects. Get on this, folks. Wow.

• 46:41Speaker 01

  So there you go. Rodriguez, that's his surname.

• 46:44Wes Bos?

  Awesome. I was always wondering that. That's good. Thank you.

• 46:47Speaker 01

  But I mean, that's, that's not the whole, that's not the whole ecosystem. This is one guy. But, but he has, he has a lovely, lovely design sense. 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, 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 totally changes it. I want to click that shiny button. I don't know. It's, I've just, my lizard brain or something like that. You know, it's what, the fact that it's good tech is, is great, but it doesn't take me all the way there. I now need the, need the shiny button.

• 47:27Wes Bos?

  Totally. 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 just curious about your, your opinions in general. Like, why is Vue awesome? Or I assume you're a large Vue proponent.

• 47:44Speaker 01

  I am. I love you, both of you. But um.

• 47:47Wes Bos?

  Oh.

• 47:48Speaker 01

  The uh, that was a joke. That was uh, really uh, that was, I was, I was a joke. It was not, not a very good joke, but um.

• 47:57Speaker 01

  You, you, you.

• 47:57Wes Bos?

  I missed it.

• 47:58Speaker 01

  It was a joke. You chose, you chose not to, not to laugh. Quite me. Yes, that, that, that is. There was no, there was no impulse to laugh. It was, it was just uh, an experience. So 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. Um, what is it like? And I think there's some great things about view there. So the view single file component, if you use that rather than JSX, is a very ergonomic way of uh, of writing, because you're writing a bit which is HTML, a bit which is.

• 48:31Wes Bos?

  Big fans of that. We're a, we're a skeleton website over here, so we love that.

• 48:36Speaker 01

  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 have not coded in a JavaScript framework before. Um, and you can say, you write, write some HTML here for me. Um, write some CSS for it. Now, of course, these days, maybe it's all Tailwind CSS. But I think one of the reasons people have uh, loved Tailwind CSS so much is that, you know, in a React world, the alternative is, you know, a CSS file 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 view SFC. Type safety in your classes, if you're using modules or even script styles.

• 49:21Speaker 01

  And so you have a lot of really nice uh, 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 view 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 view. Uh, I think there are a couple of things there. I think one is, he is uh, willing to reconsider things. So he's not satisfied exactly. So Veet, for example, had a, a total rewrite. Oh, this is my cat. You'll have to see my cat.

• 50:01Wes Bos?

  All right, yeah.

• 50:02Speaker 01

  But she won't let me talk.

• 50:03Wes Bos?

  I'm into that.

• 50:06Scott Tolinski?

  She's requesting, uh, yeah.

• 50:09Speaker 01

  Here is Kat. This is Bali. Uh, she is very sweet, but she does demand to be petted. When the occasion demands.

• 50:18Scott Tolinski?

  Yeah.

• 50:19Speaker 01

  And so VIT had a full rewrite, really, and 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? And there's another one coming.

• 50:34Scott Tolinski?

  Breaking.

• 50:35Speaker 01

  So there is a, a library created by Johnson Chu, who was the author of, or is the author of the, um, language tooling for Vue. For goodness sake.

• 50:51Scott Tolinski?

  I had to move my dogs 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.

• 51:00Speaker 01

  Uh, so Johnson created that, like a Vue language tooling in, in VS Code and also a language server which works in Vim and JetBrains and so on. And, and also powers, uh, other languages like Astro. He abstracted it away into a core library.

• 51:17Speaker 01

  And, uh, he created something called Alien Signals. Actually, it was originally called Native Signals. And, uh, there was a big firestorm on Twitter that came for him with people saying, how dare you? Uh, this is not the native signal implementation proposed by, proposed to T C thirty nine.

• 51:37Scott Tolinski?

  Yeah.

• 51:38Speaker 01

  And he was really not meaning, he wasn't pretending that it was, he wasn't, in his mind, that's what it meant. But he renamed it, um, Alien Signals. And it, it powers, I think he needed it for some of what he was doing with editors. And it now, uh, 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 Vue 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 view for the idea that it is very, it's not afraid to rethink things.

• 52:22Speaker 01

  Svelte also is like that, right? Um, because the latest uh Svelte release that that moved much more in the direction of, you know, with runes, for example, and exportable stores. Um, those are big changes to happen uh 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 and what you hopefully you feel is a better direction.

• 52:46Wes Bos?

  I'm curious, you said you're a full-time open source author, um, so how how do you make money doing that? Or or do you?

• 52:56Speaker 01

  Ooh, um, yeah, I that is important. So yeah, I'm a full-time open source developer and I'm sponsored. So I have uh 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 um, 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.

• 53:39Speaker 01

  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. Uh, if I'm that fortunate, I don't have many 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.

• 54:07Speaker 01

  Sorry about this cat.

• 54:09Wes Bos?

  She is very persistent cat.

• 54:10Speaker 01

  Yeah, she is extremely insistent. So, you know, that's not, that's not what I'm up for. So I'm, but I'm, I'm very, very grateful to be.

• 54:19Wes Bos?

  Okay.

• 54:19Speaker 01

  So my main sponsor is Nuxt Labs, for example. But by, by no means my only one. Um, 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. Um, so I'm, I'm grateful that I don't have to pursue consultancy to the extent I would have to do otherwise. Um, you know, I'm grateful that, that I, that I'm set free in terms of time. But it is very important to me that, that it is not a.

• 54:51Wes Bos?

  Totally.

• 54:52Speaker 01

  That it's not a, a directive. Uh, employment.

• 54:55Wes Bos?

  That's really cool 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.

• 55:15Scott Tolinski?

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

• 55:46Speaker 01

  My sick pick is something I, I came across recently called Deskpad. Don't know if you've 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, uh, not super large, but a bit larger than, if I want to show my screen with somebody, I don't want to show the whole of it. I often just want to share a part of it. Deskpad lets you do that. So you have, um, basically can drag windows into it. They are on that as a window and that can be the screen that you share.

• 56:21Wes Bos?

  It's like a like a virtual monitor. We were talking about this the other day because I often

• 56:25Scott Tolinski?

  Virtual monitor, yeah.

• 56:27Wes Bos?

  I want to share my screen, but I don't want to share everything on it. I also, I don't want to share a single app because that's also annoying when I want to switch between multiple apps.

• 56:37Speaker 01

  Exactly. So, I mean, it's true because like Chrome, you're like, you can hide 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.

• 56:54Wes Bos?

  Sick pick. I'm installing it right now.

• 56:56Speaker 01

  That's my sick pick.

• 56:57Scott Tolinski?

  Sick.

• 56:58Wes Bos?

  And shameless plugs. What would you like to plug to the audience?

• 57:02Speaker 01

  My shameless plug, I'm tempted to say, you know, come here and pick up my cat. No, my shameless plug is, is a course I'm 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 a skilled React developer. You know how stuff works. Next.js is second nature, but what do you do if you want to get going with Nuxt? We'll be starting this. It's currently just sign up for, to be notified. But if you, if you're interested, I'm going to be, be starting to produce videos and stream them out to an early cohort. And who will all give me feedback hopefully and keep me going in the right direction. So that's coming soon this year.

• 57:47Scott Tolinski?

  So we'll, we'll put a link to that in the show notes. The domain is react-two-nux.com. You can sign up with your GitHub on there and sick. I'm really looking forward to that.

• 57:59Wes Bos?

  Well, thank you so much for coming on. That was awesome. Glad we could finally get you on and and finally chit chat. This is really fun. Anything else to add or should we wrap it up?

• 58:09Speaker 01

  It's been such a pleasure. Thank you for having me on. It's been a lot of fun.

• 58:13Wes Bos?

  Awesome. All right. Thank you.

• 58:14Scott Tolinski?

  Happy to have you.