905: You Should Learn Nuxt!

CJ steps in for Scott and joins Wes to share his experience working with Nuxt, from routing and data fetching to the pros and cons of the framework. They break down the Nuxt ecosystem, directory structure, and how it handles server routes and modules. Show Notes 00:00 Syntax Meetup! 00:26 Welcome to Syntax 01:21 The deal with Nuxt. CJ’s Nuxt Course. 02:51 Why do you like Vue? 04:52 Brought to you by Sentry.io. 05:17 Routing with Nuxt. h3 - The Web Framework for Modern JavaScript Era. Nuxt Guides. 06:12 Built on Nitro. 06:49 The Nuxt Ecosystem. 07:52 API Route Support. 08:15 Nuxt Directory Structure. 09:09 Does Nuxt do too much for you? 11:15 Data fetching in a Nuxt app. 13:25 RPC, Form Actions, Server Actions? 15:00 Nuxt Server Folder Hastle. 15:57 useFetch Hook. CJ’s Nuxt Crash Course. 17:29 Core Modules and Community Modules? Nuxt Modules. shadcn-nuxt. @nuxt/ui. DaisyUI. Pinia. 21:17 Nuxt Hosting. Deploy. hub.nuxt. 23:59 Anything you don’t like? 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:00Wes Bos?

  What's up everyone? Before we get in, we want to tell you that we're having a Syntax meetup in Denver. You're gonna want to come to this if you're anywhere near Denver because it's gonna be a hoot. May 29th, go to syntax.fm/meetup. You can grab your tickets for that. We've got Syntax folks are gonna be there. We've got Sentry folks that are gonna be there. We've got the Vercel crew. We've got the Mux crew. It's gonna be called Dev's Night Out. It's gonna be a hoot, so don't miss it. Welcome to Syntax. Today, we have CJ on and he's going to tell you why you should learn Vue and Nuxt. We had Daniel on, Daniel Rowe, to talk about a lot of his work on Vue and Nuxt. And CJ just put out an absolutely massive course,

• 0:44Wes Bos?

  like almost 12 hours, something like that. What was that CJ?

• 0:48Speaker 01

  Yeah, it was 12 and a half hours if you include the hidden chapter.

• 0:51Wes Bos?

  Oh my goodness. So that's on our YouTube channel, youtube.com/syn-tax.fm. And the idea of this episode is we're gonna kind of run through what Nuxt and Vue is, why CJ likes it, and how all the pieces work. And you're gonna finish this episode. It's a real quick one. You're gonna finish it being like, damn, I'm gonna learn Nuxt. I'm gonna go take CJ's course.

• 1:22Wes Bos?

  So, welcome CJ. How's it going?

• 1:23Speaker 01

  It's good. Thanks for having me on. I am excited about Nuxt. I've been working with it over a month, probably close to two months now, just building with it, learning everything I can about it. And I like it. I've used a lot of meta frameworks. I've used all the meta frameworks. I've built stuff with NextJS and SvelteKit and Solid Start. And I've been messing around with TanStack Start. And right now, Nuxt is my favorite.

• 1:46Wes Bos?

  That's a big thing to say. So for anyone who doesn't know, Vue is the equivalent of React. You probably know that if you're listening to this podcast. And Nuxt is their meta framework for building full stack, client-side, server-side applications with Vue, both on both sides. Similar, you can say it's like the NextJS of Vue. Is that fair to say?

• 2:12Speaker 01

  Absolutely, yeah. And the similar thing about it is because it's also built on top of Vue Router, which is the routing tool that's used in the Vue ecosystem, a lot of people will choose Nuxt, even if they're only building a single-page application. And so, yeah, Nuxt is their meta framework. You can build content-based websites, single-page applications, server-side rendered websites, multi-page websites, anything in between, and it supports the similar idea of like, these routes could be pre-rendered or server-side rendered, but these routes are always run on the client. Or you could build a fully pre-rendered website. So, yeah, it supports all the different rendering strategies.

• 2:46Wes Bos?

  Like a full static, yeah.

• 2:48Speaker 01

  And you get to use Vue to build out your pages.

• 2:51Wes Bos?

  That's awesome. And why do you like Vue? Why is Vue better than Svelte or React or anything like that?

• 2:59Speaker 01

  Yeah, it comes down to personal preferences, but I find that when I'm building things with Vue, I have to write less code than I do with React. They have a lot more things typically that are just built-in, that I don't have to reach for another library for.

• 3:13Wes Bos?

  Yeah.

• 3:14Speaker 01

  And a lot of times, things are just slightly more intuitive. Now, I guess if you've been in the React ecosystem for a long time, it doesn't matter if it's intuitive because you've just learned how it works, so you know how React works. But I find that if you just use your web development brain and you come in fresh to Vue.js, a lot of things just kind of make sense out of the box. There's no like, rules of hooks. You don't have to learn about functional programming or immutability. You can kind of just use what you know about web development, and then it just makes a lot of things easier. So, that's why I like it. Yeah.

• 3:46Wes Bos?

  It seems to me like the very same like, excitement that I got when I first used Angular, like the very first Angular, coming from the mess of jQuery that I was writing. And then, I remember the very first time I used like, data binding in Angular, you know, like you have an input that was, and there, at the time, was two-way data binding, which is apparently a big no-no these days. But I had two inputs, you could type in either one, and then it was mirroring it to like, a paragraph tag on the page. I was like, holy smokes, this makes so much sense to me, and is so exciting.

• 4:21Speaker 01

  Definitely. And when I first picked up Vue JS in 2015, 2016, that's basically how it was kind of advertised. It was like the happy middle ground between Angular JS and React. Like, because even back then, they were using the virtual DOM, but they adopted a lot of these directives that you had in Angular JS, like v4 used to be ng4, or vif used to be ngif. So it's kind of like, you get all of these niceties of like magic HTML things, but it's performant, it's built on top of the virtual DOM, kind of the best of both worlds.

• 4:53Scott 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.

• 5:17Wes Bos?

  All right, let's talk about routing, because I honestly think if you're building a web app today, you have to start with the router, because all of these things know about your data, they know about the pages, they know about all the endpoints. The router is like the nucleus of a web app. So Nuxt has a router, I'm assuming?

• 5:35Speaker 01

  It does. And so it's actually built on top of Vue Router. And so, I'm gonna, I'm gonna sound like a broken record, but this is one of the other reasons I like the Vue ecosystem. Things are built in, and the Vue Router comes from the core team. And if you're not using Nuxt, you still would choose Vue Router if you were building like a single-page application. But Nuxt builds on top of Vue Router to give you file-based routing, and then also like server-side rendered routes. So it uses Vue Router, it allows you to do like programmatic navigation. They have built-in components like the Nuxed link, which allows you to create your links within your app that behave as single-page application links once they've been hydrated and rendered on the client side. And then it supports file-based routing, because it's also built on top of another tool called, or another framework called Nitro.

• 6:18Speaker 01

  And so when you had Daniel on, he talked about Nitro quite a bit. And actually, that's one of the ideas they had when they were building out Nuxt, is like, they're doing all of this stuff that could be very useful to other meta frameworks as well, not just for the Vue ecosystem. So they pulled out those pieces and that became Nitro. And so now, if you look at Tanstack Start, it's built on top of Nitro. If you look at Solid Start, it's built on top of Nitro. So all of those pieces that those frameworks now get to use that make them, that allowed them to hit the ground running, actually came from the Nuxed ecosystem.

• 6:50Wes Bos?

  The, the whole NUX ecosystem is building some of the best stuff out there, right? Like, all the on JS stuff comes from people that were from the Vue, the ecosystem. Obviously, Veet is from the guy that made Vue as well. And it just seems that all of these new tools where it's just like, ah, yeah, that makes a lot of sense. And oh, that you can deploy this thing to, to Node or to Cloudflare or to Vercel or to Serverless, you could put it anywhere you want. It just works really well and just it, it's just a joy to use a lot of these new tooling. And that's honestly why I've been wanting to build something in NUX because like,

• 7:34Wes Bos?

  literally everything else I'm, I'm using is, is coming out of this ecosystem. So probably they got this part figured out, too.

• 7:42Speaker 01

  I think so. And so that, like I mentioned, that gives you file-based routing. So you can create Vue files, which specifically become pages in your app. They also allow you to do like dynamic params, but they also support API routes. So in your NUX app, there is a folder called server and you define all of your API routes in there. And those are actually built on top of a framework called H3. And Nitro is built on top of H3. But H3 was one of the first like runtime agnostic, kind of like express replacements. And so when you're building out API routes, you get to use those functions. When I mentioned the server directory, that's one of the other things that reminded me of what I like about NUX is this idea of conventions. So if you go on to the NUX documentation, then click on docs and then guide.

• 8:27Speaker 01

  There is a section called directory structure. And this lists out every single directory that you might have in your NUX app, but each one of those has its own documentation. So it has this idea of conventions where like, if you put something in the compositables folder, It's going to be something that is available throughout your app. If you put something in the components folder, it's available throughout your app. All of your pages go in the pages folder. So just like all of your API routes go in the server folder. So this is another thing I like about Nuxt is their conventions. It's not the Wild West. Like you could come across a NextJS app where they just put stuff anywhere they want. And they can, because it's just JavaScript. But I do like that Nuxt kind of has some of these conventions where any one of these folders has the specific types of things inside of it.

• 9:10Wes Bos?

  And yeah, that little bit of like magic is something that I often like. Are you, would you say you're a fan of magic? Or where's your line for how you like, how much magic you like?

• 9:20Speaker 01

  I love magic. I understand people that don't, right? Because at a certain point, it could feel like I have no idea what's going on because everything is handled for me. But I have used Vue long enough, I've used Nuxt long enough, that there are so many things I don't want to have to do. I don't want to have to do them by hand every single time. So I appreciate the magic that they give me because I know what is happening under the hood. But I completely understand that perspective of you come into this and you're like, where is all this stuff coming from? Why is there so much magic? I like it because I don't want to have to write all that boilerplate. And if you understand the magic, like if you do understand where all this stuff is coming from, then you can extend it. But that is a learning curve, right? If you do want to go in and kind of change the behavior of how some of these things

• 10:03Speaker 01

  that are magic, you are going to have to do some research to figure that stuff out.

• 10:06Wes Bos?

  In a lot of cases, you can also still duck out and get access to everything. I'm just reading the docs for the actual middleware here, where it's like, well, sometimes you do want access to the raw request and be able to do that type of thing. So it's nice to have those escape patches. Waku is similar to that as well, where it's, things just work when you get fired up. But if you do want to do some specific things, you certainly can duck out and write your own middleware, write your own plugin for it.

• 10:38Speaker 01

  Do you know if a Waku is built on top of Nitro? Or is it Vinci? Is Vinci built on top of Nitro?

• 10:43Wes Bos?

  Um, it's not. It's just, it's V and Hano all the way down, which is probably one of the only ones. Because it seems like a lot of these other ones are built on Vinci. And and Nuxt, or sorry, not Nuxt, Vinci, H3, all of these unJS parts, I can't even remember. I did a whole hour-long talk on like all these like standard pieces and and writing like standardized modern server JavaScript, and I still can't even remember all of them.

• 11:14Speaker 01

  Yeah.

• 11:16Wes Bos?

  What about data fetching? So how does how does that work when you're building a Nux app?

• 11:20Speaker 01

  Yeah, so i- if you want to define calls to your database or things that happen on the backend, you're going to write those inside of your API routes. And so those go in the server folder in the API folder. But any API route you have defined in there has automatic type safety using their built-in composable called usefetch. So for any endpoint you define inside of your view page or view component, you can say usefetch. You're going to get type completion as to what endpoints are available, and it gives you type completion as to what the return type is as well. But one of the beautiful things about usefetch is it's isomorphic, right? It runs both on the client side and on the server side. So you can write one bit of code that awaits a call to usefetch to get that gets back your data. When that code

• 12:02Speaker 01

  runs on the server, that's going to server-side render the page. If you arrive at that page via like a client-side navigation, that request to the API will actually happen on the client side. And Nux is smart enough, because of Nitro, to see that if a request is happening to an API endpoint inside of server-side code, it just invoke it invokes that function directly in your backend. So your API routes can actually call each other, but it's not it's not like doing a network hop. It literally figures out, oh, I'm already running on the server, so I can actually just invoke that other API function.

• 12:35Wes Bos?

  Okay.

• 12:36Speaker 01

  Yeah.

• 12:37Wes Bos?

  I was going to ask that because we'll talk about like like React server components equivalent in just a second. But if you want to make custom functionality available, you stick it in the API route. But like, are you are you literally fetching from the same server, you know? And then that's that's not the case. It just calls the function instead.

• 12:57Speaker 01

  It calls the function, exactly. And then they have utilities to include the incoming request headers, right? So let's say one API route needs to call some other route that is authenticated. If that request only happened on the server, it would include all the user's cookies and everything else. So if one route needs to call another, it can call the I forget the name of the hook, but it's like useheaders or getrequestheaders. Attach those and then the request internally appears as if it came from a user because it includes all their cookies and everything else.

• 13:24Wes Bos?

  Okay. And another thing I asked you before we started recording is like, is there the equivalent of like a RPC or React server actions or form actions, basically being able to define a server function and call that from the client?

• 13:42Speaker 01

  It's purely through their use fetch composable. So they don't have form actions or server actions. There is a community module where they've tried to figure out how to make these, but it doesn't exist in the core Nuxt just yet. Essentially, if you want to do data fetching, you define your API endpoint, you use the use fetch composable to call it, and that kind of gives you the RPC because you have type completion as to what the API endpoints are, you get type completion as to what's coming back from them, and those can be called from the client. So yeah, no actions, but this combined use fetch composable with APIs gives you an in RPC-like experience.

• 14:18Wes Bos?

  Oh, yeah. I bet we'll probably see something similar to that in the future. Like Svelte just announced they're doing asynchronous Svelte, which is setting up so that we will be able to get both React suspense-like things in Svelte, but also a bit nicer of RPC. Svelte currently does have the ability to like submit from the client to the server via, I think they're called form actions in Svelte. Is that right?

• 14:46Speaker 01

  Yeah, actions and loaders. Yeah.

• 14:48Wes Bos?

  Yeah. Yeah. But right now, they're just, they're tied to a page at a page level. So I bet that the new sync Svelte stuff will allow us to put those anywhere else.

• 14:59Speaker 01

  Yeah. I would say if I had one thing to complain about for Nuxt, it would be the fact that all my backend code has to go in that server folder. So working in a framework like SvelteKit, your loaders can be defined right next to the page. And so that's, that's a nicer developer experience. You don't have to jump around between your code bases, just the file right next to it. In Nuxt, it's in that server folder. So if I had to complain, that's the one complaint, is I do have to bounce back and forth between my pages folder and my server folder. So that can be a little bit cumbersome.

• 15:27Wes Bos?

  Yeah, it is nice to be able to like have a folder for a component and you can you can put your tests in there. You put your CSS in there, you put your client side code, your server side code. You put everything in that one folder and that makes it nice and portable. Because you know where you're working and also if you want to move that functionality, what it looks like, what it does, how it acts on the server. You can you can sort of bundle that all up into a single component or folder and move that to another project.

• 15:57Speaker 01

  Yeah, and I will say if you want to see some of this stuff in action, you don't have to commit to the 12 hour video. I also made a NUX Crash Course video. It's about 45 minutes, but I will say if you skip to the 16 minute mark in the NUX Crash Course 2025 video I released, it shows you this this use fetch hook. And one thing I'll point out really quick is the how easy it is to get server side rendering and also a client side request of that data with just three lines of code. Next JS with server components comes to mind because if you want that experience, you're going to have to duplicate some code, right? So for server side render, you can await that request to your database or API or whatever else at the top level. And that will suspend that component from rendering on the server side.

• 16:42Speaker 01

  Once the data is available, it just ships back to the client what's needed. But what if someone needs to go to that page and they were already on your site? Right now, the only way to do that is to have in in Next JS and React is to have a client component that has like a use effect with a with a fetch or maybe use something like tan stack query. So there's a lot more plumbing you have to do if you want to get that experience where if I go directly to the page, it's server rendered. But if I navigate here and I'm already in the app, that should be client rendered. With use fetch in Next JS, it's super simple. They have an option you pass in there called lazy. If you set lazy to true, it'll automatically allow you to navigate between all of these pages and then show a loading spinner if that request is happening on the client side. So they've figured that out.

• 17:26Speaker 01

  It's still very cumbersome to do in my experience in Next JS.

• 17:29Wes Bos?

  And let's talk about these modules or core modules. So let's say you want to build something and you need auth. Sort of the reason why a lot of people reach for the React ecosystem is there's there's a module for absolutely everything. And I believe that exists in the Vue and Nuxt ecosystem as well, right?

• 17:49Speaker 01

  Definitely. And there are certain NPM modules that you could just install. It doesn't necessarily have to be next specific.

• 17:55Wes Bos?

  It doesn't have to be the next version. Yeah.

• 17:57Speaker 01

  Especially ones that are based on web standards because it's built on top of Nitro. If you're thinking about like these backend things. But I will point you to the Nuxt docs. So if you go to the Nuxt docs, click on at the top integrations and then modules. Just search for the thing that you want to exist. So for instance, if you search for auth, you can see there's a plugin for kind auth. There's like a hosted auth service. There is side base Nuxt auth. So that actually uses auth JS under the hood. This page on the Nuxt documentation has community modules, but also like core modules too. So any kind of thing that you would want to do, someone's built a module. And the way that you install these is there's like a nuxi add command. It automatically creates a config file for you if that particular module needs it. But in the course, I show how we use the ES lint module.

• 18:42Speaker 01

  So this automatically gets you up and going with a ready, ready to go, well-designed lint config. I also use the icon plugin. So this uses iconify, which lets you pull from like thousands of icons. I also used the color mode plugin, which gives you automatic like mode and dark mode detection that you can use to like plug into like a theme switcher.

• 19:05Wes Bos?

  Yep.

• 19:05Speaker 01

  There's an images module similar to how you, how next JS has their like image optimization module. So like I said, just, just go here and search and someone's probably already created a module that just makes it immediately available to use inside of Nuxt.

• 19:19Wes Bos?

  And for all the like, you think, okay, I'm building an application, right? You have your modules and whatnot. There's also equivalence of like UI components, data stores. The Vue ecosystem is like mature, right? There's equivalence and in many cases, better versions of what we have in other frameworks.

• 19:41Speaker 01

  I would agree with that. And I think same thing, pick any UI framework that you use with React. You can find an equivalent that's well supported and has a good community in the Nuxt ecosystem.

• 19:50Wes Bos?

  Even like a ShadCN.

• 19:52Speaker 01

  Yeah. If you search for a Vue ShadCN, they're making it happen. And there's a ShadCN-Nuks plugin that automatically sets it up. So it's usable inside of your Nuxt app. And of course, there are UI frameworks like specific to the ecosystem. There's a framework specifically called Nuks UI that looks really nice. In the course, I actually use Dazey UI. So Dazey UI is just a Tailwind CSS framework. So it can be used with anything and I was able to use it inside of my Nuxt app.

• 20:19Wes Bos?

  Awesome. And Syntax sponsored this one. How do you say it?

• 20:23Speaker 01

  Pinia.

• 20:24Wes Bos?

  Yeah. That's a data store, right?

• 20:26Speaker 01

  Exactly. So I didn't get to talk about that, but that in the world of Vue JS, if you need global state management, if you need a store, everyone reaches for Pinia. There's not 20 choices. There's not a lot of bike shedding around that. If you need global state, we use Pinia. And in the course, I use Pinia. There's a Pinia Nuks module that gets everything set up for you. And it's really nice because in the world of Vue, they moved to this idea of the composition API, where you have all of these small functions similar to hooks, but without all the rules of hooks in React that let you create state variables, create reusable state functions. And Pinia just works on top of those as well.

• 21:06Speaker 01

  So if you're already used to all of the compositables in Vue, like creating state variables or creating effects, you just use those inside of a Pinia store. But now that store can be imported and used inside of any component.

• 21:17Wes Bos?

  And let's talk about hosting. I think Vue and Nuxt is like the only framework, or the only major framework that doesn't have a massive company behind it, you know, like Angular has Google, React has Vercel and Facebook. Svelte, I could know, Svelte doesn't have any, any, any big company behind them as well, but Vue and Nuxt doesn't, right?

• 21:41Speaker 01

  Yeah. I mean, and technically Svelte hired Rich Harris, Vercel hired Rich Harris, but still Svelte is not necessarily owned by-

• 21:48Wes Bos?

  No, Svelte is not a Vercel project. They're just paying for him to work on it, which is really cool.

• 21:54Speaker 01

  Yeah, but that's the other thing about Vue and Nuxt. It's community driven. Of course, they have like corporate sponsors, like you can see on their site like who sponsors them, but it's all about the community. It's all community driven. No, no one is paying to have certain things done. It's, you're not gonna have a rug pull because a company decided to do things a certain way. It's all by the community. And because of that, it's very open. You can host it anywhere. If you go to integrations and then hosting, they have docs for Netlify, Vercel, AWS Amplify, Azure, CloudFlare, Dino Deploy, GitHub Pages, Digital Ocean, like anywhere, and Vercel. Actually, in the course, I host the Nuxt app on Vercel, so that's possible too. But yeah, you can pretty much host it

• 22:36Speaker 01

  anywhere because it's built on top of Nitro and they don't have any allegiance to a particular provider. I will say there is a service called Nuxed Hub that is, I believe, some of the members of the core team started to create this to kind of figure out, well, how can we make money and be open source too?

• 22:53Wes Bos?

  Yeah.

• 22:54Speaker 01

  And it essentially configures your CloudFlare account automatically to be able to deploy a Nuxt app. And it's, it's like a hosted service that you can use. But beyond that, yeah, it's all community.

• 23:05Wes Bos?

  So that, yeah, their Nuxt hub, I think we talked to Daniel about this. It's not like a, it's not a host itself. It's just like a, kind of like a flight control or, what's the Laravel one? Before they had Laravel Cloud, they had, or they still have it, but basically you bring the own hosting, but the app, it just like does all the deployment and all the pointing and all the configuration, everything. So it's just a nice dashboard that you get this nice experience.

• 23:34Speaker 01

  Exactly. I think the Laravel one was Laravel Forge.

• 23:37Wes Bos?

  Yes.

• 23:38Speaker 01

  And then, yeah, NuxHub, very similar. They kind of abstract away all of the nitty gritty details of configuring CloudFlare and then you just pay for the raw cost of whatever hosting provider.

• 23:50Wes Bos?

  That's good. What, what database did you use in your course?

• 23:53Speaker 01

  We use Drizzle with LibSQL and when we're in prod, we deploy to Terso.

• 23:59Wes Bos?

  Beautiful. Cool. Anything you don't like about Vue or Nuxt?

• 24:06Speaker 01

  Like I mentioned, having to jump between folders is something I actually got used to. Initially, I was like, I don't like this and this is one of the reasons I might not use Nuxt again. But having since then, started to build things out with TanStack and also revisited NextJS, I actually do prefer, even though I have to jump around, I do prefer the Nuxt way of doing it. I will say, we didn't talk about auto imports. And so this is one of the things that people might not like about Nuxt is by default, it sets up stuff so that it's automatically imported. So if you define a component in the components folder, you can use that throughout your app and you don't have to import it. If you define a composition function in the compositables folder, like use fetch or use my custom thing, you can use it anywhere without importing.

• 24:51Wes Bos?

  You don't have to import it.

• 24:52Speaker 01

  Don't have to import it. And that, some people can find very confusing, especially if you get dropped into a larger codebase, you're like, where the heck is this thing coming from? Of course, you can use go to definition, you can hover over it in the editor, it'll tell you. But that's something definitely to get used to. I personally like it. Again, the more experience I have, the more stuff I work with, I want to write less code. I want to import less. I just want things to work. So I like it, but that will be something you technically can turn it off, but a lot of the docs are using auto imports or some of the tutorials are using auto imports. So that might be something that takes getting used to.

• 25:26Wes Bos?

  Oh, yeah. Yeah. Web components are like that as well, where you just, you just register it and then it's just globally available, you know, and it can be a little bit funky, especially if you don't have the tooling set up to figure out where is this thing being defined? Or like, like you could possibly overwrite components, I guess, or they, is it based on the name of the file?

• 25:49Speaker 01

  It uses file name. They have several conventions. So like I use kebab casing for my file names, but the convention is you use, you instantiate them with Pascal case. So it automatically knows that because I named it that it converts it to Pascal case. And then when I use it, I can use it that way. You technically could use it Pascal as well. Those are actually rules that I believe come from Vue JS, not Next JS or not Nuxt. It's just the conventions for how to instantiate a component based on its name. Yeah.

• 26:18Wes Bos?

  Yeah, it makes sense. All right. Well, that was, that's super interesting. Thank you so much for laying it on us. I need to build a Nuxt app so bad. I've been thinking about it for quite a while. I almost moved my own personal site over to it. But I, I didn't do it because of JSX. I wanted to just stick with JSX. Although I think you could probably move over to JSX to, to view code pretty easily. What do you think?

• 26:45Speaker 01

  You technically can use JSX in your Nuxt components. But so like, yeah, you can, like you, you literally just call it dot TSX. But all the docs are for view components. Everything you find about view is not going to show you JSX. So that's going to be an uphill battle, but technically you can. They, they have a component loader because at the end of the day, your view components just get turned into a render function. You can use JSX in the exact same way. So technically, if you don't want to leave JSX, you could use it.

• 27:14Wes Bos?

  They could, but not, not like React hooks or anything like that. That stuff wouldn't work. Simply just templating with JSX.

• 27:21Speaker 01

  Exactly.

• 27:21Wes Bos?

  Cool. Awesome. Well, thanks so much. Make sure you check out CJ's video. Go to youtube.com forward slash syntax FM and watch his tutorial on Nuxt. Give it a shot and let us know what you think.

• 27:34Speaker 01

  Definitely.

• 27:34Wes Bos?

  Peace.