paul:
Hi there, and welcome to PodRocket. PodRocket is a podcast brought to you by LogRocket, which is an all-in-one solution for weekend devs or enterprise teams, combining session replay, error tracking, and product analytics to help solve user reported issues, you can find bugs faster and improve conversion and adoption. Go grab a free trial at logrocket.com today.
Today, we have a very special guest, Alexander Leichter, a software developer, open source enthusiast, and all around tech wizard. Alexander got into computers by playing Minecraft. It's probably a source story that a lot of people can hold common to their hearts and now, he's working on some of the coolest projects in the tech world. We're going to be talking about Nuxt, Vue, two of the most exciting frameworks in web development today. And specifically going into some of the changes between Nuxt 2 and Nuxt 3 and how it's more than just Vue on steroids. Alex has contributed directly to these repositories, and we're going to focus in on one thing that Alex, I know you've spent time on, which is the extends thing that has come out in version three. So, welcome to the podcast. It's great to have you.

Alexander Leichter:
Thanks for having me. Yeah, awesome. I don't even have to add anything. That was a brilliant introduction. Thank you so much.

paul:
Yeah, it's a pleasure to have you. So, how long have you been in this ecosystem, the Vue Nuxt ecosystem? It really sounds like you're a pro at it, because you're contributing to these repos left and right.

Alexander Leichter:
Yes. So, I started using Vue and Nuxt in 2017, and I joined the core team in September 2018. So yeah, quite a bit.

Paul:
So, what was your number one most proud contribution for Nuxt 3, if we were to start off on one?

Alexander Leichter:
That's a tough one actually because I think it's not that much code, I would say. It's more sharing examples, like documenting some features and, of course, the [inaudible 00:02:09] on extends, which you already mentioned the feature that I gave at the Nuxt Nation, people were pretty happy about that and seeing that feature coming up because this is something that's, according to my knowledge, only Nuxt as a framework has right now and that makes it quite special. So yeah, I would say that. And I think besides that more, yeah, being part of the community, helping other people, it's not like that one single moment, it's like, wait, that's it. It's more like doing that for more than four years now and obviously, trying to contribute and helping out other developers.

Paul:
Yeah, the talk that you gave on extends really motivated me to check out Nuxt as somebody who's come from other frameworks as well because correct me if I'm wrong here, I'm going to try to tell the audience about how exciting this is, but it was essentially some way for me to take a starter template from somebody else that has worked and directly bring it into my code and say like, Hey, I'm extending this, I'm extending this and I can do it in several layers. Could we get into that? So, why is that so powerful? Why is it groundbreaking and why don't you think other frameworks offer that? Why is Nuxt special?

Alexander Leichter:
It's a very good summary of that. Exactly, the idea is you have any kind of application and you can just build your application upon that. So, it's especially nice for companies to like, okay, we have one core product, but we have several clients that need another white label solution or that need a feature here or an adapter there. Oh, one person uses, I don't know, Shopify, the other one uses BigCommerce or whatever. So, to integrate that, or okay, the branding is different. Usually what you do is you either have different branches with lots of the code changes, you have to merge it back to the develop or the main branch if you want to change all the things in other branches too. So, it's quite hassle to maintain that.
And with extends, you can say, okay, I have a base application that contains all the logic necessary for all the clients, for all the different instances, so to say. And then you can build your instances on top of that, so you don't have to rewrite or copy and paste all the logic again and again. And yeah, then also you can overwrite components to say, okay, this component should be different for that client, for that instance. And once again, it's not limited to one or two layers, you can do that with as many layers as you want. So yeah.

Paul:
What's a layer?

Alexander Leichter:
A layer is basically some kind of application. So, a base layer to say you have this base instance, it can be anything, can even be just a component library and you say another Nuxt project is based on this partial or Nuxt application. So each layer, so to say, could be an own Nuxt application. Usually it's like you start with a component library or some composables utilities and then you say for example, okay, I have a target that should be for websites and another one for apps that use it as a WebView. So we have another small Nuxt application, target app, target web for example, that are based on the base one and then from there you say, okay, that should be for this and this client or this and client or should be, that's kind of white label.

Paul:
Immensely powerful.

Alexander Leichter:
Yes, you can do all the things of that so great because again you have all really grouped by concern to say, okay, if you change something in the base, it has impact possibly on all the other projects, but if you change something and the code base of one certain instance, it will only change that. So you also are more secure when you change code and you're not worried, oh okay, how do I merge that back to the other instances? How do I do that? It's all very nicely grouped and yeah, it works pretty well.

Paul:
That sounds like it's nicely grouped for how do I mark my silos of functionality and update them independently and not have all this mess? One area of concern that immediately pops in my head is like, okay, what if I have because a Nuxtion viewer getting into server-side or static, you can do hybrid rendering. What if I'm running into extends where I have a static site and now suddenly because it's in nice static land and they're throwing some server-side logic at me, what sort of guarantees or processes or things are available in the extends ecosystem and API that let me think about this and keep track of it.

Alexander Leichter:
So the good thing is that's also the config itself, so the Nuxt config central point of configuration that's also in the end merged through all these layers. So for example, if one base layer says like, okay, yeah, that route should be statically generated, then you can even say, okay, let's override that rule, I want everything of that, that being serviced that rendered or say like, no, okay, let's keep that, let's only service that render the new routes I add. So yeah, the big benefit there as well as that's that you have all the control in the bottommost layer, more specific layer to override all the changes or keep them.

Paul:
So it really feels like it's almost like a package manager for the Nuxt land. It's like I know how to take this in and out of a Nuxt project and hook up the pipes. It's not just me installing something.

Alexander Leichter:
Yes, exactly. And the good thing is you can even use with MPM package, you can for example publish a template, as I said before as MPM package and extend based on the package.

Paul:
Very neat. Yeah, this feels like it's in my intro I was like, tell me why this is more than just Vue on steroids, but this feels Vue on steroids because it's as a developer, I can immediately reach for these prefabbed piece of functionality. When we stepped into the podcast you were saying, I asked what is your most proud contribution? You were like, well, it's a lot of documentation process, all this sort of stuff. And I think it really speaks to where we are in the developer world right now where it's like right now it's about efficiency, becoming lean, becoming quick and these types of updates you're talking about are right in line with that. What is another area that you worked on personally in two to three or that you saw your colleagues working on that excites you?

Alexander Leichter:
I'm very happy we have regular team meetings and then triad some issues with discussion topics. So I also really like the whole topic of SEO, similar to Harlan, which is another Nuxt team member. So this was very interesting. In Nuxt 2 we had the trailing slash behavior. So whenever you have a site for SEO, you want either have a trailing slash at the end or not. It really depends, but you want to have a, for every URL it should be either always with the trailing slash or without. So otherwise both are accessible and then search engine, Google could say that is a duplicate content and it's can reduce a crawl budget and it's not good for SEO to keep it very short.
So in Nuxt 2 we had an option to say, okay, either we always have the trailing slash or not and yeah, I was thinking about okay, we don't have that in Nuxt 3 right now, maybe we can somehow bring that back. So I wrote a little issue and then we discussed it with the team. So like, okay, we take a few actions here and this is something I want to implement, well this week's almost over, but rather next week we said okay, want to give the user an opportunity to say, okay, look, whenever you use a Nuxt link, which is the link component Nuxt.js, then it should have always a trailing slash or not. And you can decide that by in the end calling a simple function saying create Nuxt link and then say trailing slash behavior, either add it, remove it or don't care which is the default. So this is something that we came up in the end and that I am eager to implement so that all that SEO topic of internal linking, having the right trailing slash will be resolved easily and it's not a nice part of developer experience for the devs.

Paul:
And a really nice experience for people who just don't have the bandwidth to get into SEO. I mean there are plenty developers who can make a banging website but they don't know how the web crawler ecosystem works. So really powerful. Again, it's right up the alley of it's on steroids. I can put out a production app and I can be a jack of all trades expert, if not. I saw a YouTube video that came out on this individual was talking about how the age of AI and tooling and process is the time for the jack of all trades to surpass the masters of one. I thought it was kind of a interesting precedent, an interesting take on where we're going.

Alexander Leichter:
Absolutely, yeah.

Paul:
Yeah, other teams that you've worked on, other open source teams, do you feel lik, you keep mentioning the Nuxt team, while I say keep, you mentioned it twice already. Do you feel like the way the team hygiene is set up right now is at a really optimal place? You sound really excited and you're smiling when you're mentioning the team.

Alexander Leichter:
I think it's really good. So for all who are not super up to date with the Nuxt team history right now, Daniel took over delete a few months even ago and shared the vision of Nuxt for 2023. There are also several talks being uploaded in the future were at VueJS Amsterdam, Daniel Puya and Sebastian, so all from the Nuxt team, gave interesting insights about where direction is going and the underlying packages and oh no, yeah, I think it's really nice because it's a great collaborative way we can always ping each other to like, "Hey, can we do a programming session? Can we take a look at this? Or I want to take over that area, can I get little heads up or have you maybe an idea how to get into that." So yeah, it's a very, I would say, insightful environment helping each other very collaborative and oh yeah, I'm very happy with the current state.

Paul:
That's encouraging to hear. It's good to hear when there's a cohesive team that has unity behind a framework because we've seen other frameworks maybe lose that cohesion and things get a little messy down the line and it can feel like, when a lot of features come out, it can feel nerve-wracking sort of to subscribe to those if the team's messy. So it's great to hear the cohesion.

Alexander Leichter:
Yeah, true. I mean good thing is now Nuxt 3 came out last year, so until then it was also a bit tough. Okay, what should we put stable release? What do we have to fix? Because obviously we don't want to push out Nuxt 4 right off the window again with more breaking changes. So all the things the people had to keep in mind, okay, maybe can't change that, but we have to find a solution solution for that issue. That I think was also not that easy, but now it's like okay, we can focus on nice developer experience improvement even more pushing out features now it's a really nice time because we can just pushing for these changes with all the difficult architectural decisions that might cause breaking changes, at least from what we see solved or at least for the longer time until Nuxt 4 comes out.

Paul:
There's a lot of planning going into how the developer experience is being shaped.

Alexander Leichter:
Yeah, that's very important for us because I mean we really enjoy using Nuxt and we want that the developers who use it have exactly the same experience. So we also know that there's lots of more things to do regarding documentation, especially of the underlying packages like the server engine, Nitro and all the NJS packages that are used to build Nuxt.

Paul:
 You mentioned Nitro, what is Nitro? So I'm not a Nuxt expert, so please enrich my knowledge.

Alexander Leichter:
Let me maybe even go a little step back based on Nuxt 2, it was like the core, we always try to keep the core very lean so it's not super bloated or everything. And the problem back with Nuxt 2 was like okay, it was all very tightly coupled to Nuxt itself. So with Nuxt 3 the idea was okay, let's create standalone packages that could be used with anything, doesn't have to be Nuxt at all. It could be can you could build your own Nuxt basically with that and one of these packages is called Nitro, which is the server engine and it's very interesting because you already heard that probably Nuxt can be deployed on so many different platforms, so you don't have a vendor lock in and say like, oh, this platform is especially good for Nuxt. Yeah, whatever you need, you can deploy it on GitHub pages, you can deploy it of course like Net5 or self on your own VPS, it doesn't matter even on CloudFlare Workers and then also work on progress.
So that's a great feature and that's actually powered by Nitro because Nitro will saying, okay, we can write the whole server and points, so API routes and end points and Nuxt, but also it will do the whole bundling with roll up under the hood. It's really insane. In the end there's an own tracer for dependencies built in. You could even say it's half a package manager, there we go again to find all the dependencies that might have to be added. For example, for CloudFlare Workers, you can't have all the dependencies. You want to have them bundled all in one file and Nitro is doing all that depending on which presale you pick. So it's very powerful and once again you can use it, I would say similar to let's say Express for example, for any project basically.

Paul:
I can run something that's sort of running Express in a CloudFlare Worker.

Alexander Leichter:
Yes, absolutely.

Paul:
That's hilarious because I mean, we were talking to Daniel and he was talking about, oh yeah, we have this new server you can really run anywhere. And the first realization is all these CloudFlare providers, these serverless people, they want it prevent you from using TCP, they're restricting the Node environment and now it's like, well we kind of figured out a different solution, so screw you guys, we're going to build it anyways and deploy it wherever we want.

Alexander Leichter:
The only point is to be fair, yeah, TCP, that's like an actual limitation. So for example, if you want to use MongoDB, that's a bit tricky, we also had an issue to that because I was playing around with that too. They are like workarounds are solutions for that. So if you for example, have a MongoDB or MongoDB Atlas, it's not a problem, you can still access it in your CloudFlare Workers. So it's not, it's the most ever fluent environment because again, there are some dependencies that are relying on Node, then you can, I don't know, mark and polyfill, but then you might lose functionality. So there will always be a difference. But the good thing is if you write for example, any kind of code with for example packages from njs who meant to be working on any kind of runtime as you said, working environment, Node, serverless, you name it, then you're pretty sure that this will work on all the presets on all different platforms.

Paul:
So yeah, there's still polyfill going on, but the magic here is that this ecosystem's going to take care of figuring out, oh you want to deploy here, you want to deploy here, here's the extra dependencies you needed. Here's how you get Nitro running in the environment correctly. That's beautiful.

Alexander Leichter:
And because again, once again for the whole freedom of choice decisions, so okay, we don't want you to lock into any kind of platform and again, it's a great benefit because you can not use Nitro standalone, which also I did for some smaller side project and I've also seen that and given a little talk about it in Berlin last year, but okay, all these cool njs packages, they're like for storage solutions for file in memory and lots of DBs, CloudFlare Workers, KV Store and way, way more. Yeah, there could be known episode about it actually and yeah, it's amazing to see that others can use that too and utilize the same power because it's not coupled Nuxt anymore. It's really standalone, which also makes it easier to test, of course.

Paul:
It's a whole other product.

Alexander Leichter:
Yes, exactly. And Daniel actually good that you to mention, it builds a little example pulling up with Nitro and several other packages and react to build a very simple prototypical like Nuxtion react just like for conference talk. So this is really fun to see that it's just works with any kind of framework in the end.

Paul:
If you can do it, if he did do it, he did can do it. Somebody else is going to carry on that torch for sure.

Alexander Leichter:
That would be interesting. Yeah, I would love to see that.

Paul:
I love this day and age where we're walking into Astro, you can use any web framework and now I mean the guts of Nuxt internally are starting to walk in that same direction, whether that's intended or not, but it's really interesting. It's really cool to see.

Alexander Leichter:
I think it is definitely intended to say, yeah look, it's open source in the end so if you want to use that then please do it. We actually have it a nice and prepared way. You don't have to copy paste the code, you can just use the package.

Paul:
So browser support in Nuxt, also I was, when I was searching up the updates for what's going on, I found this blog post that said boosting all the browsers. So what is happening with browser support in Nuxt 3?

Alexander Leichter:
Yeah, so compared to Nuxt 2, who still had and still has to support IE11 with U2 as well, there were some things we could do to okay, let's deliver modern non-trans power code to the evergreen browsers and the legacy code to the rest, but now that Vue 3 doesn't support IE11 anymore and hopefully lots of people don't have to anymore. We can focus on okay delivery experience to the modern browsers. So we don't have any kind of legacy fallback because it would not work with Vue 3 as well because it's built on proxies and they're not available IE11. So yeah, what we do by default is deliver, so to say most modern at least [inaudible 00:18:34] as possible based on, I don't know, last three versions, I think, I can check that later and ensure that there won't be any extra [inaudible 00:18:43] coverage slower and bigger send to the browsers.
And besides that, of course it's smaller now thanks to Vue 3's tree shake ability and Nuxt 3's tree shake ability as well. We say okay, if we don't use for example layouts in the application, they're not part of it, they're just tree shaken out automatically and there are so many more improvements yet to come, especially the whole area. Talking about the performance you mentioned asked already the Island Architecture, this is I think something that's really interesting for the future and I love that also Nuxt or the team is going that direction and trying things out there.

Paul:
The Island Architecture is extremely compelling and I'd love to pick your brain for a moment about static site generation and how Nuxt is moving in that direction and we have this continuing continually changing front end ecosystem about, when I first started it was just like plain HML and CSS basic websites and now we're doing server-side and the islands and then static and all that. You really need to be nimble as a front end developer to keep up with what's going on.

Alexander Leichter:
Yeah, it's crazy. Actually I'm writing my thesis right now about the executive topic like server-side rendering and SPAs and all the modern approach and that it's so fast-paced and changing so it's crazy. But regarding the components islands it's called Nuxt, so the thing is Nuxt itself, you can run it without JavaScript just to server-side rendering. You can just say go 0kb JS, that works. For example, the website Nuxt.new where it can just start a new playground for Nuxt project that has that enabled. So it has zero kilobytes of JS, but if you want to go in a direction other like the actual Island Architecture goes, it's a bit more complicated because right now we have an experimental approach that's inverse that little bit to say okay, we can define components that are so-called server components. So they are executed only on the server, so that means no hydration, no extra JavaScript downloaded for them. That works through another handler in that's implemented in Nitro for Nuxt.
So say like okay, I give the component name, the ID, some properties and it'll evaluate and render on the server, pass the HTML and we'll just bring it in the application, which also has the benefit that you can even update that. So if a prop change, we do another HTP request, get the new component. So this is a little bit of inverted to say, okay, let's render some parts only on the server and the majority on the client because again, there's lots of work to be done there. It's still experimental, but just from future perspective, what if we say let's make the whole app itself a server component and then specify certain components that are rendered on the client as well. So that's an idea that we're trying to look into that definitely could be worth checking out.

Paul:
You have to do it that way because you're starting from the server point of view and then you're-

Alexander Leichter:
Exactly

Paul:
... Taking to the client as needed. Gotcha. And we're getting faster websites, faster build times, all this great stuff. Do you feel like having hybrid rendering increases the surface area complexity for front-end developers? Like riffing off of that statement we just touched on?

Alexander Leichter:
Yeah. Already when I was taught the first time or I learned the first time about server-side rendering, I was like, okay, whenever I already got it and explain it to people again and again it's like, yeah, it's such a nice feature but it's adding lots of complexity and now that we can say, okay, this page should be server and that should be pre-rendered before on build time, that should be stale-revalidate, that should be just statically rendered on demand than kept in the cache. That all of course increases the complexity and the mental payload. But if you want to have an application that uses all that, it has to be complex. That's the thing. If you want the best performance, then that's the way to go. That's also good thing is you don't have to start with all that right away. You can build your application then with Nuxt say, okay, let's transform that part into something that's should be rendered on the server only. So change the component to a server component or let's say, okay, let's these pre-render three sites or routes on the server before or on demand. So you can go gradually step by step. But yeah, I think it also adds complexity that's very difficult to avoid, but if you do it step by step and you learn during that, I think it's more manageable than just having okay all the possibilities and doing lots of things at once.

Paul:
Just got to trust the process. You go step by step, add complexity as you need it and I'll also take a moment here to just add if you're adding complexity to your web app and things are getting really crazy and debugging is getting harder, I'll remind our listeners that this podcast is sponsored by LogRocket and LogRocket can help you understand exactly how users are experiencing your digital product. It offers session replay, error tracking, can see heat maps right in the UI, component by component product analytics, frustration indicators can actually, it's good for developers. You can break down error tracking and all sorts of other very interesting metrics about how your DOM is interacting with your users. In addition to machine learning algorithms that surface most impactful issues affecting your users, you can spend more time building a better product rather than hunting through your tools. So yeah, solve user reported issues faster, find those bugs and improve conversion adoption with LogRocket today. Turning real quickly back to the complexity problem. Yeah, when I first stepped into server-side rendering Alex, I had no idea what was going on. The frameworks use such a good job at tying together or abstracting server-side rendering where you don't need to think about it as a front-end developer that you don't think about it.

Alexander Leichter:
Absolutely. But it's also dangerous of course because kind of have to know what's going on and then if there's an error and you're like, okay, what's happening there or the daunting hydration errors, it's always a topic. I wrote a longer blog post about it a couple of years ago. It's like, okay, what is this actually? Yeah, when the server sends something declined, expect something different and then okay, how can that happen? What are typical patterns to avoid all that? It's lots of knowledge that's ideally every developer using SSR has, but it's not the ideal word, of course it's not the case.

Paul:
I feel like there's two types of JavaScript developers now. There's like you can use a framework and code in the framework and still make a production app with all the tools and stuff. But to understand the difference between using ts-Node and Node to run a script is you needed some deep knowledge honestly to get down there and really understand what you're doing. So Alex, who do you think Nuxt three or Vue three, this combo the pair technologies is poised to best serve? Or what does it pivot towards the audience? Do you feel like there's a pivot in audience about who might be using the framework from two to three or a set of customers that you guys had in mind that the update to two to three maybe helps the most? Because it sounds like it's a lot of tooling and a lot of beginner-friendly help and guidelines.

Alexander Leichter:
If you have never used Nuxt before or a Vue developer has never tried it, then right now it's an amazing time to try with all the improved developer experience and the route rules also can have hybrid random mode, combine all these things, that's definitely great, but what you also want to achieve, because Vue 2 is going end of life at the end of the year, end of life and end of 2023, which means inevitably that Nuxt 2 is also going end of life. So if Vue and Nuxt 2 both going end of life and that means we want to ensure that the people who still have the Nuxt 2 application can migrate easier or we can help them migrating in some way. So yeah, leveraging all the things we have. We have a migration guide so things are a bit easier to check on okay, a little checklist, checking out what people have to care about.
Once again, I have to mention Harlan who did a great job and has longer blog post about migrating because he did it for some of his applications too. And I think that's also very important. So everybody who is on Nuxt 2 right now is like, yeah, should I stay? Should I migrate? What's the thing now since Nuxt 3 stables out, it's a really good idea to migrate. And the good thing is you can again do it a little incrementally to start, okay, we can use the composition API for lots of components already because we got backboard from Vue 3 to Vue 2, so we can do a bit of groundwork there. We can then use Nuxt-Bridge as intermediate solutions. Like okay, we can try out Nuxt 3 with a little bit like a compatibility build and then we can say okay that do the functionalities work, is it going well? And then eventually migrating into Nuxt 3.
That's usually a decent approach. What you of course can also do is to, oh, it's very complex application, before we touch everything, let's think about a new architecture and doing a rewrite. This is also valid. Both is definitely going to work depending also on your application you choose one or another of course. And time, budget, one is more incremental of course the other one is more, yeah, just rough cut, which can help. I know from from some of my clients who yeah, that's a great time, we always want to rewrite now we have multiple reasons to do it. Yeah, one of these is definitely advised.

Paul:
Do you feel like the use of extends might come into play for these larger teams trying to incrementally upgrade piece by piece or is that kind of a improper use?

Alexander Leichter:
Yeah, sadly you cannot extend an Nuxt 2 project. So that's the downside. But what you can do of course if you have a larger application then to say okay, how can we slice that properly? How can we silo it and then create tinier applications out of it. So again, one, once again a client of mine did exactly this. They used NuxtJS extend to have a variety, like a big application, chopped it into smaller ones and then in the end fuse it together and have then teams working on different parts of the application and they're exactly in their code base and of course changing something at the base when they want to and they know when they touch only theirs when code might have an influence on others and that's actually a good choice there to do that.

Paul:
Are there any other dev tools that you would call out that have come out recently that might help people either migrate or wrangle with their existing code base better?

Alexander Leichter:
I would say that point when I say dev tools, that there are the Nuxt 3 dev tools who came out and they can be really useful. It's not like for example the Vue dev tools, not a Chrome extension, or like a browser extension in general, it is part of your application and is embedded in there if you want to add that. So this is extremely helpful to see for example what kind of components you use, what routes you use. It is modular so you can even write your own plugin and as a demo, that was really funny, Anthony who built it together with Daniel, Puya, Sebastian, the team in the end, showcase that you can even run Vue's code in the dev tools and then when you change something it'll be transferred through RPC to your actual files. So you can basically code on your application in the dev tools of your application.

Paul:
That's wild.

Alexander Leichter:
Yeah, and it's possible for modules to add more and more things there. Once again, Harlan added an OG image preview together with his package that generates OG images for the website. So you can see, oh that's the OG image generated, awesome. Perfect. And lots of module offers have even more and more opportunities to integrate their module into the dev tools.

Paul:
So lots of Nuxt 3 dev tools coming on, I mean VS Code in the browser RPCing straight to my local host is pretty wild.

Alexander Leichter:
Yeah, it's crazy. It really feels like a cheat code. Also there is the icon module that Sebastian made and Sebastian added a little module in there to say okay, you can look up for the icon, you can just copy paste it, go onto VS Code tab, put it in there and you see thanks to Vue's superfast HMR that changes directly in the browser. So yeah, it's crazy. And again there, sky is the limit.

Paul:
You guys are running on Vite now, so everything is like blazing.

Alexander Leichter:
Yeah, it's so fast. It's amazing, luckily Nuxt 2 had the Vite module as well, but of course there are some implications on that you cannot use [inaudible 00:31:01] and so on, but if Nuxt 2 wasn't built on Webpack then it was a bit difficult for some modules, but in the end, yeah, the change to read was so worth it. If I switch back to Nuxt 2 projects, always like, okay, I have a minute now to go write up some notes or improve documentation, check the code and then the service app and then Nuxt 3 it never happens. It's just straight there.

Paul:
Alex, what do you see yourself getting in the weeds with over the next quarter?

Alexander Leichter:
Yeah, definitely more Nuxt 3. What a surprise.

Paul:
Yeah, yeah.

Alexander Leichter:
I also think I will explore more the SEO performance part of that for sure. And I'm very happy that I can also do a bit more of education, so workshops on Vue and Nuxt, but also JavaScript and TypeScript. I'm happy that I'll give a few more talks and conferences and getting into that, talking to people and kind of understanding their issues. It's also super important of course to understand what are the community's actual thoughts because if you know a tool very well, you know all the capabilities, or at least most of them, but as the average Nuxt user, what do they know? What are they aware of, what kind of problems they have? And this is super valuable feedback to get to then incorporate in, okay, we can improve the docs or maybe write the block post or change something in the code to make things easier.

Paul:
Alex, if people want to follow you to keep tabs on what you're working on, be it the SEO kit stuff or whatever it might be, where can people follow you?

Alexander Leichter:
Yeah, so I am on Twitter as long as the platforms still exist. I think the username is also in the show notes, then it's @thealexlichter, so my full name. Not that easy on GitHub, I am there as well. There my nickname is ManniL, M-A-N-N-I capital L. I think the easiest is going to my website or blog, which I hope to resurrect let's say in the next half year, something like that. Because yeah, I want to write more in-depth blog posts, there are lots of things that I think people would like to know about, not that much suited for documentation because it's too lengthy. Yeah, I think that these are two good ways. I also have Mastodon, that's also both linked on GitHub or on Twitter, so feel free to follow me there as well. Yeah, I think that's it.

Paul:
Great that that's a good host of things to get the website to Twitter and your blog.
 It was a pleasure to have you on Alex. A pleasure to talk about Nuxt 3 and specifically extends, That's cool. I'm excited to read about that.

Alexander Leichter:
I'm glad to hear that you got excited and hope many of the listeners too. And as usual, if there are any questions, please feel free to shoot me a message on any of these channels or on the Discord as well, on the Nuxt Discord. I'm happy to answer all of them and yeah, thanks for having me.

Paul:
Thanks Alex.