You Should Learn Nuxt!

What's up, everyone? Before we get in, we want to tell you that we're having a Syntax meetup in Denver. You're going to want to come to this if you're anywhere near Denver, because it's going to going to be a hoot. May 29, go to Syntax.fmmeetup.

You can grab your tickets for that. We've got Syntax folks Yarn going to be there. We Scott Sanity folks that are going to be there. We've got the Vercel crew. We got the Mux crew. It's going to be called Dev's Night Out. It's going to 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 Node, to talk about, a lot of his work on on Vue and Nuxt. And CJ just put put out an absolutely massive course, like, almost twelve hours, something like that. Wes it what was that, CJ? Yeah. It was twelve and a half hours if you include the hidden chapter. But yeah. Oh my goodness. So that's on our YouTube channel, youtube.com/syntaxfm.

Yes. And the idea of this episode is we're gonna kinda run through what Nuxt and Vue is, why CJ likes it, and and how all the pieces work, And and you're gonna finish this Node. 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.

So welcome, CJ. How's it going? It's good. Thanks for having me on. I am I am excited about Nuxt. I've been working with it over a month probably close to two months now. I'm 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, Next. Js and SvelteKit and, SolidStart, and I've been messing around with TANSTACK Scott. And right now, Nuxt is my favorite. That's a big thing to say. So It is. Yeah. For anyone who who doesn't know,

Vue is the, like, equivalent of React. You probably know that if you're listening to Spogast.

And Nuxt is their their meta framework for building full stack ESLint side, server side, applications

with with Vue, both on on both sides. It's similar. You can you can say it's like the next JS of Vue. Is that fair to say? 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 ESLint. Or you could build a fully pre rendered website. So, yeah, it supports all the different rendering strategies. Like a full view. Yeah. And you get to and you get to use Vue to build out your pages.

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

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. Yeah. And a lot of times, things are just slightly more intuitive. Node, 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 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 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. It it seems to me like the the very same, like, excitement that I got when I first used Angular, like the very first Angular, they're coming from

the mess of jQuery that I was writing.

And then I remember the very first time I used like data binding in, in Angular, you know, like you have an input that was in there at the time Wes two way data binding, which is apparently a big no no these days. But I had two pnpm, you could type in either one, and then it was 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 is so exciting.

Definitely. And when I first picked up Vue. Js in 2015, '20 '16, that's basically how it was kind of advertised. It was like the happy middle ground between AngularJS 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 AngularJS, like v four used to be n g four or v if used to be n g if. 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. And if you want to see all of the errors in your application, you'll want to check out Sanity at century.i0/syntax.

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

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

Alright. Let's talk about routing because I 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?

It does. And so it's actually built on top of Vue router. And so Yeah. 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 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 it allows you to do, like, programmatic navigation. They have built in components like the Nuxt Tolinski, 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. And so when you had Daniel on, he talked about Nitro quite a bit.

And and, actually, that's one of the 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 Node if you look at TanStack Scott, 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 to hit the ground running actually came from the, the Nux ecosystem. Yeah. 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, Vite is from the guy that made Vue as Wes. And it just seems that all of these new tools Wes it's just like, 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 Knox because like literally everything else I'm, I'm using is, is coming out of this ecosystem. So

probably they got this part figured out too. I think so. And so that like I mentioned, that gives you file based routing. So you can create view 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 Nuxt 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 h three. And Nitro JS built on top of h three. But h three, was one of the first, like, runtime agnostic kind of, like, express replacements. Yeah. 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 Nuxt JS this idea of conventions. So if you go on to the Nuxt documentation, then click on docs and then guide, there JS a section called directory structure.

And this lists out every single directory that you might have in your Nuxt app, but each one of those has its own documentation. So it has this idea of conventions Wes, like, if you put something in the composables 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 next a Next. Js app where they just put stuff anywhere they want, and, they can because it's just JavaScript. But I do like that Next kind of has some of these conventions Wes any one of these folders has the specific types of things inside of it. Mhmm. And, yeah, that little bit of, like, magic is something that I often like. Are you would you say you're you're a fan of magic, or where's your line for how you like how much magic you like? I love magic. I I understand people that don't. Right? Maybe. 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 Nux long enough that there are so many things I don't wanna have to do. I don't wanna 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 I completely understand the view 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 wanna have to write all that boilerplate. And if you understand the magic, like, if you do understand where all this stuff is coming from Yeah. 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 of how some of these things that are magic, you are gonna have to do some research to figure that stuff out. In a lot of cases, you can also still duck out Yeah. And and get access to everything. I'm just reading the docs for the actual middleware here Mhmm. Where it's like, well, sometimes you do want access to the raw request

and and be able to to do that type of thing. So it's nice to have those escape patches. Wacoo is similar to that as Wes, where 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 plug in for it. Do you know if Oahu is built on top of Nitro or is it Vinci? Is Vinci built on top of Nitro?

Do you know? It's not. It's it's just it's v and Deno 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 Nux. Sorry, not Nux. VINCI, H3, all of these on JS 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. Yeah.

What about data fetching? So how does how does that work when you're building a Nuxt app? Yeah. So if you wanna define calls to your database or things that happen on the back end, you're gonna 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 use fetch. So for any endpoint you define inside of your Vue page or Vue component, you can say use fetch. You're gonna 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 use fetch 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 use fetch to get that gets back your data. When that code runs on the server, that's gonna 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, Nuxt 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 back end. 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. Oh, okay. Yeah.

I was gonna ask that because we'll we'll talk about, like like, rack 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 Yarn 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. 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 use headers or get request headers.

Okay. Attach those, and then the request internally appears as if it came from a user because it includes all their cookies and everything else. Okay.

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

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 wanna do data fetching, you define your API endpoint, you use the the use fetch composable to call it, and that kinda gives you the RPC because you have type completion as to what the API endpoints Yarn. 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 nRPC like experience. Oh, yeah.

I bet we'll probably see something similar to that in the future. Like like, Svelte just announced they're doing a synchronous 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 our PC. 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? Yeah. Actions and loaders. Yeah. Yeah. Yeah. But they're right now, they're just they're tied to a page, at a page level. So I bet

that the new the sync Svelte stuff will allow us to put those anywhere else. 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 Bos, 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. Oh, 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 Node, you put everything in that one folder, and that makes it nice and portable, because you you know where you're working. And, also, if you wanna 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 or folder and move that to another project. Yeah. And I will say, if you wanna see some of this stuff in action, you don't have to commit to the twelve hour video. I also made a, NUC a NUC crash course video. It's about forty five minutes, but I will say if you skip to the sixteen minute mark in the NUC 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 ESLint 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 gonna 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 Vercel, and that will suspend that component from rendering on the server side. 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 JS to have a client component that has, like, a useEffect with a with a fetch or maybe use something like TanStack query. So there's a lot more plumbing you have to do if you wanna get that experience Wes 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 and 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. It's still very cumbersome to do it in my experience in Next. Js.

And let's talk about these, like, modules or core modules. So let's say you want to build something and you Node, like, 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? Definitely. And, there there are certain Npm modules that you could just install. It doesn't necessarily have to be, Nuxt specific. Doesn't have to be the Nuxt version. Yeah. Especially ones that are based on web standards because it's built on top of Nitro, if you're thinking about, like, these back end things. But I will point you to the NUC stocks. So if you go to the NUC stocks, 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 plug in for Kind Auth. They're like a hosted auth service. There JS, Node based 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 wanna do, someone's built a module. And the way that you install these is there's, like, a Nuxty 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 ESLint module. So this automatically gets you up and going with a ready ready to go, well designed lint config.

I also use the Scott plug in. So this uses Iconify, which lets you pull from, like, thousands of of icons.

I also used the color mode plug in, which gives you automatic light mode and dark mode detection that you can use to, like, plug ESLint, like, a theme switcher. Yep. 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.

And for all the, like, you think, okay, I'm building an an application, right, you have your modules and whatnot, there's also equivalents of, like, UI components, data stores.

The Vue ecosystem is is like mature. Right? There's equivalents ESLint in in many cases, better versions of what we have in in other,

frameworks. 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 the Nuxt ecosystem. Even like a shad CSS, there's a a view version. For a Vue Shad c n. They're they're making it happen. And there's a shad c n dash Nuxt plug in that automatically sets it up so it's usable inside of your your Nuxt app. And, of course, there are UI frameworks, like, specific to the ecosystem. There's a framework specifically called Nuxt UI Mhmm. That looks really nice. In the course, I actually use Sanity UI. So Daisy UI is just a a Tailwind CSS framework. So it can be used with anything. And I was able to use it inside of my my Nuxt app. Awesome. And Wes Syntax sponsored this one. How do you say it? Penia.

Yeah. That's a data store. Right? Exactly. So I 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 Penia. There's not 20 choices.

There's not a lot of bike shedding around that. If you need global state, we use Penia. And in the course I use Penia, there's a a Penia Nuxt 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 Deno just works on top of those as well. So if you're already used to all of the composables in Vue, like creating state variables or creating effects, You just use those inside of a PNaStore, but now that store can be imported and used inside of any component.

And let's talk about hosting.

I think Vue and Nuxt is, like, the only framework or the the only major framework that doesn't have a massive company behind it, you Node, like, like Angular has Google, React has has Vercel and and Facebook.

Svelte I could know. Svelte doesn't have any any any big company behind them as well. But Yeah. Vue and Nuxt doesn't. Right? Yeah. I mean and, technically, Svelte hired Rich hair or or or Vercel hired Rich Harris, but still, Svelte is not necessarily owned by Node. Svelte is not a Vercel project. They're just paying for him to work on it, which is really cool. 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 Yeah. 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, Deno Deploy, GitHub Pages, DigitalOcean, like, anywhere in 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 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 Nuxt GitHub 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? Yep.

And it essentially configures your CloudFlare account automatically to be able to deploy a Nuxt app.

And it's it's like a a hosted service that you can use. But beyond that, yeah, it's all community.

So the yeah. They're NuxtHub. I think we talked to Sanity about this. Mhmm. It's not like a it's not a host itself.

Use it's just like a kinda 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 and all the pointing and all the configuration, everything. So So it's just a nice dashboard that you get this nice experience.

Exactly. I think the Laravel one was Laravel Forge.

Yes.

And then yeah. NuxtHub, 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. That's good. What what database did you use in your course? We use Drizzle with, LibSQL. And, in when we're in prod, we deploy to Terso.

Beautiful. Cool.

Anything you don't like about Vue or Nuxt?

Like I mentioned, having to jump between folders JS 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 Next. Js, I 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 composables folder, like use fetch or use my custom thing, you can use it anywhere without importing. You don't have to import it? Don't have to import it. And that, some people can find very confusing, especially if you get dropped into a larger code Bos. You're like, where the heck is this thing coming from? Of course, you can use GoToDefinition.

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 the more experience I have, the more stuff I work with, I I wanna write less code.

I wanna 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 auto imports or some of the tutorials are using auto imports. So that might be something that takes getting used to. Oh, yeah. Yeah. Web components are like that as Wes, where you just you just register it and then it's just

globally available, you Node, and that 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 Wes, or they is it based on the name of the file?

Uses filename. They have several conventions. So, like, I use kebab casing for my file names, but the convention is you use you, instantiate them with Scott 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. Yeah. Makes sense.

Alright. Well, that was that's super interesting. Thank you so much for laying that on us. I need to build a 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. Wow. But I I didn't do it because of JSX. I wanted to just stick with JSX. Although, you I think you could probably move over to JSX to to view code pretty easily. What do you think? You technically can use JSX in your Nuxt components.

But so, like yeah. You can. Like, you you literally just call it .tsx, but all the docs are for Vue components. Everything you find about Vue is not gonna show you JSX, so that's gonna be an uphill battle. But, technically, you can. They they have a a component loader because at the end of the day, your Vue components just get turned into a render function.

You can use JSX in the exact same way. So, technically, if you don't wanna leave JSX, you could use it. They could. But not not like React Hooks or anything like that. That that stuff wouldn't work. Simply just templating with JSX. Exactly.

Cool.

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

Definitely. Peace.