Anthony: For framework, we want to make it as minimal as possible, and also providing the best practice. That's what the developer experience that every tool is trying to say that we want to make things easier to use. We want to hide the complexities from the user code to our framework code so you don't need to worry about them. Paul: Hi there and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket combines session replay, error tracking, and product analytics to help software teams solve user reported issues, find those issues faster, and improve conversion, and adoption. Get a free trial at logrocket.com today. We got a true open source hero on the show today. A guy who's been creating some of the most cutting edge developer tools out there. That's the theme of our show today. We're going to be talking about tooling. While also being a member of the core team of Vue, Nuxt and Vite. He's a creator of Vitest, Slidev, VueUse, UnoCSS, the list goes on. Anthony is all about really building these developer tools and he's here to talk about his most recent Amsterdam chat on developer experience with Nuxt. Welcome to the podcast Anthony. Anthony: Hello. Glad to be here. Paul: We're going to hop right into the topic of the show developer experience with Nuxt. What is the big thing that you feel like is new for developer experience in 2023 in the Nuxt ecosystem? One thing you mentioned in the talk was developer experience in Nuxt for the new server, the nitro server that's coming up in the Nuxt ecosystem. What is the Nitro server? Why is it different than the old way that we used to do the server side capabilities and why is it such a big deal for Nuxt and the community? Anthony: So Nitro is a tool that comes out when we build Nuxt3 along the way. So it will be firmware agnostic layer of your server that can view your server functions deployed to any platform providers like Vercel, Netlify, CloudFlare, or even GitHub pages. Without actual configuration it can raise out the environment and know where it runs and to generate the configuration for each providers to get their own capability. It's also possible to build a server in your service worker that runs on the client side where you pretend you have a server, something like that. It basically has a layer to say we app chart the layers of how your server runs and it allows you to, without worrying about each platform specific settings or how you deploy your server. On top of it we'll build Nuxt3. In that sense, that's Nuxt3 inherent all the great features that Nitro provides. Paul: Why would you say that this is a big addition for the community in the vein of developer experience? Anthony: We need to say that we want to build something specific for that platform and that makes your code, vendor lock in to that providers or to that things. So if you ease out the difference between each of them so you can easily switch them so you got more choice and also that can benefit to the larger range of the audience is that if I choose these providers or if my company need to use these providers, I don't need to sacrifice the things I do, right? If the tool I really want to use is not supporting our providers, making not able to use that tools, which is a shame. So that means that we build these compatible layers. It says making things easier and also a fun part is that even though it is beautiful Nuxt, we trying to make it general as possible. So Daniel was also trying to present it in to build a React meta framework using Nitro. So that will make things quite interesting and also if you try Nuxt it's not really complicated. Paul: What do you mean by a meta framework? Can you enlighten me? Anthony: When we say frameworks or when we say libraries we say that Vue itself is a framework but it's like a framework at a certain extent is that Vue only renders how your data has been reflect your Vue, right? But now the Vue also involved with some build pipelines. So you have a SFC, single file components that you can have some custom syntax and you can manage your CSS and how you integrate to your components and also routing the state management. So that we say it is a framework, right? But that basically means that's only for the client side and if you want to have some server side rendering capabilities or if you want more like API requests, a little bit like backend. So that's where the meta framework comes in. So meta framework is built on top of the, we say the client framework is that it's wrapping with all the features you probably need in a small complex enterprise. Paul: You mentioned some key terms that have been available. File-based routing has been around, it's in a lot of frameworks but there's new additions in these updates that have come out, server APIs, there's a bunch of things when you're actually writing the application, it sounds like a lot of thought has gone into the developer experience. Is there something that you can talk about in terms of the server APIs or the server side rendering capabilities or importing that makes the building of the application within Nuxt a better experience? Anthony: In Nuxt2 we going introduced the file system routing is that when you want to have a routing in your app, you just create that file with the same name as a route and with the file structure so Nuxt1 knows how it's being defined and it's reflect to the client side routing automatically. So when you type local host dash four, either one knows to find the pages dash four Vue file to render that content. So you don't need to care about that, you don't need to worry about that, how these things configure it. In that sense we thinking that's a good develop experience is that you don't need to duplicate the past four several times to say okay, we have a page called fold of vue and then we need to mount it to the dash four routes. It's like automatically so you only need to type the past four ones. In that sense we also have that in the server API power that is powered by Nitro is that we can have a dash servers dash API and to say get user dot, you can provide a function to it to return some data and Nitro will automatically terminate into your app X like dash API dash get user. So when you call it, you actually call that files to get the functions so you don't need to set the routings manually. Paul: I love that because if I'm throwing together a web app quickly, that's where I get lost is I have spaghetti code for my APIs in the background. So if it's like file-based, its one way to think about it, it's one mental model you're building that it really excites me. Well when you just mentioned file-based routing as we know that came out in Nuxt2. Is this something new that's in Nuxt3 being able to address the server side APIs? Anthony: Yep, it's a Nitro thing. So even if you don't use Nuxt3 you can use Nitro. So I actually use Nitron alone to build some APIs using the server. It's like [inaudible 00:07:20] is that just building a server that's hosted on the serverless providers? Nitron is a Nuxt3 thing but if you really want to try it on Nuxt2 we also have a project called Nuxt Bridge that's back porting some cool new features for Nuxt3 back to vue two and help you to do the transactions so you can step one by one and go to Nuxt3 finally. Paul: Do you feel like Nitro is a sleeping giant for the dev community? Because it sounds like Nitro can do a lot of cool things and people are really hacking away with Nitro using it in ways that might not just be for Nuxt like yourself Anthony. Do you foresee Nitro like having a bigger space in the developer community than in the coming years? Anthony: Yeah, we do. I think for us or for every developers that you want to make your tools is more general enough to serve different kind of the audience and that story happens on [inaudible 00:08:14] as well. So [inaudible 00:08:15] was initially a view dev server and then we figure out to say maybe this can benefit for other frameworks so we extract the view part in as a pluggings so then it can also help you to say if the plugging API is capable to handle the view part, that can be also enough for other frameworks to do. So in the end we see that [inaudible 00:08:36] has actually built a very great community around it and we have a lot of things like [inaudible 00:08:43] and Solid or some people from React also using that. We have a lot of things built on top of [inaudible 00:08:50] and that was initially built for view. So I think for the same we wish Nitro can be more framework-agnostic tool for other, let's say meta frameworks or other usage can be reused by. Paul: Right on. Could it be used in a completely headless way to power some headless applications like building out Nitro to use as just an API layer? Oh, I want to build something that just manages files and will return data to a front end for a WordPress side? Anthony: That's totally possible. When I want to write let's say GitHub boat, so you can be triggered by some web hooks and then that requires you to have a server have a address for GitHub to call the hooks, right? So it's a bit hard for me to set up a full server and doing it in a VPS to handles all the things, but with Nitros I can just set up API hooks and then deploy it to notify over sale and the serverless function will directly work. Then I can hook the web hooks from GitHub to DERIV code functions. So I got a function that runs on the web. Paul: What about the module system? Could you talk to me a little bit about the updates that came with Nuxt3 and how you can import, how you can template things. Why is it faster for a developer to pick up Nuxt and just pull and code and start a new project? Anthony: That was initially a random idea I had is that in view we introduce the view competition API, which you have a few APIs to call like brief computed watch. So you need to import it from view in every components you have. When you build a lot of components it can be a bit annoying is that you need to type it every time. Maybe I'm just too lazy. I start thinking that maybe since the way that view doing that is that to enable [inaudible 00:10:38] shaking is that if you don't use the APIs it doesn't bundles into an app but for the most of case if you using competition API you will use [inaudible 00:10:45] anyway. You will use computer anyway. So I was thinking that maybe I'll just make it global available, so I just type that globally start with and import it. So then in the rest of the file I don't need to import it anymore. The trail checking issue is that I'm using it anyway, so I starting with a very hack project to doing this way. So it's called View Global API. You install the package, it is injecting all the view APIs into global, which is a bad pattern. Paul: I was going to say do you think this has the potential for misuse? Anthony: That's the problem. And also when it gets big we adding more APIs to the global is that either we introduce API you don't use, which is also a best. So I'm thinking that maybe with the on demand idea of [inaudible 00:11:30] is that maybe we could do that on demand if you using that API. We say we have a registry to say whenever we see a rev function being called, we know it's from view. So we injecting imports really from view at the beginning of that files in the build pipeline. So that means you will still get the benefit of the trail shaking of the ES modules, all the things, but you just don't need to import that thing. It'll detect automatically and import it for you. And also we have the type definition so you will know when you use it, you will know that if you use a wrong or if you just ask how you do it with the normal thing then you don't need to import it anymore. Paul: But it just kind of like does that middleman stuff of rendering down and then importing it during the [inaudible 00:12:16] build that it'll auto import it for you? Correct? Anthony: Yeah. Paul: Okay, gotcha. We talked about a bunch of new features that are coming out and some new bells and whistles. Anthony, what about your areas of improvement that you feel like maybe could have used some more attention? So one thing you mentioned in your talk is this general idea of transparency. What does transparency mean for you in a framework? What does good transparency versus bad transparency look like? Anthony: To talk about this, I think I need to talk about the conventions we introduced like file-based routing or the auto imports or the things that we have in to say that we have a structure of our project. We want to minimize the code, you have to write the boiler place you have to write in your project to say we only want the user to focusing on the logic itself. Not to say how to link with each others or every time you need to start a components you have to copy this kind of code over. That's a bit like verbose and also hard to maintain in the long term. Once you need to change something, you need to change it everywhere. So for framework we want to make it as minimal as possible and also providing the best practice. That's what the development experience that every tool is trying to say that we want to make things easier to use. We want to hide the complexities from the user code to our framework code so you don't need to worry about them. But then it's act some obstructions to say, okay, we have this convention you have to follow, you have to create a file like this, you have to write a code like this. This is not a bad thing but sometimes it can lead to a problem that it increase the cost of learning. Once you have a lot of things like this, it can make it hard to understand why look like this or what to learn in order to use some features. That's kind of being a trade-off of using a tool is that you have to learn a tool in order to use it. I think also the problem comes when you have a lot of things on top of each other, it's hard to say when something goes wrong it's hard to say where it goes wrong. It makes the tools not transparent as you see, it's too complex. You cannot understand what it's doing underneath. Then that's the problem of the transparency. Paul: It's like the abstractions and opinions that the framework is bringing and understanding and how to dig underneath those and build the correct mental model for the fundamentals. That's like how you would coin transparency and you mentioned if you don't have the mental model it can make it much more difficult to find bugs to build out your application. There's this cost, this human cost of organization, of understanding what you're doing. Every time you learn a new framework. It's like you have to learn a new language and so you want to minimize that new language curve that you kind of need to learn? Anthony: Yes. Paul: I'll also take this quick moment to just remind our listeners that this podcast is brought to you by LogRocket because we were talking about fixing bugs and that's literally what LogRocket was built to do for front end devs and teams as a whole LogRocket. It helps you understand exactly how your users are experiencing your digital product with session replay, error tracking, product analytics, a bunch of indicators for frustration performance, heat maps, analytics for the user interface and there's machine learning algorithms that surface the most impactful issues affecting your users and you can spend more time building a better product than hunting through tools and how to fix those issues. So solve user reported issues, find those issues faster and improve conversion in adoption today with LogRocket. Anthony, so we just touched upon what does transparency mean for you in a framework and how you define it? What is Nuxt doing right now in your opinion that is really good for transparency with the update to three and then maybe what's one or two things that you feel like should be addressed or maybe are being addressed and worked on right now that improve it even more? Anthony: I think the transparency thing is a relative thing to say is that that's being the trade-off of having abstractions and that probably something that cannot be completely solved, but we are trying our best to explore how we can improve that in that area. Recently we announced a tool called Nuxt Step Tools that's create a planos inside your app to expose some internal things of your app and also we want to be able to help you to find the bottleneck of your performance issues or also providing the documentation as you need it. When you have a documentation side that can be a long list and we have a lot of features to provide, but is that when you're building an app, you're probably not going to use all the features, you only use a set of them but then you're looking at the website, you need to figure out what you are using and where to look for your documentation. So we are thinking that maybe with the Nuxt Step tool is a that time virtual tools that it knows which features your app is using and it can provide the documentation at the right times, at the right moments for you when you need it to say that if you have a file-based routing, it can have a page to say okay, file-based routing, we follow this convention for dynamic route and also if needed we can provide a link to a full page you can see. That's something we want to improve and to see if you have something broken in your app, it can help you to identify where is it or help us to identify where the bug is in framework. We can fix that. Paul: What do you think is one of the most unique features that the Nuxt dev tools bring? So you mentioned that it does this logic for us of gluing together this idea of here's how Nuxt abstracts, so if maybe file-based routing, here's what the Chrome run time spits out, it might be confusing and so it helps us understand that by giving links to documentation stuff. What are some other features that you feel like people should be aware of if they're opening up Nuxt dev tools for the first time? Anthony: So Nuxt dev tool will say we have components auto imports, we have the API's auto import and we have a registry which is in the memory of the code is that normally it is invisible for users. You don't know which modules being registered as auto import. That's a list that you can go to the DTS file to look at them, but it's horrible. So we want to make some UI to say you can see all the list and categorize. You can search for them to say if you have multiple components we can build a relationship between each component. So once you import that component, you can see how many other components these component is relying on. If I really want a page that's very minimum or if I want to avoid some components being imported accidentally by the others, I can check the component to see if it's relying on some components I don't want. And also we have a inspector. So it's a bit like Chrome's inspector. You can pick out an element to inspect its properties or it's class and then you can change them. But at the framework level is that you have multiple components that's contributing multiple elements. One component can have a lot of elements and [inaudible 00:19:33] is the components and you can see them in the DON tree but that means that if you modify them you cannot write back to your source code is that when you refresh it's just gone. Right? So you want to find your code for that element. Currently in Chrome, that tool it's not possible is that it's not aware of what framework you are using or it does not communicate with the backend? With Nuxt dev tool we have the context of view and also we have a server so we know which Don elements comes from where in your source code and we know that in specific line of it. So you can inspect the components to click it, it will jump directly to your editors and add that line so you can directly change it. Paul: That's incredible. That's something that would take me so long if I'm writing some raw react code to figure out which component imports from which component. And so the reason why this is possible is because you're building up, you said some sort of registry in the background. So this Nuxt devs tools has an understanding about how the actual code is structured semantically in your code editor. Anthony: Yes. Paul: That's really neat. So you also mentioned that it's designed to be extensible. Do you already see people extending this and doing plugins? Is that what you mean by extensible? Anthony: Yeah, it's actually quite fun. In Nuxt I can think it's a very great module system. It's a bit like plugins to Nuxt or extensible feature for Nuxt, but it can do a lot of things. It has a very good hook system. You can have a lot of internal information of Nuxt and you can do a lot of things like install some transformations at the build lines or injecting some code in the client side. So the module can do a lot of things. That's say that a module can say contributing CSS framework or just use my [inaudible 00:21:21] for example. So it was against all your code to generate some atomic CSS which is quite similar as [inaudible 00:21:30]. So we have a Nuxt module for [inaudible 00:21:32] that say it will install a plugin for a pipeline and also inject some client side code to do the refreshing is that for the integration like this or for any tools is that we build integration for Nuxt. We want to have a way for those integrations also providing their internal state as a virtual UI or something. We can have a list of the tokens you have or we can have each file which file contributing to which file using these utilities of CSS or how big your CSS is generated. So with the modules with Nuxt Dev tools, a module can hook into Nuxt dev tool to say we are contributing a UI view to say with this module installed, we can provide a playground for you to play with it with that certain integration. Paul: Do you feel like Nuxt dev tools is setting a precedent for a new way to interact with a debugger in the browser? Anthony: We hope that starting a trend we would like to see other frameworks also doing that. Also for the integration part, if I build something like the CSS framework, I can provide a set of UIs that can run each different frameworks, that would be great. Paul: You could like AB test between different ones. Anthony: Yeah. Paul: That'd be really cool if it's setting a new precedent because it's almost like you guys are identifying this layer of information that was missing. Anthony: Yeah. Paul: That now maybe people might start providing in their libraries and make it much easier. Anthony: That would be fun to see. Paul: And exciting for people who are getting into web development. I remember the first time I ever did React and I see that too many renders too many times and you get freaked out and it's a very cryptic error message. So this sort of toolings things are very good for people stepping into it for the first time as well. So where do you think the Nuxt ecosystem is going to evolve as a whole? It almost feels like in Nuxt3 it's all about tooling, documentation, plugability, like you mentioned, trying to prevent vendor lock in. It almost feels like Nuxt is setting a bunch of precedents for how development is done on the web and the [inaudible 00:23:34] team and all these technologies. Do you think in the coming year you're going to continue to move in this direction of focusing on tooling and focusing on developer experience? Anthony: Yeah, I think I'm really passionate about the tooling or developer experience is that even I don't do it for anything for anyone else, I do it for myself. I'm really happy about it is that I will just make my workflows faster and I can enjoy to do more about the other part of the thing. So I don't need to do the label work. I can build more stuff to build more interesting stuff focusing on the logic of them. So that's why I am being very passionate about the tooling and also if that tools happen to help the others and that will makes me feel that, oh, the time I spent that saves a lot of times from the others. That would be a very good feeling to say I'm doing the real contribution to the world. Paul: Anthony, if people wanted to improve their own developer experience, stepping outside the Nuxt in the view ecosystem, what are some other things that you found help accelerate your life, streamline your processes that you might want to turn other developers and engineers onto? Anthony: Id I had to pick one, I think the quite interesting one for me is a project called NI, which is under maintenance space. So you can see that github.com/antfu/ni and it's short for MPM install. So that's a project that I built along the way of when I was organizing my show file to analyze. Nowadays that's in the front end world that we have quite a few different package manager, like MPM, yam and now PMPM and also [inaudible 00:25:20] is also doing package management as well. So if you go to projects for only others or for any project, they may choose to either use Yum or PMPM or MPM. So you have to be very careful which tool they are using otherwise it runs the wrong command, the app will not work, so you need to remove the node modules and do the install again. So that's something I'm being annoying for a while. I'm thinking that maybe I can just check which package management the project is using and I will just call the name, call the corresponding package manager. So I write a shorthand called NI which is just a really fun project for me to solve my own problems and now it's getting a bit popular. So people find it useful to boost their own workflows. I think that's something that you can feel the difference very quickly. Paul: The node ecosystem, I love it, but what a mess even between a yarn like yarn one, two and three, I don't even know what is going on anymore with yarn and it's like switching between package managers is a hell of a time. So I would never even think about that. A simple alias tool that has some logic about how the ecosystem works and does it take care of things like removing my yarn lock, my PMPM lock and reinstalling as needed if I mess something up? Anthony: No it actually- Paul: No? Okay. Anthony: Always use the right tool so you don't need to worry about that. And it said you see that when you install package, you use MPM, install some package and in Yum it's Yum and some package. You need to remember the sub command and they are sometimes different and how they handle the arguments are different. So in these tools I'm just normalize it so you just rung it without worrying about which tool is underneath. Paul: So github.com/anthonyFU/ni? Anthony: Yeah. Paul: For NPM itself, I love that. I'm going to go check that out after we finish our podcast. If people wanted to find out more about what you're working on within the Nuxt ecosystem because you have your fingers in a bunch of different things like you're mentioning your CSS framework, naturally if you're writing a CSS framework and about the new Nuxt dev tools, you're going to make it compatible and put in a bunch of great things. So if people wanted to follow the Anthony Fu ecosystem and see what tools you're putting out, I'm sure people can subscribe to the GitHub, github.com/anthonyfu, but what about Twitter or Medium or any other places where you might have content for people to follow? Anthony: I will post my latest update on Twitter and also master long. So my Twitter account is NTFU seven and my mastodon is at antfu/webtools, W-E-B-T-O-O.LS Paul: Dot LS. Very important. Anthony, thank you for your time. It was a pleasure having you on and I hope you invent some more great dev tools to help our developer ecosystem. Anthony: Thank you.