Daniel Kelly: With the introduction of view three actually being written in TypeScript, that was an eye-opening experience for me. Maybe I should really invest a little bit more time into fully understanding what TypeScript is. This is a framework I rely on every day of the week and they said, okay, let's scrap what we had and start from scratch with TypeScript. Paul: Hi there and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. Log Rocket combines session replay, error tracking, and product analytics to help software teams solve user-reported issues, find issues faster and improve conversion and adoption. Get a free trial logrocket.com today. I'm your host Paul, and today in this episode we're going to be talking to Daniel Kelly. Daniel is a teacher content creator at View School. He has over 10 years of development experience, worked with a variety of technologies. I mean this is a web development podcast, so we want to bring you experts. So he's been in View, Nuxt, Laravel. We're going to be going over TypeScript, why you should use View with TypeScript, some of the new exciting features in View three. Welcome to the podcast, Daniel. Daniel Kelly: Thanks Paul, thank you very much. I am a human being for everybody out there wondering, and definitely dabbled in some other cool stuff back in the day as well. Maybe a lot of you have done some WordPress stuff, and some jQuery stuff, maybe some things you're not proud of. Paul: WordPress, that just really brought me back. We're in a different world today. We're going to be talking about Nuxt today. That's a totally different world. Daniel Kelly: Yes. Paul: Different development style and everything. How long you've been messing around with Nuxt? Daniel Kelly: I think I first really used Nuxt for a JAMstack static site generated thing. Just a little side project that I was playing around with, back in maybe 2019, I think? And it was really cool. I was used to working with PHP on the server side with Laravel, so the whole node running on the server side thing was a little bit scary for me. PHP land is a little bit easier for me to understand. And having that JAMstack architecture was really easy to get into, coming from the PHP side. So that was a lot of fun, and almost picked up using Nuxt for a project we were using at work. We ended up not doing so, but since then joining the View School team, I've used Nuxt for different classes, different courses and things like that. As well as our VJs four event that we put on a couple times a year, where we build a real-world project. So that's been a pretty cool experience. Paul: For somebody who's not in the View world, what is an analog to Nuxt? Daniel Kelly: The closest thing would be, almost like Laravel, kind of. Because you get the server side stuff, but then you get to write view components for your template layers. So instead of writing blade templates, you're actually just writing more View, which feels really nice. You're not swapping back and forth between different languages and syntaxes. Paul: I find it interesting you say Laravel. Because just by the naming convention, I think a lot of people think about next, right? Daniel Kelly: Absolutely. Paul: And so why did you say Laravel and not Next? Daniel Kelly: I've literally never used Next. And if you're going to compare one to one, yeah, probably Next is the good parallel there. But to be honest, I tried React one time, just didn't like it. It wasn't for me. Paul: Why wasn't React for you? Daniel Kelly: It just was so foreign to what I was used to. And then I started trying out View just a couple weeks later, and View just felt more natural. Paul: That's interesting to me, because we're talking about TypeScript in this episode. And when a lot of people step into using TypeScript, they're like, okay, this feels more natural because I'm getting code completion, I'm getting suggestions, I'm getting organization in my brain, just intrinsically. And my big thing that surprised me was, TypeScript feels late to the party with Nuxt three. I'm very curious why it felt like that saving grace to you when, assuming at the time there was no TypeScript, or it wasn't strongly used. Daniel Kelly: When I first started working with Nuxt, you could use a little TypeScript with VJs, but it was kind of painful. So honestly, I just avoided it. I used TypeScript for maybe some little helper libraries that weren't specifically dealing with view. But when it came to my components themselves, I just avoided TypeScript. And with the introduction of View three actually being written in TypeScript, that was kind of an eye-opening experience for me. Maybe I should really invest a little bit more time into fully understanding what TypeScript is. Because this is a framework I rely on every day of the week. And they said, okay, let's scrap what we had and start from scratch with TypeScript. And so there must be something to this. So if I want to make something maintainable like View, maybe I should consider TypeScript. With View three, like the View three boiler plate code where you do MPM and net view at three, literally the first question after what's your project name is, do you want to use TypeScript? So it's a very big part of it. And then in Nuxt three, TypeScript is enabled by default. There's nothing you have to do except create the project with the CLI. So it's very easy to get started with TypeScript in view three. And I think this is a big deal, because I think for me was a bit of a hurdle to jump over it. But with view three, there's literally no excuse not to just try it out in the project. Paul: Do you think that this is a good opportunity for people to step into script as their first foray? Daniel Kelly: 100%. Because you could have a Nuxt three project for instance, that already has TypeScript enabled, and you could do all your components in just JavaScript. But then you find one single use case where, oh, it could be cool to use TypeScript here. Well, then you just add lang equals TS onto that single component and you can start dabbling in TypeScript. You're not using it in your entire project, so it's really easy to get started that way. Paul: And so under the hood, I'm imagining it has that omniscient ability to transpile at every component, but it only does it selectively. It's something like that going on? Daniel Kelly: Yeah, yeah. I don't know all of the magic that's happening. I'm sure it's probably like the allow-JS configuration setting and TypeScript somewhere in the configuration of Nuxt and it just says, okay, we're cool with writing JavaScript here. And the TypeScript compiler just says, okay, that's JavaScript. We're cool. Paul: So bootstrapping a project is super easy. What was the command? Daniel Kelly: For just plain View three? It's MPM and Knit view at three. And then for a new Nuxt three project, I believe it's MPX, NuxE, create. Or MPX, NuxE, an net. Paul: That's a good excuse to get started with TypeScript. I feel like you can step into a framework and have that be your language. There's this sigmoid curve about using a framework versus actually learning how to code a node. And that disconnect is always entertaining, to see how frameworks try to glue that together. And some do a better job than others. Daniel Kelly: And I think Nuxt has really done a good job of it, because it just feels so seamless. I don't have to worry about, where does the output file go, and like blah, blah, blah, all this. It uses Veet under the hood as the build system. It's super quick, but in a view three project you can even see you're literally doing script source to your TS file. And that's the way it should be, right? You should just be able to add it, and you shouldn't have to worry about all the steps in between. Paul: The first time I ever tried to import a simple JSON file into my TypeScript code, I was having a horrible time. I'm like, this should just work. Daniel Kelly: Absolutely. Paul: That's really encouraging to hear about View. Daniel Kelly: It's good the ecosystem is moving that way. And to be honest, for a guy that comes from the PHP ecosystem with Laravel, that is one of the big issues with JavaScript sometimes, is there's just so many different flavors. You get your ESM modules, and your require, and all this stuff. And it's a very complex ecosystem, so to see frameworks really make the process easier is excellent. Paul: What do you think is something that developers might run into if they're coming into TypeScript for their first time, and they're used to developing in JavaScript, that might cause a scope explosion or like a complexity explosion that people might want to look out for? Daniel Kelly: I think that when a lot of people first get started with TypeScript, it does feel a little bit more wordy. Sometimes you feel like you're typing things to make the compiler happy and your ID happy, not necessarily make your code work. So some people have a bit of a bitter taste in their mouth when it gets to issues like that. What you don't realize is that down the road, you've actually probably saved yourself some trouble that now you're never going to get into. And if you hadn't had TypeScript in the first place, that frustration that you have for doing a little bit of the extra typing, a little bit of the extra things like that, it would probably hit later if you're just using plain JavaScript. I definitely think some people feel like they're typing for the compiler, they're coding for the compiler or for the red [inaudible 00:08:40] lines in their ID. Sometimes that can be an issue, just in terms of how people feel about coding with it. Paul: Just a quick pause here to remind you that Pod Rocket is brought to you by Log Rocket. Log Rocket can help you understand exactly how users are experiencing your digital product with session replay, error tracking, product analytics, frustration indicators, performance monitoring, UX analytics and a bunch more. Machine learning algorithms surface the most impactful issues affecting your users, and you can spend your time building a better product rather than hunting through tools. Solve user reported issues, find those issues faster, and improve conversion and adoption with Log Rocket. Do you feel like there's a general pattern of misuse of TypeScript that you notice? And I'm only asking because I watched a video with Matt Polach, who we've had on Pod Rocket, discussing like some details about TypeScript Library, and the language, and going into. And he said one thing is like, you don't necessarily want to type everything. When I first got into TypeScript, I would put that colon in front of everything and it's like, well no, that's not the point. I wonder if there's anything like that that you notice people coming in and using it in an incorrect way, specifically with Nuxt or View. Daniel Kelly: I think people do tend to use that colon a little too much like you mentioned. But View is really good at doing the implicit typing, right? It can take your initial value of a reactive ref and say, okay, the initial value is a string, so this ref is always going to be a string, right? Paul: Oh, neat. Daniel Kelly: It's really great at implicit typing, actually. You can have your computed props be implicitly typed based on the return of your computer function. You can have, even in Nuxt it's so amazing. You can have your API endpoints typed. Like, you're making your request. And not only can you auto complete the API endpoint, slash API slash whatever, that's in your little dropdown list of options. Also, whatever's returned from the response to that endpoint is fully typed. Honestly, view makes it pretty hard to do things wrong. Some people do get a little confused with defining omits from a component. The syntax is a little verbose for defining the payload for an omit. You kind of have to remember just copy and paste it somewhere, put a snippet in your IDE is what I've done, and that helps a ton. Paul: I think it's hard to make errors, and it'll auto complete, and stuff like that is a good call out. Because we're also coming into this day and age of code pilots getting better and better, ChatGPT's out there And I mean specifically Code Pilot, which is in your IDE, it reads your types. And it's really neat when it reads a type, and if it's going to type my API endpoint, it would just auto complete it for me. It just knows and it would be correct. That would be sweet. And I didn't know that Nuxt typed my API endpoint in the backend, so that's super. One thing that gives me an unshakable feeling of anxiety if I'm writing an express server of something is when I'm taking that request body into the function, I'm just like, what is it going to look like? Am I going to use Zod? I mean I typically use Zod, but there's like a whole ... Use TypeScript, people. I'm really encouraged to use Nuxt and View, hearing all this gluing it does. It reminds me of Prisma, how it emits different types and then I can follow those types, drill down, and really see what different functions are expecting. Daniel Kelly: That is a great pair actually, for working with Nuxt in databases, is throwing Prisma. In there and then you really have typing across the entire app, right? Paul: Yeah. Daniel Kelly: You've got your data layer from the database being typed to your backend, then your backend is being typed to your front end. Paul: I feel like typing, and using Prisma, and this general organizational hygiene is becoming pertinent, and you can find it in a lot of different frameworks. How do you think Nuxt specifically sits in between the remix and the Astro of the world, or the Gatsby? Because remix is the service side rendering king. Gatsby, Astro people are like the static king. It can be said in a lot of contexts. I wonder where you see the next few years of next down the road, and who's going to be using it, who are the customers? Daniel Kelly: To me, there are some holes in what Nuxt does compared to something like, Remix has the special ability to load all these different pieces of data in parallel. And you don't have that in Nuxt. And Astro is really built for no JavaScript unless it's really needed. While Nuxt out of the box comes with Hydration and all this stuff, and it's really built for server-side rendering though you can do static generated stuff in it. But Nuxt is adding on all these little things that are taking cues from these different things in the community. So I know for a fact that having some loaders, like Remix uses in order to do things in parallel. I know for a fact that there are some people in the Nuxt Labs team that are dabbling with that, if not actively working on a solution for that. You've also got route rules for hybrid rendering. Paul: Yeah, Astro, they were the big hybrid rendering poster child. So Nuxt has taken a similar approach? Daniel Kelly: Yes, they are. And so you can do SWR on some routes, which is the Stillwell revalidate. You can do completely static on some routes. So the very first hit is run on the server, run in the Lambda function, whatever. And then it's cached indefinitely. So you can do that per-route. You can also do complete SSR per-route. Or complete SPA per-route. So essentially four different options there for each route. Run everything in the client, run everything on the server, or do these different caching mechanisms. You can run server-side Nuxt stuff on hosting solutions like Versace, and Notify, and all of it runs in the serverless environment. And all of it works with TypeScript. It works really nicely. Paul: How can you make a node general server side run in a CloudFlare worker? Daniel Kelly: It's magic to me, to be perfectly honest. Under the hood, they use a piece of software from the NJS organization, so NEX Labs also has an NJS organization on GitHub. And the piece of software is called Nitro. So it's basically this server engine that can run in any environment. It can run on Node, it can run on Dino, it can run on CloudFlare workers. Yeah, it's crazy man. Paul: I feel like all these serverless things came out because they were like, we need to control and constrict a little bit. And now they're like, oh yeah, well screw you guys. Daniel Kelly: Absolutely. And it's really nice, because you can use this no matter what framework you're using. This is a framework-agnostic thing, and I really like what the Nuxt team is doing in terms of the NJS organization. They're opening up a lot of possibilities to not just View, but to everybody else as well. Paul: And so the hybrid generation is something that's already out, if I'm not mistaken, right? Daniel Kelly: Yeah. Paul: The hybrid rendering, excuse me. And then the generation where you can do it anywhere you want, that's out. Daniel Kelly: Yes. Paul: And then the thing that you talked about that people are probably working on right now in the labs was that first thing we just touched on. Daniel Kelly: The remix-style kind of parallel loading stuff. Paul: Is there anything else that's maybe not out yet down the road? Have you heard through the grapevine? Daniel Kelly: Daniel Rowe put out a experimental package within the past three or four months to strip all your JavaScript away. Like Astro, essentially. And I believe it's an experimental feature now in Nuxt three. So they are working on that piece. So a lot of the things that these other frameworks are doing, Nuxt is either already doing or at least working on, and I'm already familiar with it. So to me it's not a really good incentive to shop around. Paul: Totally makes sense. It's like, you might as well continue being the expert in the domain that you're an expert in. Well Daniel, if people wanted to learn about the differences specifically between Nuxt two and three, because there's a bunch we didn't get into this episode. Dynamic roots have changed, there's a lot of other stuff that are different between two and three. So what are the top three that you would highlight on, besides the Dynamic route changes? Daniel Kelly: Number one is probably the EPI routes. This is huge. Because they are typed, and because you can have the EPI routes right there in your app, you don't have to boot up another express server somewhere or something like that. This is baked-in. Number two would have to be probably the hybrid rendering. Because on the JAMstack before Nuxt three, you're really talking about a build step where you're generating your entire site at one time. But now with Nuxt three, you're talking about hosting on the JAMstack in a slightly different way with that SWR kind of caching stuff. And so that's really a big deal. Because the build step in the JAMstack, while it's wonderful for performance, it can be this thing you have to work around sometimes. Then number three would have to be the composition API being the first class citizen. Like everything, Nuxt three is based around the composition API. And if you work in the composition a API long enough, it really just becomes very familiar, and going back to the options API can be a bit of a pain, to be honest. So those are probably my top three differences there. I do have a talk on this, and we go over all sorts of different syntax changes and things. There's a great cheat sheet out there by a guy named, I think it's Harley. But he has a Nuxt two to Nuxt three cheat sheet. I will try to find a link for you and pass that on, but that's one of the best resources I've found there as well. Paul: The Composition API is a new thing that we mentioned. When we were talking about the differences between Nuxt two and three, two of the things we were already harping on because they're like so big and so profound for the ecosystem. But the composition API was the new flavor of ice cream right there. So what is the composition API, and why is it important if that is a first class citizen right now? Daniel Kelly: Composition API was the new syntax introduced by View three. A different way of defining your [inaudible 00:18:06] activity within your components. So in View two, the options API was all about defining different types of reactivity based on an option. So you have your data to define your reactive data, you have a computed prop to define your computer properties, and so on and so forth. And they all had to live in this options object. And that really limited you to using the Reactivity API, only within the context of components. Now you had View X, which did a lot to get around that constraint, but that was kind of really your only option if you wanted to use reactivity outside of a component, was use View X. But now with the composition API, instead of passing these options into view, you're actually grabbing the reactivity stuff out of view. And that means you can add it into a component, but it also means you get added into not a component. You could just use it in the web browser, you could use it in what's called a composable, which is a way to kind of share logic between different components. It makes it really powerful. I even saw my boss, Alex, who founded View School, he had a talk at VGS Amsterdam where he actually used the composition API with a handlebars application, just to kind of show the flexibility of what the composition API could do. You don't have to use it within the context of a view component. Paul: It almost feels like a hyper-flexible react hook, if I wanted to put in into React context. And it gets a reusable piece of logic that I can really plug into different flavors of components, not just a React component. Daniel Kelly: Absolutely. And hey, if you're feeling adventurous, maybe you could even use a View composable in a React component. Paul: If it's a first class citizen now, why is that different from it not being a first class citizen in the prior version? What does that verbiage really mean? Daniel Kelly: So in the prior version, you had to download a different module in order to make the composition API work. To be honest, I don't even know if Scripts setup was supported or not. I'm sure it eventually was. But a script set up is just an extra bit of compiler magic on top of the composition API to make it easier to work with in components. So in Nuxt three, script set up is like the default. In all the documentation in Nuxt three you've got composition API being used, and Nuxt two, it's all options API stuff. Paul: It's threaded throughout the whole ecosystem now properly. Daniel Kelly: Yes. Paul: That's ready for private, gotcha. Remembering back to the talk that we referenced, I wanted to search up the name so that anybody listening can go look it up for themselves and see the difference between Nuxt two and three. It's called Leveling Up Nuxt with Daniel Kelly. And this was in Nuxt Nation in 2022. Go check out that if you want to really get into a longer talk. There's great slides that Daniel had, with good graphics, so you can go look at that. Daniel Kelly: I worked on that a long time, Paul. So thank you. Paul: And if people wanted to learn more about Nuxt in general, obviously go to the Nuxt homepage. You mentioned one or two individuals during our podcast, are there any other people that you would recommend folks follow or resources that besides the homepage that you would point people to? Daniel Kelly: Sure, definitely. So in terms of people from Nuxt, already mentioned Daniel Rowe. This man is a hero, he will answer any question. Anthony Fu is a really great resource for Nuxt stuff. He's on the core team. Puja Parsa, he's the mind behind a lot of the MJS packages, and just an absolute next-level genius. So far beyond what I can understand. But he's a really awesome resource as well. There is of course the next docs, which now live at nuxt.com, by the way. It's not nuxtjs.org anymore. So I know that has confused a few people. We have the Mastering Nuxt course, is the official course for Nuxt three. There's also a Nuxt three basics over at View School that I did not too long ago. And it's really interesting, short, compact, but give you the fundamentals kind of stuff. Paul: And if people want to follow you on Twitter, Daniel? Daniel Kelly: You can find me on Twitter at DanielKelly_IO. Paul: And I have to finish the podcast with asking when you said he's a next level-genius, do people in your circles ever say Nuxt-level genius? Daniel Kelly: I don't. No, it's all good, man. I'll definitely had that play on words thrown around. Absolutely. Paul: Nice. Daniel, thank you for your time. It was a pleasure. Daniel Kelly: Thank you very much, Paul.