Kate: Hello, welcome to PodRocket. I'm Kate, the producer of PodRocket. With me today is Noel, our engineer at LogRocket. Hi, Noel. How's it going? Noel: Good, good. Kate: Thanks for joining us again and also our guest today is, Alex Lichter. How's it going, Alex? Alex Lichter: Hey everyone. Thanks for having me. Yeah, I'm feeling great. How about you? Kate: Thanks for joining us. Yeah, so Alex is the founder of Developmint and also the Nuxt core maintainer. Excuse me. So just to start, can you tell us about what is Developmint and maybe just your role as a maintainer of Nuxt? Alex Lichter: Sure. Developmint is a company me and a couple of friends at first funded back when we passed our A-Levels and now we're two of us. But what I'm mainly doing there is doing consultancy, basically everything about web development with a focus of course on front end Vue and Nuxt, so that fits. But also we're doing basically full stack stuff and wherever help is needed it, we'll jump in. About Nuxt, the role as core maintainer, I think we'll go into that a bit later. I think I would start first with explaining what Nuxt is actually for everybody, not knowing about it. Nuxt is a web framework of course, fully front end oriented, but it is a meta framework based on Vue.js. So I mean, Vue is probably known to most of you and Nuxt sitting on top of that, and the idea is to make developers live easier and to make, especially also developing full fledged applications a breeze. I think that sums it up. Noel: Yeah. Perfect. What is your role in the Nuxt ecosystem, as a core maintainer? Were you pretty early on? Did you join later? What does that look like? Alex Lichter: I joined as I think the fifth person in team that was back in 2018, I think if I remember correctly. Quite some years ago and back then we were from four people to six then. So Jonas who is not part of the team anymore, joined with me back then and it was pretty wild, because there was no company behind it. Because now there is a company, because the Chopin brothers who founded Nuxt, also funded a company and got VC money. So went through a seed run, which is pretty awesome. Back then basically what happened is, that I was starting with Laravel and then came to Vue, because Vue is the default pre-seed for Laravel. I really liked the idea of Vue just using HML CSS and JavaScript to get in, not that much theory and technical stuff and not the need of type scripts, so that was pretty cool. Alex Lichter: The learning curve was, I think optimal and the docs were very good. I started with it and I worked on some client projects and then I realized, SEO is necessary. You want to have all the meta tags when sharing stuff and by default, single page applications aren't that good when it comes to SEO. So I thought there might be a solution for that and the answer was back then, Nuxt. I found out about it, I was all in, I used it and then I realized that there were a few things that were necessary for one of our projects. For example, like adding RSS feeds and they weren't part of Nuxt back then. I thought there might be a module for that, which is basically just a plugable module for Nuxt, the core isn't growing and growing and going that big, but there wasn't. Alex Lichter: So I thought, okay, I will just develop one and, well, I know that there is open source and thanks to Laravel, to the Laravel community also, well, was into it already. So I thought, well, if I have to write it and to make it work for my project, I could also open source it to reduce the workload for others. So others can use it as well and maybe work on it too, because they may need, I don't know, another format or something, or have other suggestions. So that was basically the idea, I got in touch also with the people back then from the core teams, of course the Chopin brothers, and also Pooya and Clark. These were to four people back then in the core team. Alex Lichter: So we were discussing a few things here and there and then I took a look into the core as well, going through all the code. Because if you've ever looked at the project at first, wow, it's a bit overwhelming, like with every large new project, but with tiny baby steps you get into it. I started contributing more and more and then it was around summer and I was on my way to Dublin actually, to Ireland, starting an internship there. Then Sebastien was like, "Yeah. Look, there is a Vue conference in London. Would you like to join us?" I was like, "Yeah. Sure. Why not?" They said, "Yeah. Okay. Then just book flight and hotel and we'll cover the ticket for you." So I was like, "Wow. Amazing. Yeah. I'll definitely not let that opportunity go." Then I went there and this was the conference where actually Nuxt 2 was live released and then the first time I met people from the core team. Basically the two Chopin brothers and we had a blast and they said, "Yeah. Congrats, thanks for being here. You're on the core team now." Noel: Nice. Alex Lichter: Yes. That's the history. Noel: Yeah. No, that's a very cool story. I guess, were you aspiring to ever become an open source contributor at this level, or did you just stumble into it? Alex Lichter: I think I stumbled into it. So it was never the goal and I never thought that it was maybe happening, but I was trying to bring that project forward. Because I really enjoyed working with it and I thought making it even better without having lots of overhead. Because most of the things I've added, most of the modules I wrote were also there because I also had to write them anyway for a project. At some point it was not only that anymore, but also, okay, this could be a great addition, maybe not for the project, but in general. So I felt the passion for the project and this is how it basically started. Noel: Nice. Yeah. That's a super cool story. I feel that's a common thread of open source maintainers, that it's always a dream many people have, to spend a lot of time working on open source and have it be their main profession focus, but it's hard to get to. I feel the common thread we keep hearing is just like, "I don't know. I just started working on stuff and kept contributing code and eventually something stuck. Now I'm doing it." I feel like this is another perfect exemplary case of that. Alex Lichter: Absolutely. Especially in my opinion, you have to be passionate about it and that's almost it. If you continuously contribute and it doesn't even have to be only code, if you contribute with documentation or explaining things, this is also very important or also triaging issues. What I'm doing mainly at the moment, besides giving workshops and talks and stuff, or producing videos, is actually really talking to people on the Discord. Understanding the problems and also try to understand what pain points the community sees. Then it's quite easy to say like, "Okay. Maybe we need to improve documentation. Maybe we need a more in-depth block post. Okay. Then I write one, or maybe we need a new function or a new feature." Also having an ear in the community is very important for that too. Noel: Nice. Yeah. Very cool. I could talk open source, maintenance and community building and stuff all day, but maybe to reel us back a bit. Can we frame a bit more about why someone might care about Nuxt and what a meta framework does? Alex Lichter: Absolutely. Yeah. First thing I always try to bring to the people is, you could use plain Vue. Nothing is wrong about that and if you start learning one of the main frameworks, or start learning Vue, it's totally fine to not jump into Nuxt right away. But if you want to develop an application and you want to be quick in terms of not having to configure all the things, or just get a sensible default out of the box, then Nuxt is a great choice. You have a very quick time to market, you can just start with your application, you have one command to build things. Another big plus is that Nuxt is very versatile, in terms of you can build SPIs, but if you want you can enable server side rendering, either on demand within those server, but also with static site generation, with just conflict flag. So that's pretty cool and it also enables you to not having to think about it before starting your application, but just build it, try it out and then iterating over it more and more. Noel: What is the difference, I guess for devs that are unfamiliar, on a Nuxt in static site generator mode, versus default mode, or is there a difference? Alex Lichter: Yeah, there is. So I think you can choose when you create a Nuxt application, but generally you have just server side rendering enabled and that means Nuxt would run with a node JS server running and whenever. At first you need that server all the time and whenever someone is hitting your page, then the first request say the person comes from Google or the user is hardware loading. This will hit the node server and the node server will take the page and render the HTMLs. That's the basic of dynamic server side rendering. Alex Lichter: But if you have, let's say a blog, then you don't need the same content be rendered over and over again. What you want is static site generation, which basically means whatever you change, you edit or update or create a blog post, then just regenerate the site. Then they're just plain HTML files and the user doesn't have to hit a server anymore. They just get the HTML file, then after they see the content they will download, of course also Vue Nuxt and a so slightly overhead. From that point on where Vue takes over, it just works like a SPA. Noel: Got you. Maybe run with your example, a user has a blog, but then they have a login system with user details and stuff that get loaded over the wire. How does that setup work? Alex Lichter: That will basically mean you can exclude pages from being generated. So you can say, "Okay. Everything prefixed with admin, for example, you don't generate it beforehand." This is actually what I'm doing with my blog as well, which is of course also powered by Nuxt. I have an admin page there and I just say, "Okay. If admin is part of the route, the just don't generate it and ignore that." This will just work like a traditional SPA then. Noel: Got you. Very cool. How about for specific parts of a, I'm trying to think of another example on a blog. Say there's a comment section in the blog that may be more dynamic, how do you set that up? Alex Lichter: Then the common way would be either to load it after the page had been sent to the user, load it afterwards. Which also makes sense, because usually comments are below the post, so don't need them in advance. There are also other ways, having the option to do something, stay revalidate. So that's not possible for Nuxt 2, but will come in Nuxt 3, so that's currently in the making to also enable that. Noel: Nice. Yeah. I want to talk about Nuxt 3 a little bit, but before we get there, I want to walk this path a little more. So like you said, if you're getting into Vue and you don't see the need for Nuxt, just start with Vue and take one step at a time. But say you have a large existing Vue project and you're starting to feel the need for something like Nuxt. How would you recommend people go and explore and maybe start trying, to convert or introduce Nuxt to an existing project? Alex Lichter: Yeah. You already said the right word, converting is the thing there, because the main problem is that you can't just add Nuxt to an existing Vue project, because of the nature of that framework on top of Vue. What you can do of course is just spin up a new Nuxt project and then basically just carry everything over. Of course, Nuxt has a very specific folder structure, but it's not that different from what you would usually have in a classic Vue application. Maybe Vue has SQL pages and of course, maybe you have to adapt the pages then. Because Nuxt is using something called file system based routing, which means if, say you have an about a view file in the pages folder, then it's equivalent to slash about. Or if you have an about folder and then say team to Vue, then it's equivalent to slash about slash team. So this is something you might have to adjust and a few things as well. Alex Lichter: You've configured things in your Vue application, or you've add it to your router, you don't need it anymore, you have added Vue X. It's also all out of the box with Nuxt. So you have to tweak a few things here and there, but you can get started easily. I personally would suggest to try carrying everything over and just keeping it with not server side rendered. Just keep it as a plain old SPA for now and as soon as you migrated everything, then you can, if you need it, switch on server side rendering and then see if something breaks, what's going on. Migration is always a big topic and I personally always love to hear stories about people migrating from plain Vue to Nuxt. Because I'm very curious how everything works, what's smooth and what hiccups or what problems are there. Because that is always interesting to know, also from terms of giving a better developer experience and improving things. Noel: Nice. Yeah. Very cool. I guess when we're talking about, in the context of the benefits of Nuxt. We touched a little bit on SEO helping, when we want to get away from these large single page apps and just performance in general. Can you speak a little bit more to how having Nuxt in the stack helps with those two problems? Alex Lichter: Yeah. For service side rendering or server side generation, SEOs almost ground it by default due to having the HTML, that doesn't have to be generated by the JavaScript. At first, your search engine crawlers can just easily pass it. I mean, Google knows JavaScript now as well, but it's quicker, they see it directly. This is almost, I've given there out of the box and you can use something called Vue-meta, which is also provided by Nuxt. To alter meta tags to add, for example, also structured data and will be all reflected directly in that HTML, so that's pretty cool. Alex Lichter: Performance wise, I think the most important part is that whenever the user really gets the HTML from the server or from the static file, they can already see the page. The downside is it's not interactive yet, but at least they can, for example, read the blog post. The perceived performance is way better compared to an SPA, where you at first get that loading spinner, because the JavaScript has to of course, first being paused and then create the HTML. I think that's the main improvement here and also with caching API responses from the server side, for example. Say you have a larger e-commerce solution, you can even get way better, really performance metrics and KPIs. Noel: Yeah. Got you. Nice. I think that leads nicely into my next question. You brought up, so you have a large shop with a bunch of products or something, something in e-commerce. I think maybe devs that aren't familiar with this paradigm of having the server query data and then build pages and expose it, I think data might get a little bit lost there. Can you explain how these frameworks that do data fetching server side and then render pages, how those work, what that paradigm looks like? Alex Lichter: Yeah. In Nuxt basically you have a method called fetch, the naming is a bit confusing, so it's part of every Vue component and it's not related to the fetch API, so that's a bit important. In this fetch method, basically it can be anything and you can get any data you want and you can use any fetching library you want, but you can get data there. By default, this fetch function will be executed on the server side, if the page is server rendered or on a client side, if you navigate from page A to page B, then B's fetch function will be executed. Alex Lichter: If this happens on the server, of course the node server will then query the API, it will then transform all the component hierarchy into a HTML string actually. It will then also add the results from every fetch call inside the HTML as state, we have in the end, say a big adjacent object with the response. Then if this will be sent to the user, the JavaScript on the user side will take over that state to synchronize it, and to also get everything the server had then sent to the client to get the API response and then take over. Noel: Got it. To continue your example, say we're on a shop page and there's a product, I don't know, ID in the query string when the page is loaded. How does the component figure out what to do with that? Alex Lichter: Yeah. Usually in the fetch function, you then say, this.dollar.router.query. Sorry... this.dollarrouterquery," so you get the query parameters of the route, and then you say, "Dot item," if that query parameter called item, and then you get that one. In that fetch function you then say, backend.example.com/item/ and then put in that ID and wait the call so you get all the data. And then possibly also prune it, because you say you only want the quantity, title and description, and you don't want everything else in the HTML is a big bluff. Just want to get that and eventually just set that in a function as this dot results equals the result. Noel: Say you are a webpage and you have all these products and stuff. Is there a way you can tell the server to go ahead and fetch all of those pages ahead of time, so you don't have to wait for a user to make that request? Alex Lichter: Yeah, that's a bit difficult, right now I don't think. So what you can do is you can preload the JavaScript for other pages. So you basically say, if you navigate from a product page, to say a product overview page to a list of products. You could say, If that link to that product overview page is in the view port and the browsers is idle, so everything else have been loaded, then you can preload the JavaScript. That's also a feature of Nuxt called more prefetching, also quite popular in other frameworks, so that's possible. But I think really more as preloading or caching results from service side rendering, this will be possible in Nuxt 3. But in Nuxt 2, I think you would have to use something beforehand, something maybe like a service function to work or whatsoever, some catching solution like Varnish to do that, but it's not that easy. Noel: Got you. I guess, I'm thinking at LogRocket we use Gatsby for our blog builds to go pull out the WordPress aid. Can you do something like that at all in Nuxt, where you say like, "Okay. I know I've got all of these pages, I need to generate, go ahead and do the pre-generation." Does that just not conceptually happen? Alex Lichter: Yeah. This is also quite interesting, you can provide, say a list of r routes, that should be pre-generated, that would work. So if you have, say high generation, you can do this. What you can also do, if you build your page very well and we assume this happens, every page is basically linked, you have no orphan pages where there's no link. Then you can just say, I don't have to put it anywhere, because I have, say at least one static route, which is the index page usually. And Nuxt has a built in crawler, that means it will pre-generate the index page, it'll look for links and it will see, these are also Nuxt pages, I have to pre-generate them too. This will work without providing any list of routes, you just have to be sure that they're all linked correctly together, but that's important anyway. Noel: Right. Okay. Cool. That crawler method is interesting to me. I guess the question that leads me to is, in Gatsby, I feel one of the cool things that has been very helpful to us is, that we can do smart incremental builds. Because we have this giant WordPress blog, if every time we publish, we had to do the whole thing. It would take 20 minutes to do a full, clean build. Is there any incremental build support? Alex Lichter: Again, I have to tell, Nuxt 3 will make that even better, but yes. So the cool thing is, if you only change data and not the code, then you don't have to run through the whole build process anymore. Nuxt will have a way to say, there basically we just check all the files in the folder, if it checks them as the same one, then the cache version will just take the artifacts from there. Then you'd only have to generate the pages again with the data that's been present, but you at least skip a few minutes of the whole webbing process. Noel: Got it. Alex Lichter: In theory with a bit of manual setup, you can also say like, "Please just render this exact route." By just saying, "Please render that." This is possible, but it would be a bit of a workaround to get it working on Nuxt 2, in Nuxt 3 it will be nicer. Noel: Yeah. No, that makes sense. Again, even if you're using Gatsby or something, if you change code on the blog page, you're still going to have to re-render every- Alex Lichter: Yeah. Sure. Noel: You can't get around that. Yeah, that totally makes sense. Cool. I guess, back to this, I feel like we're on the fringes of it and you touched on it earlier. But we were talking about plug-ins or you mentioned plug-ins a little bit. Can you explain what plug-ins or modules, whatever, what those are in the Nuxt space? Alex Lichter: Yeah. That's important, because plugins and modules are not the same in Nuxt. So basically Nuxt modules, you can think of it as an isolated piece of code that can do almost anything in Nuxt. It can even, say Nuxt has specific so-called hooks, not to mix it up with react hooks or something. But just to say, whenever Nuxt is doing something, generating a page, finishing generation or serving a page when running a server, you can hook into Nuxt and change the behavior. Alex Lichter: Say for example, there is a module called the site map module and it will utilize a hook. To say, whenever the generation is finished, then create a site map based on the pages you've generated. Modules can use these hooks to alter Nuxt behavior, they can also add plugins and I'll come in a second with plugins. They can do whatever they want basically, they can even change the CLI of Nuxt. The skies the limit and the cool part is, of course you don't need much. They are basically NPM packages, you can install them, specify them and they work out. Alex Lichter: Nuxt plugins basically run once, either on the server on the client side or if you want, even both and they're usually used to add Vue plugins or to create services to inject helper methods, so these are super common for those tasks. Say you have a Google analytics module and it'll use a plugin to enable the client to say, this dot dollar GA analytics dot on or dot off or dot send event. It'll basically provide functionalities for the client or even for the server through the plugin. Noel: Got it. Are modules something that only run at build time, is that accurate? Are they injecting code? Alex Lichter: Yes and no. There is usually or best practice is, if you can avoid then yeah, only run at build time, don't run at run time, also due to the whole size of the application for serverless and cost at times and so on. So mainly there is an option to say, build modules and then define all the things that are going around at build time, but sometimes a module needs to be there at run time. So you can say, "Okay. We define this as a module that's just called modules and not build modules and it will go in there." For example, if it adds some middleware or server middleware from some custom endpoints or something, then it should be there in runtime too. Noel: Got it. Adding custom middleware, for example, wouldn't be a plugin typically, that'd be a module? Alex Lichter: Yeah. Because middleware, yeah, it would be a module and it worked like, in the Nuxt conflict say, "Okay. We will add this piece of middleware." Or there's also something called server middleware, which basically can act as a small node app in Nuxt. You can basically say, "Create a route called slash ping and whenever this happens, then just return with a response of 200, to enable easy health checks." This would be some kind of server middleware, but this only works when a server is running. So it would have to be part of the modules, because run time and let's say, site generation won't do anything because there's no server. Noel: Got it. Cool. That makes sense. I think the example you brought up was an RSS module that you were working on initially. So you've got a site set up or using Nuxt and you wanted to add an RSS feed. How do you integrate with a module, an RSS module, for example? Alex Lichter: So first, it's called feed module, it can be RSS, JSON, whatever. There are I think three standards. What you can do is you can add that through NPM, whatever you like and then in say, build modules or modules, you define that you're using this one. Then you say either in that definition, you can give inline parameters or you have a special configuration key called feed. Then you can say, "Okay, I define," you can define as many feeds as you like, say, "I define a feed called feed XML." Then I have some creation function that will basically in the end return the whole feed. Alex Lichter: Then defining cache time, the type of the feed and also data, if you have data already there. In this creation function, basically you say, "Okay. I have a feed object, which is based on another MPN package." Imagining all these feeds, that's way better than me writing a small little version of that. Then you can say, "Okay. I give the feed a title, a link description and then I can even do data fetching in there." I say it's a function, I can do, Axios calls it fetch or whatever and I say, "Get all the posts from my blog, from my API and then for each item, just add that to the feed item and all good." Noel: Nice. Very cool. I think that all make sense to me and thank you for painting such a clear picture, it helped. I understand this ecosystem a lot better now. Alex Lichter: Awesome. I'm glad to hear. I hope our listeners will too. Noel: Yeah. For sure. Cool. I guess with that, I'm curious about V3 and what you guys have been working on there. What prompted it? I mean, obviously Vue 3 is probably the answer there. But what else were you motivated to get in there and what's new and exciting? Alex Lichter: Yeah. Of course, Vue 3 is a huge factor, also Webpack 5, that Vite is now existing. There are a couple things that really, I would say changed and brought the ecosystem forward. The main point, there were few refactors that were long awaited anyway. So these needed a new breaking change and major version anyway, then there were a few things that will be necessary to make Nuxt even better. One thing that's happening in Vue 3 is, we get the core even leaner by extracting lots of functionalities into own isolated NPM packages. Basically by just saying, there is a package called UFO, that's basically there to handle all URLs and paths. Mainly URLs to say like, "Okay. Remove the query, just strip something else or add a trading slash or not." Alex Lichter: Nuxt had such utilities and still has it in Vue 2, but the idea is to make it at first reusable, it doesn't have to be Nuxt that uses that. Also to not have this as part of the core to make it easier testable, because testing these utilities in Nuxt is possible, but for some utilities, they have to couple to the actual Nuxt. The idea is to decouple them, bring them on packages, make them easier to test and also to reuse and even on projects, but also other frameworks if they like to. Then the other pain point so to say, was the whole topic of server side, not server side, serverless rendering. This is possible for Nuxt, but as I said, it's not as straightforward. Alex Lichter: The idea was to create a new server engine and the idea is to cover almost all deployment possibilities you have. That means classic deployments, that excite generation, server side rendering as well, which is important, but also deploying on serverless, like Azure, AWS, whatsoever. But also, and this is not a challenge, deploying on workers, on non-node environments, like Cloudflare Workers or Netlify. I think agentless they're called they, they have V8 isolating, but no JS environment, so you have to mark a few things out here and there to make all that work. A couple of things that besides Vue 3 and a position API, that drove Nuxt in the direction of, okay, we need a new major version. We can clean things up, we can split things out, we can make things better and testable, but also improving internals. Noel: Got you. Nice. Very cool. I guess, but my first question is on bundler. You mentioned Vite, is that the default now, or you have to configure your build step when you set up a new project? Alex Lichter: Yeah. By default, Vite is used as dev server, but the cool thing is you can always switch between Vite and Webpack and there's also... That's crazy what all these amazing people did. There is now something called unbuild, which is a package and it is basically a unified JavaScript build system. You basically build a way together with unplug and which is another option, to create plugins that are usable for Rollup and Vite and Webpack and for the same time. Ideally you create something and unplugging together with unbuild for the build phase, will be the reason that it works almost everywhere. You don't have to think about, okay, for Webpack, I have to do this extra or Vite do this extra. This always reminds me of back in times with jQuery, where we have, okay, this browser is doing it differently and we have another thing implemented here. jQuery is like, "Yeah. We take all what to do and uniform it." The same idea is behind unplugging, where you say Vite is doing differently, Rollup Webpack, both, all together, same interface, same API and it just works. Noel: Nice. So are you saying that is useful even if you're just deploying a web app, having a site, because then you just have to define the config ones or is that mainly for if you're working on modules? Alex Lichter: I mean, it depends a bit on what you're doing, but if you say, "I want to create a plugin that will work for any bundler." Then you surely can use unplugging. Right now it's commonly used in the Nuxt ecosystem, but that's the reason why it's a separate package, I can think of it being used wherever. That would totally make sense, if you go in all the way, deep down and creating on that lower level. Noel: Sorry. Yes. I'm catching up still, I'm still wrapping my head around this space where thinking about multiple bundlers now, instead of just- Alex Lichter: Yeah. It's crazy. Noel: It's good. It's a good change. Yeah. Alex Lichter: It's also super interesting. I mean, Rollup was there before and was mainly used for libraries and Webpack was mainly useful for the end application, but now also with Vite. Then another pain point is the whole ESM topic, switching from CJS to ESM only and libraries not having. This is also something that Vite pushed forward and Nuxt is also pushing forward, say ESM only, which means some dependencies can't be used anymore. Is there work around? Is there interoperability things that can help? But sometimes this also leads to breaking stuff and that's one of the reason why Nuxt also tweak things, find out ways to improve stuff and to give the best experience possible. Noel: Yeah. Nice. Say that somebody is starting a new project and they want to use Nuxt. Would you recommend that they just jump into 3 or would you say, "No, probably stick with 2 for now?" Alex Lichter: I mean, it depends a bit on what they're trying to achieve. Nuxt 3 is taking shape. I think the main issue, what keeps me personally from doing productive things, besides getting Nuxt production ready, is that most modules are not being ported over yet. I personally haven't ported my modules over yet too. Mainly because static site generation is not yet implemented, because there's still some architectural works to make this hybrid rendering or ISR and so on, incremental static regeneration work. So that's what's still holding and the other point is, that now there is something called Nuxt Kit, which is more or less a nice way for all module offers to define a uniform surface, say a contract for modules. You have options say, there's the name, there's the version, you have compatibilities, you have a dedicated way to write things, before it was just the function. Which means more freedom, but also less structure and so on. Alex Lichter: The main point is, testing these modules right now, there is a new test runner called V test. Another new cool thing that's also being used as a test runner for modules soon and there is also utility in the work that will work with Nuxt or Nuxt 3 which is the CLI test. That's still a work in progress, so right now I don't want to port my modules over without testing it properly, right now I can't test them due to this part be missing. I'm still waiting, but then I will port things over. Now coming really back to your question to answer them, if you want to play around and if you don't rely on modules, then just go ahead, because there's nothing that keeps you. But if you say like, "I want to bring a thing in production in a week or two." Then Nuxt 2 is a good option and you still get lots of goodies, like the composition API from your 3 through Nuxt modules, you can still do that and still leverage most Nuxt modules. Noel: Nice. Very cool. Somebody's more just exploring and wants to play with stuff, 3 might be where to go ahead and start, because you're probably not going to need to pull a bunch of stuff. But if you're going to need to integrate with a bunch of services and it'd be handy to have a ecosystem, 2 might be a better bet for now. Alex Lichter: Absolutely. As I said, you can always try paving path for migrating by just saying, "Okay. I still use to composition API for a module. That's still a way in Vue 2, even though it had been introduced in Vue 3." I think that's a good way too, because I personally, I really love to use the composition API and I don't want to miss it on Nuxt 2 either. So that's a good part too. Noel: Right. Totally. Yes. Say your goal was you wanted to build some crazy fast site and you wanted to deploy it at the edge, so it can run in Workers and everything. Is that working in 3 or is it close? Alex Lichter: Yeah. You can deploy in Cloudflare Worker's already in 3. In theory, you can even do this in Nuxt 2. So I did this for a Nuxt 2 project as well, because this new server engine called Nuxt Nitro is also pluggable into Nuxt 2, but ideally you just go for 3. Noel: Nice. Very cool. Awesome. I want to go check out Vue 3 now. I used Nuxt a long time ago, when I was spending more time spinning up new Vue projects and I had a big one, but it's been a long time. It's exciting hearing about all this new, I want to go check it out. Alex Lichter: Yeah. I think from the community, I have the same mixed feeling, because it now takes a while. Vue 3 is out for more than a year now and I understand that, but there is lots of internal work to get things done. Plus we don't want to push another version in half a year say, "There's Nuxt 4 now because we had to do lots of things that we just waited for." Right now is a change and it takes a bit and also we try to have a clear migration path at some point. But I would say for everyone waiting for a release date, it will be available in March, that's the plan. But of course, ecosystem catching up, we saw that with Vue 2 to Vue 3, it always takes a little bit of time. But we try our best to make it as short as possible and also give clear guidance. Noel: Nice. Yeah. I guess on that note, I feel it's been a little bit slower on the uptake for Vue 3 across the board I think, than anyone anticipated. A lot of the popular front end library or just module component libraries have taken a lot longer time to get rolling, but I feel we're getting there now, everything's catching up, we're on the precipice here. Alex Lichter: I hope so. Yeah. We're looking forward to that, more adoption, because I think Vue 3, even though there was this whole, I don't want to say drama, but about like, "There's a new API and we want to remove the options API and no, it's all good." Which was just, I think just a little bit of miscommunication in the end, which could have happened to anyone. But I think the step and the direction is good and also the developing experience will be improved, no matter what you use. No matter if you use JavaScript, TypeScript, it doesn't matter, now Vue plus TypeScript is amazing. I don't like Vue 2 plus TypeScript, due to me being forced having this magic, this app where and then other using the class component approach, not my jam, but with composition API it's amazing. Noel: It feels much more natural, to just have the type system there. Alex Lichter: Also, I think Vue with the composition API feels more like just JavaScript's, so to say. Such a common term saying, "Yeah. This is just JavaScript." Now it feels less magical, but of course, if you start and only know a composition API, I think it's tougher. When I personally explain to people what Vue is, I always start like, "Okay. This is the option API, we'll do all the things that are available there and then we will take a look at the composition API." Mainly because people learning Vue now will definitely need the options API. There are so much content, so many guides, videos about Vue 2 and patterns, they will have to understand, right now there's no way around it. Noel: Yeah. I know. When we had Evan on, I asked him this question specifically, I was like, "I feel like documentation is hard when you're making such a big shift like this." And it's like, "We're aware of it and it's a thing." But yeah, I agree. I agree, the old way isn't going anywhere anytime soon, just because there's so much content there. Alex Lichter: Right now, have you seen the new Vue.js documentation, it had been released? Noel: Yeah. It's good. Alex Lichter: It's amazing. I was like, "Wow." Noel: Yeah. There's definitely a lot of effort going in. That problem is being thought about for sure. Alex Lichter: Absolutely. When I started with Vue, I always felt documentation was already top notch, but I think right now they really adapted to the whole situation with two different APIs and giving code examples for everything and being more clear. I have another friend who came from Angular, started learning Vue and was like, "Composition API." Having a tough time understanding, it's like, "Yeah, look at the staging docs." And they were like, "Yeah. Wow. That's way better." Noel: Exactly. Cool. I guess, other than that, is there anything else in the Vue ecosystem or even in the web dev ecosystem in general that you're really excited about that's coming? Alex Lichter: Yes. I mean, as I said, adoption of Vue 3, sure. But I think in web development in general, I really hope to have conferences again, I'm really missing seeing people around the world. Usually Vue conferences or general web dev conferences, even meetups, local talent, just seeing people, getting in touch with them. It's different to being online and it's better than nothing, but still, that would be amazing to feel again, to meet people. I mean, besides that, I think Vite is still something or to look at and also I'm super curious where this is going. On a broader perspective, the whole topic about, at first, using Rust more and more for JavaScript tooling, which is happening to speed things up, so it will be super interesting. Alex Lichter: I think also about reducing the overhead of server site rendering, more or less doing less hydration. Hydration, just to explain that, is basically the scenario when the server sends the HTML over and then Vue or any other framework kicks in. If you could now just say, "Okay. Scrap whatever the server sent, I will just rebuild it on my own." Or it'll go through everything the server send and then says, "Yeah. Okay. I will basically match that to my own representation." In Vue's case it's virtual DOM representation, and this takes a bit of time. Especially with static content, Vue could also just say like, "Yeah. The static, I know this." Because when the Vue compiled the Vue single file components, it hinted this is static, I don't have to hydrate this because it won't be changed. Having more of these improvements, maybe even to some part of partial hydration, ignore large aesthetic part of the site, will really improve the performance. So this is something I really look forward to and also more investigation in this direction. Noel: Yeah. I feel like we're in this era now, everyone's thinking about performance just way more. Alex Lichter: Yeah. Finally. Noel: For a while for those about the dev experience and now it's like, "Okay. We got to make the web snappy." Alex Lichter: Performing again. Noel: Yeah. Exactly. Alex Lichter: Yeah. It's crazy, if you think about how much JavaScript is being shaped for almost the reason. Performance also, one of the topics, I always try to take care, no matter what it is. Especially if you have SEO concerns, you always need really good performance and KPIs for classic web applications, behind authentication people always like, "Huh. Yeah. If it loads a second longer, I don't mind. People will use it anyway." I'm like, "I don't know." Noel: Yeah. No, it matters. It matters, certainly. I start looking at the user fall off charts and time is money, man, it's real. Alex Lichter: I'm super looking forward to that. Actually I am right now, I'm writing a thesis on this topics, on server site rendering and also maybe there will be some interesting outcomes. Kate: In your spare time? Alex Lichter: Yeah. So in theory, my full-time job is being a student, but in theory. Well, I hope I can finish it this year or so. Kate: Awesome. Well, Alex, thank you so much for joining us. Is there any links or anything you want to point our listeners to. We'll include them in the show notes, but- Alex Lichter: I think mainly if you have any more questions, then of course I think the Twitter profile is the best way to just shoot me a DM over, or just Tweet me, just add me. For more in depth technical post, I hope I'll write more this year, there is also my blog, a couple of cool posts there. I think that's it, if there are more questions then just add me. Kate: Awesome. Alex, thank you so much for joining us and we'll see you around. Alex Lichter: Yeah. Thanks for having me. Have a good one. Brian: Thanks for listening to PodRocket. Find us at PodRocketpod on Twitter or you could always email me, even though that's not a popular option, it's Brian at LogRocket.