Noel: Welcome to the PodRocket podcast. I'm Noel. Today we're welcoming back Daniel Roe. Daniel is a framework architect and Nuxt core team member. He's joining us today specifically to talk about his latest conference talk for Vite, how Vite Makes Nuxt Possible. Did I get that right? Daniel Roe: Yeah, that was it. Noel: Awesome, awesome. How are you today? Daniel Roe: Do you know, I'm well. It's been a good day today and I've got a cup of hot chocolate, which is absolutely the right call right now. It's in the evening in the UK. It's the kind of weather where a fire would absolutely be the right thing to have and I feel that my hot chocolate is getting me a good part of the way to the cozy autumn feel. Noel: Oh, nice. Yeah. My wife and I got back from a trip to Scotland a week ago, and we were at this little bed and breakfast near Portree, I think that was the town. They had little fires in the, I don't know, reading parlor room every night. It was excellent. It was so good. Daniel Roe: That sounds incredible. That's a good holiday. Noel: Yeah, it was perfect. It was quiet and calm. Scotland was lovely. I'd never been north really of London at all, so it was great. Daniel Roe: Yeah, there's so much in the north. North Umberland, just south of Scotland, is an amazing county to visit as well. It has I think more castles per mile than any other place in England. And for England, that's saying quite a lot. Noel: Yeah, there's so many. Yeah. Daniel Roe: Exactly. I know. But yeah. Yes, you tend to go to Little Village and ther're these blue plaques that say things like, "Charles Darwin's first tortoise lived and died here," and that sort of thing. Noel: No, it's all good. It's all good. Cool. All right. Well, I could talk about travel and English geography at length probably, but let's jump in a little bit. Daniel Roe: Excellent. Well, okay, it wasn't the direction I was expecting to go in. Noel: No. Well, let's talk about Nuxt. Maybe to even step back a little bit further, can you tell us a little about who you are and how you found yourself involved in this ecosystem? Daniel Roe: Sure, sure. So I'm one of the team members of the Nuxt team. Nuxt is a framework for building web applications, we have our focus on developer experience, which I guess probably most very much would. It's built on top of Vue. Nuxt is progressive, so it tends to be very easy to get started whatever you're building, whether it's enterprise or personal, and then it's progressive, so you can customize it to your heart's desire on top of that. So I joined the core team probably just over a year and a half ago. Before that for a couple of months, I was a maintainer I think. And then before that, just an occasional contributor. So I was building a SaaS startup using Nuxt. And so really a lot of my appreciation for Nuxt and also the direction I want to take things in, it's all based on personal experience. So this is the do what you'd like to see. Noel: What was your draw to Nuxt originally? Why did you choose it for your project? Daniel Roe: So originally, the first time I came across Nuxt, I had a small creative agency and we were building sites for clients most often using WordPress. And we had a great stack on top of that. If anyone uses WordPress, I totally shout out the Roots Stack using Composer to manage dependencies for WordPress and some really amazing other things that as well, like Trellis, which is a great DevOps platform, all kinds of cool stuff. But I think it was actually Jeffrey Way and the whole Laracasts instruction course platform that first acquainted me with Vue. I thought, "This is actually a really cool idea, this idea of declaratively stating how the data model of your application is connected to what displays on the screen." And this is shared across lots of frameworks, React and Vue, but it was new to me and I really thought it was a bit eye opening. And so I started playing around with Vue and moved the agency a little bit. We started doing much more in the way of Vue based applications, and I was looking for a framework built on Vue that would do some of the work that we were doing to render stuff to HTML rather than just producing a template with some curly braces in it, which was what we were doing to start off with, and found Nuxt and really never looked back. I still remember one of my team when I told him that we were going to switch this new project we were working on from WordPress to Nuxt, he gave me so much grief. He was so annoyed because I think we were maybe even two days into it, and he had started some work and I just turned everything over. But he came completely around and he is a total fan of Nuxt now as well. So that was my way in, WordPress to Nuxt. Noel: Nice, nice. Awesome. Yeah, I feel like people just getting into the Vue ecosystem, it's often that story. I mean, it's a similar story to a lot of the more modern front end frameworks, which is like, "I tried it once and it was great and then I never really thought about it too much anymore after that because my problem was solved." Daniel Roe: It's moving from the declarative, "I want something to happen on the page, I'm going to write some JQuery that's going to go and find the thing that I want to change. I'm going to make it change when something happens, which is also going to..." That's a very intuitive model because you're thinking of webpages as static first. There's this canvas and you're going to have to draw on it, and if something happens, you're going to have to change that or rub it out and do something different. So it's really when you first encounter something like Svelte, whatever, I don't know, it feels like your world has turned a little bit upside down thinking about an application as something that isn't static by default, that is dynamic and reactive by default. As you say, it's once you see it, you don't go back. Noel: Yeah, and I think that that declarative nature, even for interactive apps maybe or highly interactive apps before that had a lot of computed [inaudible 00:07:32] and stuff, as you said, you're managing them with JQuery and stuff. I feel like it's almost surprising to me reflecting now that that was the norm that was settled on for so long because there was so much state that was there but didn't really have any tangible reason for existing other than just, "Oh, we should just be updating an object that then should be being reflected on the DOM." That is so intuitive and so common a pattern, that it's almost surprising that it took us as long as it did to get here. Daniel Roe: And it's such a source as well of buggy code. I mean, I say as someone who's written my fair share of buggy code, but the idea that you are responsible yourself for flushing data changes to some user interface. That is the thing where if you're responsible for it, you're just so many opportunities to shoot yourself in the foot. And I think actually in a similar way to the whole move towards state machines and the idea of your application having discrete states and clear ways of moving between them, and also discrete states that can clearly be debugged and tested, is a similar thing because I see it as analogous, I don't know if you agree, but having a handful of Boolean toggles that are pending true or false. [inaudible], true or false, has user clicked confirm button, true or false, that kind of thing, just multiplies the possibilities without giving you any real way of managing flow from one state to another state. And I think it's a similar kind of thing in terms of debugging and the opportunity to introduce new bugs without realizing it and managing state without having something that's going to be sitting there, ensuring that your state is then up to date with what you're displaying, I think is a similar thing. Noel: Yeah, no, I totally agree. And I think that analogy is fair. I think the front end in particular to me is maybe a little bit clearer. I guess the domain is more controlled versus in the server in more just generic computational mediums. It's like, well the state machines are nice. There could be a lot of overhead in certain types of computation or something that are occurring. But I think, again, the front end in particular is such a clear case of the state should be largely observable. There's not that much computation actually happening on the front end as we think of it, hard logic stuff going on that I think it's an easy to see the benefits very tangibly very quickly for declarative reactive programming in front end frameworks. Daniel Roe: I mean, exactly because the more you do that, the more that your code becomes about manipulating data and you stop being so concerned about how you are changing a user interface so your code becomes much more business focused rather than UI focused. So it's also a really helpful thing because that naturally leads you to use the tools of the browser like CSS to do the visual transitions and things like that. Unless there's a really strong reason for, say, using animations that have to be controlled by JavaScript, as in it's one thing to toggle a class on and off, but if you're talking about manually ticking a counter or something like that to move something across the screen, to me, that's a bit of a code smell. You want the browser to be doing what it's best at and actually this move towards thinking about the data of your application as the source of truth and then just letting stuff naturally happen on the screen. It's the similar thing, I think, you talk about a class on or off and then you let the browser do the animation part rather than trying again to manage that comparatively. But I mean, in terms of thinking about the state machines, I mean, I certainly agree using a library like XState is of course great, I mean it is an overhead, but even adopting state machines in principle, so not having a toggle true or false for pending, but having some kind of status variable that has a discreet state, but so there's only one, so you're either going to be in state pending, state fetching data, state data error to state, I don't know, whatever it is. And as the poor mans state machine, it's not quite the same. It doesn't have the clearly defined logic for how you move between states, but at least it gets you away from the weird world of success is set to true. That error is also set to true. What do I display on the screen? Noel: Oh yeah, I completely agree. And yeah, it seems like we're pretty clearly on the path of even the front end and the back end, and maybe it's easier to talk about the front end specifically, just get the data from the server, do whatever you need to do and update the front end accordingly. We could be constantly polling, we could be having updates pushed in a million ways, whatever the data is that's coming down from the server, do the thing, transform it and set it. Maybe for offline applications, that's not super clear and you have that data coming from somewhere else, like user input on the device is the primary input source, but just we can always take the state we're in and figure out what should be being displayed on the screen and then handling the next state of input is not that hard a thing to comprehend. We've solved that big problem of, yes, but what about if X is true and Y is false and that is, whatever, seven? And I think that reality is becoming much more, I don't know, tangible and we're having a lot less tricky front end bugs because that trend seems to be occurring. But I don't know, I'm way off track here, we're way down in the weeds. Daniel Roe: No, I think you're right. We are moving in that direction. Noel: Yeah. But let's go back to your talk. So how Vite makes Nuxt possible, I guess someone coming in from the outside that knows that Nuxt exists, and it existed before Vite, would say, "Well how does it make it possible if it existed before?" Daniel Roe: So that's an interesting question. So one of the things that I've been probably the majority of my development on Nuxt over the last year and a bit, has been focused on Nuxt 3, actually which is a completely rewritten version of Nuxt from the ground up. There were a lot of new technologies available. So Nuxt 2 was a little bit limited in its development because it's a major version to it, so you can have no breaking changes in Nuxt 2. Nuxt 2 is tied to Vue 2. So there were a number of technologies that came to a major version at the end of the Nuxt 2.13, such as webpack. Webpack moved from webpack 4 to 5 post-CSS, moved from post-CSS [inaudible]. And Vite was born as well in a similar timeframe as well as Vue(3). So we suddenly have all of these new technologies around including Vite, which is great, but also webpack. There's a new major version of webpack with changes you can't upgrade Nuxt to without breaking a lot of people's applications. And that's one thing we don't really want to do, not deliberately anyway. And that was also partly maybe why I would say Nuxt 3 took as long to develop as it did because it was a case of everything has to be pushed to Nuxt 3. And so every new technology or upgrade that we need to make, it's all starting to happen in Nuxt 3 and we don't want to defer anything because that would then be another major version to Nuxt 4. So it became a really big project, a pretty impressive and exciting one with lots of benefits. And I think the people who are using Nuxt 3 in production now, at least the ones who talked to me about, they tend to all think it was a really good move and a great experience for them. But one of the decisions we made early on was that we wouldn't just keep webpack compatibility with Nuxt 3, which we could have done, we could have kept webpack 5, but Anthony Fu, one of the team, developed a library called unplugin which allows you to write plugins that work in lots of different ecosystems, esbuild and Rollup and Vite and webpack, and maybe more. The idea is that there's this consistent interface for writing them, which not unsurprisingly resembles a Vite-like plugin or a Rollup plugin is effectively the same thing. The unplugin takes care of transforming that into say a webpack shaped plugin when it's needed and so on. So we had to do that and we've had to make sure as we've added new features that's not been deeply tied into one bundler only. Even now actually, you can bring your own bundle to Nuxt if you write your own implementation, it just has to have an object with a bundle method and you can provide that to Nuxt and it will call that, and then whatever it produces is the Nuxt bundle. So it's built to be extensible, but how does Vite make Nuxt possible? Or I guess probably it would be more accurate to say how does Vite make Nuxt 3 possible? Because a lot of the things that Vite enables are some of the new things we brought to Nuxt 3. So I don't know how much in detail you want to go, but a lot of the things that we've done have been built on Vite plugins. So I did a little count before the conference and discovery of 11 feet plug-ins in our Nuxt part of our app. And they all do different and important things. A lot of them are standalone. So you can effectively develop a new feature in a plugin. You can integrate it with Nuxt. And then that's a feature that can be rationalized on its own, it can be understood and comprehended. You can see how the plugin works. It doesn't tend to interact hugely with other parts of the app, the core Nuxt internals I should say. And so that's a really, really good and agile way of developing from my point of view. So we have a number of ad hoc modules, which is our internal term for them, things like the view router integration. You don't have to have view router integration Nuxt, you can have a minimal app without a pages folder. And so all of the way we built that was in a module on its own. So easily extractable, it can just disable itself if it's not needed. And that means that Nuxt itself can be quite composable. And I mean, it's the best way of adding functionality to Nuxt. If a user wants to contribute in somewhere often, building a new module to make a proof of concept before, then making a PR to Nuxt and adding it to core is the best way to go. And I think all of that means we're able to work quite quickly with Vite. So you spin up a new module, you create probably a Vite plugin as part of that, you write it using unplugin, so it works with webpack and the rest of the ecosystem. You build a feature and it is just glorious how quick that whole process can be. And I'm talking about it as though that's just Vite, it's not just Vite. I mean, the whole plugin model and the way those plugins work and the intuitiveness of them as well is really due to Rollup, I think. I mean, the format is mostly the same. That is how the plugin works, it's how the pipeline works. And as somebody who's written webpack plugins as well, I think writing Rollup plugins is a lot easier and a lot faster work. I don't know, do you feel... Noel: No, no. You answered the question I was going to ask was the way that you were describing about describing the utility that Vite was bringing, I was going to say it almost sounds like you're just saying that Vite is a convenient, I don't know, bridge or implementation maybe of Rollup plugins that empower this whole ecosystem to work in a more modular way. So that was the only insight I was going to offer. I've never written a webpack plugin, so it's hard for me to totally empathize with that struggle. I'll have to take your word for it. Yeah. Daniel Roe: Yeah. Well, you don't have to now. You can write it with unplugin and you'll have to plug it out of the box. Noel: Right, right. Daniel Roe: Yeah. So I mean, that whole thing has been good. And I will say that Nuxt 3 development has been quite quick in terms of implementing new features from idea to RFC to implementation has been quite quick. And so it's been great to be able to do that. I'm not even touching I guess on the speed of Vite, which is the major thing I think that made people adopt Vite so quickly in the beginning because it wasn't the first framework that offered this idea of, "Let's use the dependency graph of a page or a component to just determine what we build." I mean, there was Snowpack as well, which was really groundbreaking and innovative and this idea of the minimum required. You don't need to perform some massive build before you can make a first request to your own server because you're not displaying everything, you're not loading every component. Why should you have to do all of that? And I think the fact that I can just spin up a reproduction or a sandbox or develop something in a matter of seconds or even milliseconds as opposed to 30 seconds or a minute, I mean, I probably don't even have the ability to count how much time that saved me. Yeah, it's definitely- Noel: I agree. Yeah, it's profound as soon as you do it. We had Patak on a couple times but a while ago and I couldn't quit talking about how incredible it is the first time you spin up a project. As it grows, it's just like, the first time you spin it up, it's really fast and it keeps growing. You're adding to it and it's like, "This is so fast." It's just almost a whole new, I don't know, the whole feeling of dev is different. It's so responsive so quick. It's the fastest feedback loop I've ever really had as far as development experience. Even if I've got a test suite running against some little Express service or something on the back end, I'm making changes to it. The feedback loop is still longer there than just control S, update, less than a second a lot of the time. It's staggering. Yeah, it's really cool. What else in Nuxt was empowered by this commitment to shifting to Vite? Daniel Roe: So I mean, quite a lot of we do is implemented with Vite and I guess that's probably what... I mean, nothing in Nuxt can be only influenced or due to Vite because we are a multi-bundler framework. We have to be. So I think probably the only major feature we have at the moment, which is Vite only, apart from things which are unique to Vite itself, is our style in lining. So at the moment, we hook quite heavily into the Vite build process to extract CSS from components as they're being built. And so normally in a server build, you don't have any CSS. The CSS is just omitted entirely and it's in the client build as a separate CSS file. And in some cases, I think if you're using the Vite legacy build, you might have CSS in line in your JavaScript, but in general that's something everyone is trying to avoid. Better to have it in a separate file that the browser can natively understand without needing some JavaScript to apply it to the DOM in the form of injecting a style block. So we had to work outside the normal constraints and so we extract CSS when the app is built and we create a parallel entry point for the styles of the application. Now when an SSR app is rendered, forgive me, I'm sure you know all of this, but- Noel: No, it's good to expand. Again we have listeners from all walks of the development ecosystem, so yeah, go ahead. Daniel Roe: Okay. So when an SSR app is rendered a Vue app in particular, every component that's loaded to make that initial HTML response leaves a record of itself in a little array, or actually a set of component IDs. And then we are able to know what JavaScript bundles to preload in the HTML because we know that these will be required on client side in order to hydrate that HTML, for example. But this also means that if we know what inline styles match or are needed by those components, we can also inline style blocks for each component. And this is a very common way of developing of course in a Vue application because you have single file components, each one has its own styles and there may be global styles as well, but typically, you're not writing a Vue app with a parallel CSS file with styles that are related to your component but not imported by it. You're typically writing it in the same file or directly importing it into it. So it works quite well. When we build the app, we're able to build this tree of dynamic imports. So you have a registry, an object which has the component IDs associated with dynamic imports. So when you know that, you don't have the cost of loading all the styles into memory, only the actual cost of the registry, the phone book. And then as needed, we can then dynamic import the chunks for each bit that's loaded on the server and render those in the HTML. And in fact, if it's not needed, if the user turns that functionality off, then there's actually no cost at all to having that information because it won't be loaded and not even the registry will be loaded. So it's an interesting implementation, it's still a work in progress. So there are still some things that we would like to do. For example, the tricky bit is what happens, say, on subsequent navigation? You might be able to ensure that you have all the styles inlined to match that first page, but what if you, I don't know, hit a button and some new component appears? Or if you perform a client side navigation to another page, you need new styles? So you still need to have CSS in your public directory and you have to make a decision about loading it at some point. And ideally you don't want to duplicate the CSS. The benefit here is if we can have enough CSS to accurately render the page so you don't get any shift, and then everything that isn't needed, you defer as long as possible so it doesn't interfere with the user experiencing and being able to interact with the page. And so finding that precise balance is something we're still working on, but it's certainly better than it was and it was a feature missing from Vue entirely in Vue 3, but which existed in Vue 2, so it's nice to be able to bring it back a little bit in Nuxt. Noel: Yeah, nice. I hadn't considered that problem of once you're in the client and you're doing client side navigation or something, you'll need to fill that request. How do you do that without having to build all styles twice like you said? What is the answer? What are you guys trying to do? Daniel Roe: If I knew the answer entirely, so I think in Nuxt 2, in Vue 2, there were effectively two alternatives. You could either extract the CSS into separate files, in which case there would be nothing inlined from the server. Or you could keep the CSS in chunks in the JavaScript, in which case there would be no separate CSS, but all your JavaScript files would be twice or three times as big because they've got big chunks of text as CSS chunks in them. And the way then that happens is entirely consistent. When that component is loaded, it inserts a style app element in the DOM and that's how the CSS gets applied. We are adopting a hybrid model, so Vite does this by default. So Vite by default, as you navigate through your app, Vite adds links to the CSS that is required. So Vite adds it to the head, the browser knows then to make the request, downloads the CSS, and so you get styles applied for free out of the box, that's just Vite doing it. So the challenge though is delaying that behavior because if you take an app which has no CSS injected at all and you load it with Vite on the client side, then Vite will immediately add a link to your CSS when the preload help [inaudible]. So what we are doing is we're basically in the Nuxt minor version of Vite, if I recall correctly, we will have the ability to handle the IDs that are preloaded and not just the IDs that are preloaded for JS, JavaScript chunks, but also the CSS chunks, which means we can actually use a global helper that lets us make decisions about whether or not this CSS has already been noted, say, by being inlined in the server, or whether perhaps it should be delayed in terms of its loading. That's something we've not implemented yet, but I think that is the solution basically to let Vite continue to to do what it's doing, but give us a little layer of control so we can tweak those knobs and try and optimize that process. Noel: Nice. Yeah, that's very cool and not something I'd really again spent much time thinking about, especially at the framework layer. You guys being able to step in there or if someone weren't using Nuxt but they were using Vite, would they be able to use any of the work that you guys are doing in any way? Daniel Roe: So that in particular, not yet. Although I have opened a conversation with some of the other framework offers in the Vite community to basically see if there's any value in taking this back into Vite so that authors can use it. That's pretty tied into the Vue implementation because it's Vue components were noted that other IDs to this set, but that's not entirely different from other component based libraries or frameworks. I think Svelte does something very similar in terms of their SSR implementation. So I think it is something that could be quite useful and hopefully we'll do that. I mean, it's also not the first time that we've done that so early on, I think it was still Vite 2 at that point. In Nuxt, we built an implementation for making your website portable. So the base URL of your website, which is normally just a single slash but could be changed to something else, some prefix, we made that configurable, we also made it configurable where your JS was, whether it was on a separate CDN for example, or maybe in a different directory, not an underscore Nuxt directory, but something else. And all of that can, of course, be configured at build time, but we put a lot of effort in to make it dynamic so it could be configured at run time. So for example, if you in your development environment were building your app, wanted to preview it and test it, but just keep all your assets locally, but in production you have a CDN somewhere else, it really doesn't make sense to have the concept of a separate build of your app that you have to do just to change that URL. Ideally, I mean, if you're following 12 factor methodology, one of the things that you want is to be able to control bits of your application with environment variables rather than having to rebuild it. You should be able to have a docker image that you can use in your staging environment and another, then the same image that you can use in your production environment and the same image that you technically could also use in your... That's the ideal because you're testing the same code, the behavior might be a little bit different and the environment might be a little bit different. And so we built that for Nuxt. I think we were quite proud of it, but I was really delighted, I don't remember exactly how it happened, but Mattias, Patak and I were chatting about it and I said it would be great to get this into Vite. It really feels like where it would belong. And actually he said that there were a number of other framework authors also wanting the same thing, to have this concept of assets for example, which are relative to the the folder wherever those assets start. And so I think the whole Vite team put a lot of effort into coming up with a good API, a good understanding of what that would look like, how that should be configured, what the right default should be, and how it would be possible to customize it. So we currently are making use of that to customize how JS chunks, for example, are rendered into the JavaScript and it's even possible to customize them in CSS. Although runtime CSS is a little bit more complicated if you have an extracted file. I still have the idea that it might be possible to do with environment variables, but it's not always possible. There's a bit of a to-do asterisk around that. But that's a very specific use case for basically being able to inject CDN URLs into image sources for example in the CSS. That's not an easy thing to solve, but it is a tiny, tiny edge case basically. Basically it works and it works in Vite core, which is great because I mean it's about moving responsibility to the right place. So again, there'll be things in Vite that should be in Rollup, things that are in Nuxt that should be in Vite. Things in end users applications that should be in Nuxt. And so how can you get them to the right location where they can be maintained and kept stable so that at the end of the day, it all works smoothly together. And yeah, I was really pleased about how that worked. Noel: Yeah, nice. I have some more questions in this realm, but before I get to them, I do want to implore listeners quick. If you're enjoying the podcast, follow us, subscribe on your platform of choice, do the thing, help us figure out what you guys are listening to and what's good. Yeah, it just helps us know where to focus our energy. Yeah, so I'm curious, one of the questions I have on my notes here too is how do you go about this decision making process at the layer you're at in this whole, I keep using the word ecosystem, but like you said, there's the builder and the bundler and Rollup and all this stuff and you guys are this very pivotal piece. What are the specific challenges you think, being on the Nuxt team, that you guys face and how do you again decide what tooling to tie yourselves to and where to focus your energy? Daniel Roe: That's a good question. We've certainly built a lot of tooling as part of building Nuxt 3. If you've not come across it, there's a GitHub organization called unjs, which it's basically started by a number of us on the Nuxt team, but by no means limited to Nuxt. In fact, that's the whole point of it. unjs stands for universal JavaScript, and the aim is to make JavaScript solutions to problems that are out there that work universally. So they don't work with just one framework but cross framework. And they don't work in just one environment. They're not node specific, but they work across environments. So whether that's serverless or somewhere that's more worker based like CloudFlare or Dino. And so we've done a lot of work creating tooling as part of this. And I think if anything, my own self criticism is that maybe we've been too eager to create too much of the tooling ourselves rather than relying on other offers. I mean, having said that, how do we decide to adopt tooling and find libraries that do what we need to do? I think a very important thing is that we don't want the implementation details to bleed through. So for example, I mean, this is a particular example of that, but we've just adopted a great little tool called Ultra HTML, which is written by a guy called Nate, Nate Moore. And he is making another framework, different framework, but he's built this great little HTML passer and it's specifically designed to support nonstandard HTML. So a Vue template is nonstandard. It's mostly valid HTML, but there are some things that are passed maybe a little bit differently, it's valid XHTML. And so this is great passer and it lets us do some cool things in terms of detecting. We use it to detect components that shouldn't be rendered on the server, to pass the HTML, find the components, remove them from the HTML so that it's not only that we don't render them, but we don't even execute them in the server bundle. That means that we can avoid calling libraries that rely on there being a window or being otherwise on the client side. So it fulfills a great need. It's really fast, it's really minimal. I could sing the praises of ultra HTML all day long, but one of the key things obviously in how we implement it is it shouldn't matter which library we implement, whether it's ultra HTML or some other superduper HTML that comes along and enables us to do HTML passing. The end user who's using Nuxt shouldn't need to worry about what's under the hood. They shouldn't have to tie their code into what we are using because that means if something happens within a library or an implementation that we're using, that means we need to pivot or swap, or I don't know, do something. You don't want that to be a breaking thing for everyone who's using your app. And I think we've put a number of things in place, not just in terms of third parties, but even our own tooling to try and reduce those breaking changes. So Nuxt, we've released a library called Nuxt Kit, which is basically an SDK for Nuxt. The idea that you can, as a module author, call a function that does something rather than having to implement it yourself. So you can do something like you call add Vite plugin. Now under the hood, add Vite plugin is going to call a hook in Nuxt, and then it's going to push that plugin into an array and first check that array exists. If it doesn't exist, it's going to create it. And that implementation, we don't plan to change it, but if it does change, then it doesn't matter because the user is calling add Vite plugin. They're not worrying about the specific what happens under the hood. So as much as possible, again, we're trying to insulate users from changes that come about from libraries or from our own changing implementations. So I think that is probably the key thing that we would want to do. Noel: Nice. So do you think right now you said that users have a choice in build tool, you could still go in with on Nuxt through use webpack, right? Yeah. So is there any concerns from the user that they're going to care about on that front? Because presumably, there's a reason that the dev is choosing one over the other. Daniel Roe: Well, from a point of view of a webpack versus Vite, obviously there are the functionalities that are present in Vite, for example, import globbing that aren't implemented in the same way as webpack or don't exist in the same way in webpack, and then likewise, the other way around. And so if a user chooses Vite versus webpack, it's possible they might choose to use those specific features and it might not be as portable between them as it could be, but that's their choice. That's not something that we've inflicted on them in terms of binding them into a particular situation. And I really respect if a user wants to do that, that's fine. But as much as possible, we want to make it easy to do things in a way that don't bind users in. So even our underlying server, the Nuxt server is called Nitro. Fun fact, it was originally called Sigma in the early days. Nuxt Sigma, we called it. But anyway, it's Nitro. And we've built that so that a lot of the cool things we're doing with Nuxt work on any serverless framework, any cloud provider. So you can use Netlify or Vercel and both will get incremental static regeneration and you can even use neither and still get something that's pretty much like incremental static regeneration, but obviously based on wherever you're deploying it. And the same is true with other kinds of caching mechanisms. And some of these different platforms have different ways of implementing redirects and different ways of adding headers. And some of them are very efficient because they can happen at the CDN layer rather than once you actually hit the server. And again, we can make that possible, but as much as possible, not stopping users from using platform specific features, but as much as possible we want users to pull in the functionality they need in a way that works everywhere and that doesn't bind them into a specific place or a specific provider. Noel: Yeah, yeah. It's intuitive to me that it doesn't feel like a point against any decision made if the user is making a decision consciously to use whatever tool they're choosing. Yeah, I think my curiosity was more in how do you guys determine which of those choices to leave up to the dev versus what do you guys decide is in the purview of the framework should be making this decision, not the developer. Daniel Roe: I think it's a difficult thing to talk about in the abstract probably is, Noel: I think you answered it pretty well already. I think we've backed into it. I [inaudible] keep digging in there, but I think those kinds of things would be a thing that those decisions would often be tricky for me to grapple with a little bit when they're not super intuitive. So anyway, I think you shed some light though on those, how you guys think about that in a way that was pretty meaningful to me. I think that was the extent of the big questions I have. Is there anything else you wanted to cover that you talk about in the talk or even just anything you want point listeners to in general? Daniel Roe: So I think one of the things that I like about Nuxt is that it's really possible to configure it, and I think it's great marriage with Vite because of, again, how easy it is to implement a plugin. So actually while I was actually giving my talk, now it was pre-recorded, so I was just chatting with people and we were able to engage a little bit there, which is great. That's the fun. And these guys, they hadn't previously chatted before, but they both had a need for implementing something that's pretty cool. And I'm not going to steal their thunder by saying exactly what it is, but I'm sure I will be pretty happy to... Anyway, I'll tweet all about it when it's out. But they were both working on it and what I talked about was how easy it is to create a Nuxt module and create a Vite plugin and take that plugin and actually add it into the app. And literally, they were like, "Oh yes, let's do that. Oh, we've just done it, we've just implemented it." And I think pretty much five minutes after my talk ended, they were like, "Yes, we've done this, we've implemented the functionality we were talking about. It's all in a module." And I thought it was super cool. One, they're obviously incredibly fast and talented and so on. But I also really like the fact that Nuxt enables that kind of thing, that you can just extract some feature or tech or idea, stick it into a module, build a Vite plugin to do some of the heavy lifting for you, and then the whole thing can really easily be added to an end user's app. So there are lots of modules on modules.nuxtjs.org. That's a great place to start if you want to see how to create one. And yeah, ping me if I can help in any way. I sometimes fear that I'm not as helpful as I could be, but yeah, ping me. I'd love to help people make something cool. Noel: Nice. Yeah, so we'll get links to Nuxt the modules list and your Twitter in the show notes, at least probably more so people can find it. Cool. Well, thank you so much for chatting with me, Daniel. Is there anything else? Daniel Roe: I would say it's been a real pleasure. Yeah. Thank you so much for having me back on the show. Noel: Oh, of course. Yeah, yeah. It was a pleasure chatting. Yeah, I learned so much. I love these episodes around just absorbing all this info. It's been great. So thank you so much. All the best. Daniel Roe: Yeah.