Daniel Roe returns to the show alongside guest host Drew and Steve to talk about the new releases and changes in Nuxt. He begins by explaining the difference between Nuxt and Nuxt Labs. He also talks about migrating from Nuxt 2 to Nuxt 3. Moreover, he tackles future projects and plans for the framework. 

Hello everybody, welcome back to Views on View. I am Steve Edwards, the host with the face for radio, but the voice for being a mime, but you're stuck with me as your host. Well, sort of. Today, I have one of my special returning guest hosts, Mr. Drew Baker, how you doing, Drew?

 

Great, thanks Steve.

 

Alrighty, and we are here to talk all things next today with Mr. Daniel Rowe of the next organization himself. How you doing, Daniel?

 

It is a pleasure to be here now, Steve. It's lovely to chat. I'm really hoping to hear some good jokes on this occasion.

 

I have jokes, whether or not they're good remains

 

I'll leave

 

to

 

it

 

be

 

to

 

seen.

 

you as to how to interpret that particular...

 

Yeah, for sure. And I'd also like to welcome our studio audience as always. Thank you.

 

Now, what an appreciative crowd, right Steve?

 

Oh yeah, they haven't booed me yet. So whether or not they do remains to be seen. So we are here to talk Nuxt and what triggered this episode in my invite to Daniel was an announcement that I saw, I believe that he made on Twitter regarding changes in the Nuxt organization. In particular, Daniel's moving up in the hierarchy there and that's all I know. So I will let Daniel explain what's going on with all the movement there and what his new role is and how things are going to work going forward.

 

Well, so it's, I think in some ways it's not groundbreaking news. So you will probably know Pooja Parsa has been leading the Nuxt framework for some time, particularly during the development of Nuxt 3. And has done a phenomenal job. Obviously we, if you're using Nuxt 3 or have used it, then you will be grateful to all that Pooja has done. He's going to be continuing to be developing at NitroPack. He's still on the core team of Nuxt. And he's also taking on a new role at Nuxt Labs. And I'm taking on the leadership of the Nuxt open source project. So I'm project lead for Nuxt as well. And I've got to say, you know, it's a real honor. I'm absolutely thrilled. It's also somewhat daunting because we have such great people on the team, people who are incredibly talented and also people like Sebastian, Alex and Puyo, who are authors of Nuxt and have taken us to where we are now. So heading up that team is both a dream and a bit of a challenge as well, but a real privilege.

 

I think we're having some trouble with Steve's connection here, so I'm just going to jump right in here, Daniel. I think that I'd like, I mean, incredible, it's an incredible sort of accomplishment for you and also you totally reiterate your points about the stacked group of people that is on the Nuxt team. I thought it was really interesting hearing from you earlier. about the structure of Nuxt and the different levels to it all. I thought maybe you might want to explain that a little bit, because it was really interesting to me. So where do you fit into, there's Nuxt, the company, Nuxt Labs, and then there's Nuxt, the framework. Give us a little bit of a background on that structure. It's really interesting.

 

Actually, I think we're planning to put out an article or a FAQ on that as well, because I think you're right, it can be a bit confusing. The point of contact is Sebastian and Alex Chopin, the Nuxt brothers, who founded, who created Nuxt in the first place. We've all seen them at conferences. We've heard the vision for Nuxt and appreciated their work over the years. They also started a company. which has been known by a couple of different names over the years, but is now called Nuxt Labs. And Nuxt Labs provides, it does a number of things, it provides consultancy, support for people working on Nuxt. It also has a number of projects built on top of Nuxt, things like Nuxt Studio. I don't know if you've been following that, but it's a completely reimagined CMS for projects built with Nuxt. It's amazing. Check it out. Nux.Studio. They've also released projects like Docus, which is open source, and also Volta, which is really built for open source maintainers. You know, it's built out of a need. And that is, that's pretty cool too. Again, check it out. And more to come. I don't want to spoil. spoil any particular announcements. But Nuxt Labs is doing incredible things, building on top of Nuxt. But it's not the same in any way as Nuxt. It's a separate company. The Nuxt, the framework is, Nuxt, the framework is an open source project. It's MIT licensed. It has a separate governance, which we actually have made public at Nuxt slash governance. And so it is that open source side of things that I'm heading up. I am sponsored by lots of people, but especially by Next Labs. And they also sponsor a lot of other people in the ecosystem. So other people who are working full-time on open source like me, and also lots of people in the Vue ecosystem, even if it's not a full-time sponsoring, they are still actively doing their best to give back to the community. So Next Labs is a great thing as far as I'm concerned. And I think it's a virtuous circle. Hopefully as Nuxt grows, that will help Nuxt Labs and lots of other companies too. And hopefully as Nuxt Labs continues to support Nuxt, the ecosystem will flourish. I think we, I don't know. Does that answer your question, Drew?

 

No, it does. And it's really interesting to me because at my agency FunkHouse, we actually sponsor Nuxt. And so I was really curious to find out that like, I guess technically you don't work for Nuxt. You know, like the company, you're on the framework side of it all. And so it was really interesting to kind of see how like, they support you and just, it's a great way to organize it. I suppose that Remuse are really interesting. I guess conflict interest would be a thing where like you're working on what's best for the framework, not necessarily what's best for the, for whatever the company goal might be. Um, with, although those are probably very aligned, I would imagine, but, um, yeah, it's still really interesting. Okay. Cool. Well, I guess that's a good stepping stone into the vision of Nux for 2023, which is a really interesting article that you published recently. Uh, I think it might be good to talk a little bit about that and what of what you were saying in that. And then, you know, also just sort of bullet pointing what's going to happen over the next 12 months.

 

Yeah, lots to say and lots of plans even that aren't in the article. But, um, I mean, there, there are a couple of things to draw out theme wise. Um, one of the themes is about unifying next. And we, you know, we, we started building next three, which is a rewrite of next in a separate repository. We have a separate documentation website for next to next three had two different repositories for the code. Which is also therefore. double the places people can raise issues and discussions and so on. And in a way, it's felt like maintenance on Nuxt, development of Nuxt 3 has harmed maintenance of Nuxt 2, which is understandable. We're a small team and we need to focus on, we need to focus. But it's not great for the ecosystem. So we're aiming to unify. So already... we interact within a couple of days after the announcement. I couldn't hold back. We unified into one repository. So we now have a Nuxt slash Nuxt repository and GitHub that's the home for every all Nuxt code. We have a 2.x branch which can then use to get bug fixes. And actually I'll be releasing 2.16 soon, maybe even before this podcast goes out.

 

Ooh, I wanna talk about

 

But

 

that.

 

absolutely. So we're pulling everything into one repo. We're also going to do the same with the website. The new website at nuxt.com is, I don't know, I'm a bit, maybe a bit partial, but I think it's beautiful. But we really want one place for all Nuxt content. So version documentation is important. So you can access both the 2.x and the 3.x documentation there. And we have some other really nice plans as well for making it the home for more. Nuxt-related content resources that will help people as they're building Nuxt sites. For example, we've already pulled in the modules documentation. So on that site, you can see all Nuxt modules and actually even browse their readmes. And there's some other really interesting things like idea of having documentation for modules sort of integrated in that site and all powered by Nuxt 3's remote sources feature. for content. So we can actually pull markdown documentation from module repositories and actually keep that updated as module repositories update their own documentation and have a sort of central place. But again, there's lots of great things I think we're planning for that. But the point is it's bringing a bit of unity back to the ecosystem.

 

Interesting, I have so many questions about the way that you're using the remote source stuff there. Does that mean that the Nux site is not static site? It's like not, it's got to be like server rendered then right? Or are you regenerating every time someone updates a readme?

 

Well, so it's a hybrid site is what it is. So some pages are static. Some pages are stale while we validate. So they respond statically. You'll get a page from the CDN cache and in the background it will revalidate. We use that for things like our list of sponsors where we actually want that to be updated in, you know, it's not every time the site is built. We don't want to push. Like you could have a webhook to rebuild the site every time a sponsor is added, but it feels like that's too big of a change when you really

 

Mm-hmm.

 

only have the pages that mention the sponsors that should be evaluated. So basically, if you look at the root rules, the site is not open source yet. That's another thing we want to do. And that should be pretty soon as well. But if you look at the list of root rules for the site, we have all kinds of different... different treatment for different parts of the site, depending

 

Mm-hmm.

 

on what function it has. So for example, some of the pages, we have a pre-render setting because actually it's not going to change. The site map, for example, we render that statically. We have a page where you can sign up for the newsletter, nothing dynamic about that static content. but pages like the modules pages or job listings or that they have a still while we validate strategy. And it's really a test bed for a lot of the NYSERA and NUX3 things that we've built. It's nice to have some big projects that are using that to the full. I think it's helping lots of projects as we test them out.

 

Yeah, I can't wait to see the source of that. That sounds very useful as a place to go to see like best practices for sure.

 

So yeah, so the website and the sort of the unity to the framework is important. We also have some other stuff. So I should mention, by the way, that one of the themes and an implication of that change. So by the end of the year, view two is going to be deprecated by view. That means that one of our focuses this year is going to be, well, at the same time, continuing to release bug fixes, security improvements to Nux 2. We also want to help people to migrate to Nux 3. And that is one of our biggest priorities in terms of thinking about the kind of tooling we build, making sure that there are modules in place. so that people migrating their Nux 2 projects can do that. They have a migration pathway. We don't wanna leave people behind. That's really important, I think. And yet because of the deadline that Vue 2 has, which is reasonable, that's gonna shape how we build and develop. Also worth mentioning, we have a new release cycle. So the aim isn't I guess, I mean, you're from agency land, right? And I think one of the most important things I always felt in terms of agency work, or in terms of actually any kind of project work, is you have to have something that you're fundamentally committed to in terms of, is it going to be the project scope? Is it going to be a timetable? And obviously that's a bit of a balancing act. But I'm sort of pushing us down on the side of... being committed to a timetable. So I would rather get a release out there and defer a PR that's not ready to the next release than delay the release. And so we have a new aim, which is we'll have a minor release each month and a patch release each week, a major release each year. So the aim is that there'll be that rhythm and it's ish. It will be every

 

Yeah.

 

week or so. and it will be every month, maybe give or take a little bit, but it shouldn't be more than a little bit in terms of give or take.

 

The patch release rhythm there is huge because that's the one, like in my world, that's the one that kills you, you know, is being like, oh man, I have to wait how long to get this bug fixed that's affecting, you know, 30 clients, you know, or something like that, or whatever it might be. So having that is gonna be very exciting.

 

So again, we're striking out a new territory here, so we want feedback is welcome. But again, that seems like something we can do. So we started it last week with the release of Nuxt 3.10 or 3.1.0 and immediately followed it the next day with 3.1.1. It's always, always, always best when you get a bug fix straight away. But this week we'll have 3.1.2. and also 2.16.0. So hopefully this will be the inauguration of something good and something regular.

 

What, tell me about 2.16. What's in that? That's exciting, it's been a while.

 

Well, that's the thing. So 2.16 brings a lot of changes that have been implicitly been in use. So people have been using Nuxt Edge, which is what we've advised. If people have been using Nuxt Bridge, they've also probably been using Nuxt Edge. These changes have been tested for quite some time. It's time to release. I think we have partly on the team delayed because we've been thinking, oh, 2.16, 2.17, they'll be our final releases. But that is very much not, that's not going to be our plan. I don't want to, I think it's probably unhelpful for us to have a big cliff edge on our release cycle, because it pushes you into thinking, well, we have to get everything in here. 2.16 is going to be just a normal release. It's not going to be the last or the penultimate, it's just going to be a release. And we're going to keep on releasing until we need, as long as we need to release for Nuxt 2. So what's in it? There have been some bug fixes that you'll be very glad to see. So the list of bug fixes is probably about a page and a half long on the sort of GitHub issue that I've created a track at. It's probably a little bit too long to mention all of them. But lots of them around routing, some stuff around sort of more modern JavaScript. So how to handle. like module.mjs files in webpack. There's a longstanding webpack four bug, which it's not really, it's not longstanding. It's been fixed in webpack five, but there's some things like that that we fix and I hope people will be glad to see them. There are some enhancements too, in terms of, there's a new default for core.js, for example, we're defaulting to version three rather than two. And there are a host of dependency upgrades. So you'll be glad to see that if you've been looking at your lock file and wondering when some of these major dependencies would update. But again, the aim isn't to get everything into this one release. There are some significant PRs that are still outstanding that we'll be getting into the next one. This is, we're getting back on track.

 

Exciting, so exciting. That's awesome. That's awesome. Well, I mean, it's a good way to talk about what's some advice. I mean, we were just chatting about this offline earlier, and I think it'd be good to bring it up here as some advice around people moving from Nux 2 to Nux 3. What would be the few things you think someone should focus on doing that?

 

So, I mean, that is interesting. So moving from Nux 2 to Nux 3, I've heard lots of different things from people in terms of what's worked on their projects. And I would say the same is also true in terms of my experience with migrating projects. So, I've had quite positive feedback from people simply creating a new project and... basically migrating each part of their project across. I think that is probably quite a good approach right now because a lot of things are, you can handle, so you can sort of migrate all your components. You can migrate your pages. There's some changes in syntax. There's some changes in lifecycle hooks. But thinking about it from scratch, rather than taking the entire project and feeling like you have to change everything at once, that works quite well. depends on your project, there might actually not be much you need to change at all. I've had people say that they've migrated in a day or a couple of hours. I imagine there'll be sites that will take considerably longer than that. And a lot of that will be the changes between view two and view three, which and the changes in Nuxt mirror that too.

 

Yeah, that's what I would think would be the biggest pain point. I mean, if I think of our team at Funkhouse that have been very much Nux 2, is going from Nux 2 to Nux 3 also includes going from View 2 to View 3. Although you can use View 2 in Nux 3, right?

 

Um, no, you can't, I'm afraid. Um, well, not as far as I know.

 

Well, you can use the options API, I guess I should say.

 

Oh, yeah, no, exactly. Sorry. Sorry.

 

Yeah.

 

You're quite right. You can use the options API and the and I mean, you can even use the composition API in view two now as well. So the, the, the chasm isn't quite as big in terms of view two to view three. That's, that's right. So yeah, I mean, a component that works for you in view two should also work for you in view three, you know, with it, it computed watch. mounted hook at all data that that's fine you can just take it across.

 

Yeah,

 

You might.

 

so I could fire up an empty Nuxt 3 site and bring over my view components one at a time if I used the Nuxt repo and then added, or Nuxt package and then added the Nuxt options API package. Is that the right package?

 

Um, well, you shouldn't need to add an options API package specifically, but, um, there are a couple of, of hooks where you'll need to use define next component. So if you're using a special, uh, the head, um, life cycle method, for example, or the async data life cycle method, you can use the define next component hook to preserve something which is a bit more familiar from next two days. Um, but I think, I mean, it's, uh, yeah. So I think I. You know, it depends how big your project is and where your logic is located. If your logic is, you know, heavily in your components, um, it might be a great time to, to migrate to the composition API and script set up blocks, just because it's it, you lose a lot, you go, your net line count will be considerably in the negative. when you migrate and it looks a lot simpler and it's easier to reason about. I'm a huge fan of it. You don't have to. It's not a requirement, but it does feel nice when you're migrating.

 

Yeah, I've just always been a big fan of reducing the learning curve as much as you can on these things. And, you know, the thought of having my whole team go from Nuxt 2 to Nuxt 3 and Nuxt View, sorry, Nuxt 3 and Nuxt and View 3 at the same time, you know, it's doubling up on the things they're going to, you're going to have to learn. So it'd be nice to be able to try both. And maybe the solution is Nuxt 2 with the composition API turned on, you know, and get everyone kind of used to. View 3 or something like that. I'm not sure, it's an interesting thing to talk about, but it does sound like the, I mean, what we will definitely do is just start on new projects with Nuxt 3. We won't try and bring over, or there's no reason to port over a Nuxt 2 one. And a big reason why I'm not scared to leave the Nuxt 2 sites out there is because you guys are gonna be continuing to push updates and patch problems and things like that. There's no reason for me to like abandon those projects, which is really good, a good. and I'm happy that you're doing that. I mean, it's always been a big selling point of view for me. I remember when I started learning Vue whenever that was, long time ago now probably. I remember that React was going through so many different rebuilds and Angular was on a whole complete new version or something and you basically had to throw out everything you knew and Vue had this big backwards compatibility thing and was all about consistency and so I'm glad that that's carrying through to the next world as well. It's awesome.

 

I really appreciate that. That's nice to hear. It's nice to hear.

 

So the next thing is, and if everyone's picking up, this is me just sort of using my privilege here to make sure that Daniel's pushing it in the right direction to help my job. What about

 

Hahaha

 

community? What about all these important modules that people need and me specifically?

 

Exactly. So basically, one of the things we've had over the last couple of years is Nuxt telemetry, which is an attempt by us to track our users. No, I'm just kidding. It's an anonymous way of us knowing what modules are used in the ecosystem and what versions of Nuxt people are on, which is really helpful when we make decisions about how we maintain and what things we maintain. So our concern is when we look out and see modules being used by Nuxt users, we want to make sure that if they've been on Nuxt 2, using a module on Nuxt 2, that when they migrate to Nuxt 3, either that module works as is, or that there is a migration path for them. Some modules are now built into Nuxt, for example, so you don't need a new module, but users do need to be able to know what to do. to remove the module and turn on an option or whatever it is. It needs to be straight forward and clear. So again, that's part of the migration focus. There are a lot of making sure that there's this continuity between Nux 2 on the module side and Nux 3. We do have new things going on in the module space as well. So we have plans for, and this has actually been going on for some time. are thinking and planning about both of these, but you should expect to actually see RFCs coming soon for Nuxt font and Nuxt script. So one of the things that you might notice looking across the module ecosystem is that there are a lot of modules that need to interact with scripts, for example, or fonts in a webpage. Maybe you're using Google fonts or you're using some a analytics script or maybe a capture script or there might be a lot of different things, a chat

 

Tell

 

script.

 

me about it. The scripts. I mean, Daniel, just so you know, one of the hardest things that we have to deal with, just like, that should be easy, is like, those little support chat widgets. Oh my god,

 

Oh yeah.

 

like the amount of clients that are like, oh, we want like a real-time chat widget. And those things are like ancient, most of them, and they're really built with this idea that a page load is going to happen every time they're out. Anyway,

 

So,

 

I'm glad you're

 

well,

 

making that stuff easier.

 

you're absolutely right. And so there are these things that happen across, like in lots and lots of them. So things about lazy loading, maybe even cookie, like some kind of consent. I don't want to load this unless such and such a condition is right. I also ideally want to load it after the sort of user has been, and they can now interact with the page. I don't want to be. loading all these heavy scripts before my page is considered to load, or I'm killing my page rank scores. Maybe you want to sort of have some kind of event system that you still want to pass to the script, but you still want to queue it up while the page is loading. There are lots and lots of tasks that many of these modules have solved and solved well, but everyone is having to do it for themselves. There's no... coordinated central framework. And I think one of the main things, the main jobs of the Nuxt framework is not to make all the modules, but to provide the tools and the APIs for module authors to be able to build and create integrations. And that is also incidentally our plan for Nuxt auth and PWA integration. And also you can see the same kind of thing with something like Nuxt Image, which exposes an API. You can build your own image provider. I mean, of course, you can make a PR and put it in Nuxt Image Core, but you can also do your own. Nitro also, there is not anything that you can't... Every provider preset we have in Nitro, you could make yourself and publish as your own NPM package. We really see that sort of the aim of the core Nuxt... libraries and utilities is to be built upon. And so that's definitely true with Nuxt fonts and Nuxt scripts. I look forward to...

 

I would urge you to also think of, I mean, it's great the way you're thinking about it. Like the being the framework to build upon is great. I would also say one of the things I've appreciated the most about Nuxt and view to a certain extent is you have the right amount of opinions on the right way to do things. Like there isn't

 

No

 

this like this react world where it's like, you can do whatever you want. You know, like there's a million ways to do it. Freedom is the thing that we're selling here. Cool, but it really helps with Vue and with Nuxt that there is a path that you're supposed to go down. And you can go outside of that and do whatever you want, but it really is easier. And if you go down this kind of like best practices route. So I love that about Nuxt too, and I know that you're doing that for Nuxt 3, but I would still sort of just continue that, urge you to keep doing that because it's been really helpful. And it just helps when you're dealing with a team of people because there's a sort of an established best practice and it's not like you have to invent everything all the time. So keep that in mind, but please feel me in a bit more about what Nuxt script is, because I'm curious, how is that different than like the view meta stuff that you did in Nuxt too? So, I'm curious, how is that different than the view meta stuff that you did in Nuxt too? So, I'm curious, how is that different than the view meta stuff that you did in Nuxt too?

 

So, exactly, so I mean, it will obviously integrate with rendering the HTML, because we need to be able to render scripts. So an example of, I mean, it covers a lot of different use cases. So some of the things that I've been talking about, deferring the load of scripts until later, having different strategies for loading them. So maybe the third party script isn't in your HTML on initial load, it's loaded later on client side. when certain conditions are met, such as when we're now loaded. We have a new Nuxt composable, incidentally, in Nuxt 3.1.0 called onNuxtReady, which runs if the page is loaded and you've had that first tick after the mount and everything's ready, it'll run immediately. So you can always wrap that around something that you have that you need to run when the browser has a moment. wrap it in request animation frame and whatever, and call it for you. You can also do that before the page is ready on hydration. And again, it will defer it to that moment. So there are things like that. There are also the opposite problem where you actually need a script to load as soon as possible. So like next color mode has needs to... actually access your local storage to find out in your browser preferences to find out what the color mode is for the page and then modify the HTML so you actually have the dark or light or cpa or whatever class in your HTML. So again this is a and it's not the only one that needs to do that there are a lot in order to handle differences between the server and the client. I can imagine I18n would want to hook into a similar kind of thing. Because again, if you're rendering, or if you have static HTML, you're rendering HTML, but now you're on the client side, you know what the user's preference for their languages, you need to make sure that it still hydrates. So again, you want to sometimes be able to run logic early on outside the NUXT bundle. And so NUXT script aims to help with all of that kind of thing. So what scripts do you want to run? when strategies do you want to have for running them? And when do you want to run them? So those kinds of questions.

 

Does that

 

We

 

overlap

 

might.

 

with the new head method at all? Or sounds like they'd probably do a little bit?

 

Well, it will be an alternative, I think. So in terms of, if you think, and also these things are probably going to be used a little bit more by, well, yes, I think these things will also be there to be used by module authors as well as users. The head method, of course, you can insert scripts always that way. You can always have a script tag and you have a script array and you put your script in. in either an object with some props for the source, or you can actually inline it with inner HTML. But this will be a different way of adding a script to a page, which is more semantic, is less about the HTML, because when you insert a script by a use head, it's just exactly the HTML syntax. You're just adding literally a script tag to the page. But the... but NuxtScript is much more about semantic. So I want this to load at this point. This is the kind of strategy I want. We also had some experiments. We have a NuxtPartytownModule, for example, which moves scripts into a worker thread rather than on the main thread, which is often a great strategy if the script's origin supports it. So it needs to have core setups, for example, if there are some issues there. That's also the kind of thing that NuxtScript will be able to. allow people to opt into without having to configure anything.

 

Fantastic. If anyone out there is listening that builds like in beds and things like that, please stop shipping your in beds with a chunk of HTML and then an inline script tag that is reliant, relying on that HTML to be there. It does not work in the modern web frameworks because you can't really embed script tags inside of these things. And so you're hearing all the trouble that, that the annual is going through to try and get scripts working correctly and then you like Spotify for example, you're terrible at this. So I'm glad there's a lot of effort going into script stuff because it is definitely weirdly, it's one of the things that got harder with the modern frameworks versus like just putting it in a WordPress template from 10 years ago. Exciting stuff. But the font thing is huge for my world. And I want you to talk about that because I don't think people are appreciating how much of a win that is.

 

So some time ago, and I should say both of these things, Nuxt script and Nuxt font are really, we've been working closely with the Google Aurora team who are seeking to bring some best practices from PageSpeed sort of into framework world. And so they're working with a number of different frameworks including us and Next.js as well, for example, Angular and And then they've been huge. I would massive shout out to the team. They've really, really been great. So Nuxt font, some time ago, last year, one of the team basically drew my attention to an amazing method for reducing layout shift when you have web fonts. So, and this is not the only thing that... Nuxt font will do. But basically, and you know this, Drew, when you load a web font, it's different than the system font, and that difference means the page jumps around. And that's particularly true if you've got a big headline hero with lovely custom, beautifully chosen by the designers, beautiful font, and it is just a totally different size from, whatever the system font is.

 

Well, I mean, I think it's probably worth a little bit just touching on what these page score metrics, just the top view of it, because I'm not sure if everyone, I mean, a lot of people might not know this. So Google has these page speed indicators and there's four or five, there's six of them, generally that matter. And one of them is CLS, or cumulative layout shift. And so what they essentially think of it like this, as your page loads, what Google is kind of doing, I'm probably... inaccurate because I haven't been talking to the Aurora team like some people, but is they basically take screenshots over like a second and then they see what's moving around as your page loads and depending on how much things move you get penalized for this. And the penalty is lower page speed scores, which some people won't care about that, but in our world, in the agency world, sometimes that's mandated by the client. like you're expected to deliver a certain speed. And so you either have to like design around it, knowing that like, all right, we're gonna have to design something that's not gonna move around very much. Or you've got to do things like this, which is really dial in what's moving around during load. Like is this image fading in or is something weird happening? But one of the ones that's the hardest to deal with is fonts moving around. Because the only real, like, I mean, up until sort of now-ish, the only real way to... fully solve that was to either pick a font, like a custom font, because of course your design team wants to use some sexy new font. Pick a custom font that like matched the system font pretty closely, which was like never gonna be one-to-one or just use a system font. So like Helvetica or Arial or Times New Roman and even that's getting like slowly changing. So it sucked. Now what Daniel's describing is now explain what this does and how it works because it solves this problem and you basically get like, I don't know, about 10 free points if you use this on page bit.

 

And just to underline that, these things aren't just arbitrary numbers either. Like, the user experience is significantly impacted by these things. If you've ever, and I have often experienced this, the page loads, you see a button, you click the button, and it moves before you get a chance to click it. That's terrible. Worse, you click a different button. You now click a link to a different part of the site, and it's too late. Um, you know, it's not to mention that just the sort of unpleasantness of the drank or the idea that this site is sort of a bit, that, um, ramshackle, uh, you know, it, it actually, it, this is, this is a really negative experience as a user, if you've got something that is changing often the case, you know, with cookie banners or whatever you load or an ad, you load the site and then suddenly something pops up at the top of the page shifts all the content down by 300 pixels. Like it's terrible, but yes, fonts, who would have thought that they do it? But yes, when you enable, so what we're able to do is, if we know the font you want to use, we can extract font metrics from the actual font file. And the particular library that we built is called Fontaine. And Fontaine uses another library called capsize. It was originally built in order to render text without the gaps, the arbitrary margin to the top and bottom of the text that the browser rendering engine inserts. So it was originally built so that text could be laid out on a page as the designer wanted it to be. But as part of that mission, they built a package full of font metrics, which were taken font files. And so we were able to use those metrics to calculate what size the font that was going to load was going to be. And ob and coerce the system font to take the same amount of vertical space. Which means that then when you actually have the system font, it still looks like the system font, but it only takes the size that the web font is going to take when it loads. Which basically means you don't get that Well, there's still a width issue, so you can have a line wrapping problem. But basically, in a lot of situations, you don't get layout shift. And that means you can go from, yeah, you can go 10 points difference in terms of your page rank for effectively something that is free to do. And we can actually do it. We have a Nuxt module for it already, which you can build, just install, and it will automatically do it for you, inserting the CSS rules you need. examining any font files you use. And that's great, but there are a lot of things around fonts that mean that this included, that mean actually it would be a really good idea for us as next to have some framework features and some framework hooks that modules and others can hook into for handling fonts for you. And... Yes, producing layout shift is a big part of that. But there are other things like if you're using remote fonts, making sure that preloads are there, or just downloading them to your projects so they can be served statically from the same domain so you don't have the network round trip issue. And there's no real benefit to having CDNs or third party sites hosting your files because there's now no longer any shared cache in browsers when getting files from a CDN. It's all based on your origin. So I think real benefits to having a shared way of handling fonts.

 

I love that because I remember when I first started using Nux 2, it's like, and I just imagine like anyone building a website is going to do this. It's like, cool, this looks great. I can build components. Cool. Okay. Fonts. And then how do I install fonts? You know, and there's a lot of questions about that. And then the other one, which I've mentioned to you before is like SVGs follow right after that. It was like, all right, fonts working. Cool. Logo on the page.

 

Yep.

 

So I...

 

It's SVGs are so funny because, you know, there are so many different ways of handling them. Right. So, I mean, you can have sprite maps. Um, I'm a big fan of, of, of, of basically having a sort of an SVG and then referencing it with symbols later. Um, I think that's great. You sort of deduplicate it. You're not cluttering up the DOM, but that's not the only approach. People stick SVGs in view components. There's a whole raft of things along that. There's iconify and nuxticon, which is a module by Sebastian, which again, effectively, it's really incredible. It actually sort of fetches the actual HTML for the font, statically that can be put into the payload. And so you get the same kind of thing without having to create component instances, lots of different ways of handling SVGs. It's a... There are a lot of ways to go around that mountain.

 

Yeah, yeah, it's not to mention like they can include script tags, they can include inline like CSS and there's a whole bunch of weird stuff that can just end up in them that gets exported differently and yeah. I am on a, and we should put this in the links to the episode, there is a tremendous like flame post issue thread going on on SVG Optimize.

 

Hahaha

 

that I'm not a part of the flaming part of it all, that I'm definitely, I've got some comments on there just about like what defaults you would have around optimizing SVG, you know, it's quite contentious. So anyway, yeah, SVG is a big thing, but anyway, exciting stuff with Nuxt font and script, I can't wait to use the font one specifically, it's gonna be awesome.

 

And great, yeah, I hope you enjoy it. Well, the aim is we'll have RFCs up as well. So you can comment, Drew, and tell us exactly what we ought to be doing. And... And...

 

Oh man, no yeah, just the SVG one would be good. I mean, like you said, everyone's got a different way of doing it. But for us, what we've found to work the best is, is essentially to use an SVG loader in Webpack that treats them like view components. You know, and

 

Mm.

 

then it's pretty easy just to drop them wherever you want. Because again, like, it depends, I wish that we could use icon sets and font sets and. these sorts of things, but my design team is just making custom

 

Mm.

 

things all the time. So SVGs and, you know, I would say like for us, surprisingly, you don't use that many of them. Like in the end, we have like 10, 12 different SVGs that we use on the site. You know, it's not as many as you would kind of think to justify like a whole icon kit or something.

 

And that is the key, though, and that's maybe very specific to your use case, because I have seen a slowdown in compilation time by people having a massive SVG as a view component that included... I mean, I've seen some terrible things. I've seen pings embedded in SVGs, masquerading.

 

Yeah.

 

Yes, it's the vector image you asked for.

 

Yeah, yeah, yeah, yeah.

 

Is it really the vector image I asked for? There looks

 

Yeah.

 

like some base 64 encoded data there. That's pretty

 

Yeah,

 

significant.

 

yeah.

 

But no, I've seen sort of really huge SVGs with, you know, I've seen like a thousand line SVGs that people have made into a view component and the performance hit is unbelievably

 

Yeah.

 

bad. And also I think there's maybe an issue with view even transformed, like the time the compiler takes just to transform that. component, quite apart from the runtime performance set. There was a situation where I was debugging a build that just kept on hanging and it was an SVG, so I'm going to paste it into a view component. But I mean, you guys would never do that. Your team would never have some unoptimized massive thing.

 

No, yeah, we run them all through, they all get run, part of our build get run through SVG Optimize for that very reason to strip out all the unnecessary stuff. But there is some scenarios where we allow SVGs to be uploaded into the CMS by the client. A lot of the times that's like an award that someone won, like, you know, like, because we do a lot of stuff for Hollywood clients, so it'll be like they won a Khan Award or a Webby or whatever, and they want to upload the little logo of the award. And then like we see some horrendous things in there too, you know, like. all kinds of weird stuff. And because SVGs can, are so flexible, they can include, like I said, like weird script tags or inline stuff or any kinds of weird things. So again, all of this is to prove my point that I wish there was some official best practices on the way to handle SVGs.

 

Well, I think there is opportunity there.

 

Yeah, yeah, yeah. Anyway, moving on. Well, we've kind of covered, I think, a lot of the good stuff here. There's been some really interesting side projects that you have been involved in, Daniel, that are like non-NUX related. Specifically, the elk stuff has been, if anyone's not following Daniel on Twitter, it's a good worthwhile thing to do. But you've talked about the elk stuff a lot. I think fill in the people listening about like what is that and what you've been doing because it's really cool.

 

Oh, yeah, absolutely. So the, I mean, I should say I'm on Twitter and I've always, I've loved Twitter. So one of the things I love about it is the conversations that you can have and you can also overhear conversations from very interesting and intelligent people and also very funny people are very, anyway, you can overhear and listen and be part of this big thing. But over the last year, Twitter has has started to take a little bit of a turn for the worse. And there were some particular decisions like the, there were some particular decisions that were, I think moved a lot of people to look elsewhere and to try and make sure that their entire social network wasn't bound up in one company's hands, particularly when that company seemed to be less trustworthy than it had been in the past. And so a lot of people moved to Mastodon, wanted to explore it. see what this is, MasterDOM is a social network, but it's decentralized. So rather than one server that has everything, there's a network of servers, like a network of email servers that exchange data between each other, and you can effectively subscribe to people. And then when they post updates, their server sends it to you. And so there's this whole social network that exists, but a lot of it is, it's maybe a little bit... unfamiliar to people. Even the idea of having to create an account at one of lots of servers is quite off putting to people. Particularly if they don't know that it doesn't really matter. Like email, you can communicate with everybody and listen to everybody no matter what server you pick. But it can still feel a bit worrying. And one of the most talented devs I know, Anthony Fu, who's also on the next team. you know, feeding into all those, the sort of, the daunting

 

incredible,

 

nature of the... He's

 

incredible

 

incredible,

 

pace

 

isn't

 

of

 

he? Ah.

 

development.

 

I mean...

 

Yeah. And yeah, it does some, I've said this before on this podcast, I think, but the work he's done with Teleport, I mean, he's got a different name, Starport or something. I think he's got a different name for it, but that is like incredible what that can do.

 

Yeah. Well, I mean, and you could pick almost any one of his projects because he doesn't seem to be able to work on a project that isn't, that is not actually transformative. Like his projects are, a lot of us put libraries out there that, you know, serve one small use case or, you know, it was interesting to me as the author to create, but Anthony really is able to come up with things that are, uh, that capture you. So he does a lot of

 

It

 

great

 

is

 

things.

 

incredible. It's incredible his ability to pick a project. Like, hey, this thing could be interesting. And you're just like, it's groundbreaking at every one of them. It's really a weird skill to be able to pick them.

 

Yeah, yeah, he's

 

Anyway.

 

got it. And also I think one of the great talents he has also is building teams. Because very quickly, things like V-Test or things like VUUs, you know, Anthony will build, but he doesn't have the idea that it's all about him, that, you know, he's got, actually he attracts people who have great talent and who... who join in and capture the vision and he is not afraid of giving them Responsibility and ownership in what he builds and just massive props to him. I think I

 

View

 

think that's so

 

use, big props to view use. That's

 

Yep.

 

some slick, there's some great stuff in there.

 

And of course, a lot of it also is not from, Anthony didn't build it because

 

Yeah,

 

that's

 

yeah.

 

the joy of having an ecosystem and having contributors you respect and care for because actually they come and they make their own things. And you know, anyway, I love it. It's absolutely philosophically where I'm at. So I, but anyway, Anthony built this client for Mastodon. I think he sent a message to the Nuxt team. He said, hey, I was just thinking, what if we built a client for Mastodon in Nuxt? And a couple of days later, there it was. There was a client for Mastodon in

 

Yeah.

 

Nuxt. And a few of us started helping out and building. I was really honored Anthony invited me to be part of that. So that was fantastic. And now Elk has over 120 contributors. It's still in alpha, but it's hopefully a much more friendly, accessible interface to Mastodon. So, check it out. It's under development. You can make changes. You can put pull requests in. You can fix issues or report them. And

 

And

 

it's...

 

that's built on like a stock version of Nuxt. Like it's not a highly modified because you guys are all working on a version of Nuxt.

 

Well, it's been a great way of dogfooding Nuxt and a lot of other libraries. So you'll be able to see I18 like internationalization at work. Lots of you use libraries. A new Nuxt PWA module was built on the project. So the VEEP plugin PWA built the module for Nuxt and that's actually just only been released, but it was again dogfooded through Elk. Lots of things. You can see un-storage at use. In use, we even built the custom driver for Tauri. Tauri is what we're using for native application support for Elk, it's built in Rust and is an alternative to Chromium, not Chromium, Electron. But you can see a lot of things at work. So it's definitely great if you want to take a look sort of how a real world application is built. by a lot of people who are, you know, really good at what they do.

 

Yeah,

 

I'm not talking about

 

I would

 

myself

 

love

 

of

 

to

 

course,

 

see,

 

but...

 

no, no, I would love to see the source code for that if you're ever gonna, is it gonna open source it eventually?

 

It is open source, in fact. When we started, we had a private repo just so we could coordinate and iterate faster, but we open-sourced it. So we're in open alpha now. Website is elkzone.org. And you can go to the try-elk-out at elk.zone is the domain.

 

Amazing.

 

You don't even need

 

I wanna

 

a Mastodon

 

check that out.

 

account. Yeah.

 

Yeah, I'd love to see it. I mean, I built a, it's something that I, you know what? It's something that I don't think Nuxt gets enough attention for, which is like web apps. You know, like I think a lot of people think of it as a website building framework, but I mean, it's fantastic for web apps too. I've used it to build a really big web app for a big like task management app for the construction industry, super complicated stuff. And it works great for it. So yeah, it's exciting to see this. And if anyone's looking to build a web app, they should start by looking at this source code. I'm sure this is the best like starting tutorial you could ever get. So

 

Well,

 

cool.

 

I-

 

And then, yeah. Oh, I did want to cut you off there, Daniel, but I did

 

No, no,

 

want

 

no.

 

to talk because we're running out of time. So I did want to talk about the Magic Regex thing, which is just a cool thing that you've done. So fill us in.

 

Oh, thanks. So the, so regex, yeah, magic regex. Basically, it all came about when I got COVID and was basically sitting around with nothing to do, feeling a bit sorry for myself. And what is it? It's a different way of writing regular expressions. So it uses sort of more natural language syntax to talk about the kinds of things that regular expressions do. And it has some design decisions that basically aim to remove a lot of errors you can make, mistakes you might make unintentionally when working with regular expressions. So everything is escaped by default, for example. You're not accidentally going to write a regular expression to match.com and end up matching any character followed by com. And the whole thing is... Other things, for example, if you have a group, and if I get other expressions, but you're only doing that in order to, say, choose between a couple of options, we actually use a more performant, non-matching syntax for that group, which again, you might not normally think about using, but is actually more performant, and no reason not to use it. So there's some good things there. We also prevent

 

I'm imagining

 

you...

 

most people are like me in that they're thinking, I don't know what any of that means and Redject scares the hell out of me so I'd rather just use you to do it for me. So this is awesome. I think this is a great tool. I use it for sure and I think everyone will benefit from it.

 

It's also, there are some other foot guns. Like if you have a global versus non-global regular expression and you hit it with match.match, like a string.match, the regular expression, it will return you different things, either an object or an array based on whether it has a global flag or not. If you hit match all and it's not a global expression, it will throw an error. You know, there are a lot of things And this is not typed at all. So if you're using regular expressions, you have no way to know that it's not going to work until runtime. And it might be an edge case and you never hit it until production. Whereas magic rejects actually will throw those errors for you type wise in development. So if you add that global flag or not, it will change the return type of the object. It's also fully typed in terms of, so for example, if you have a named group, it will type the return of the.groups property. It even is fully typed with regard to anonymous groups. So if you normally put some brackets or parentheses around a bit of the word, it will not only not allow you to access the index of a group that doesn't exist, but when you do access the index of a group that does exist, it will actually give you a hint and show you the bit of a regular expression that it matches, which

 

Yeah,

 

is

 

it's great.

 

really, really good. Yes, and that was written by David Tai, by the way, collaborator who's been working with that project. with me on the project. And sorry if I'm going on, the whole thing

 

No.

 

compiles, it compiles to a normal regular expression. So in your built library, there should be no trace, like your app, there should be no trace of magic objects, because I have a transform which basically takes your regular expression, as long as there's no dynamic bit of it, it will compile it to a normal regular expression. And

 

It's amazing.

 

like

 

The thing I like about it the most is that it allows, there's nothing more confusing than coming into someone else's component or a project or whatever and seeing just this big chunk of regex and no explanation about it. You know, it's just this big assumption that like, ah, whatever this complicated piece of regex that you've generally found on stack overflow, whatever that is, the person reading it, you're expecting is that knowledgeable to be able to understand what was happening here, you know, or to tweak it in some way. Like you'll see some big chunk of rejects and it'll be like manipulating the title to remove, you know, unwanted character. And you're like, okay, what unwanted character? What title, you know, what went wrong here? Yours, it's written like regular language. It's, I mean, it's a podcast and people can't see it, but if you've ever used like an ORM tool or like a really easy... uh, like way to kind of search for something. It's kind of like that. Um, so there's a lot of like dot and this thing or this thing, you know, it's not a whole bunch of weird symbols. So it's really easy to read after like what someone else wrote. So in a team environment, it's, it's incredible. Like even if, I would say even if you're a team and you feel like, ah, you have someone in your team who knows regex like, or is very comfortable with it. Generally that person ends up writing all the regex for everyone else. you should still probably just not do that anymore. I think you'd still benefit from using Magic RegEx because it just brings it down to everyone's level. Again, it's like reducing the learning curve is huge, I think, and you get a huge benefit across the team from doing things like that. So I think Magic RegEx has been really exciting. Anyway, the domain name is regxp.dev. We'll put it in the link, but it's really worth checking out.

 

I'm taking notes. This is all great. It's going to go in the testimonials. Thank you.

 

Good, fair enough. You should. Well, Daniel, I think that's enough time for you that we've taken up and it's late at night for you. Is there anything else that you want to touch on for the NUC stuff that we missed, maybe?

 

There is so much to say but definitely, definitely keep your eye on the announcements that are going to be coming out from Nuxt, particularly next week. So next week, keep your eye out because we're going to have a really exciting announcement and I think it's going to really, it's going to transform how people, how people Build how people It's going to transform people's development experience with Next. I'm not gonna say too much more, but you might be able to guess.

 

Exciting stuff. All right, is that gonna, cause ViewConf is next week, and I know that you guys are all going there. Is that gonna come out as part of that?

 

It might, it might well,

 

Okay.

 

there might well be an announcement at PJS Amsterdam.

 

Yep, nice, exciting stuff. All right, cool. Well, normally this is where Steve would kind of wrap it all up for us, but he has disappeared for some reason. Technical problems. So we'll just do it ourselves. Normally we finish up with some pics. So these are just things that we found interesting on the internet over the last couple of weeks or whatever it is and things that have piqued our interest. So Daniel, do you have any pics that you want to drop in there?

 

I think I would have thrown people towards trying out Elk. That would absolutely be something I would recommend. I've also, if you're in a leadership role in your job, I highly recommend Sarah Drazner's book, which I have. I think it's a great book. It's a great book. have it's actually in my bag. So I can't pull it out right now, but totally check out her engineering management book released recently. It is fantastic. And it's also it's got a beautiful cover as well, which is reminiscent of books of the past.

 

Awesome, yeah, I wanna check that out. On that note, that just reminded me of an amazing book that we read, that we had everyone at Funk House Read that changed the game for us. It's called Run Studio Run. If anyone is running a creative agency, you should read that book. It's incredible. Called Run Studio Run. Cool, well, my picks are a sort of skewer CSS one, which I love to talk about. It's called It's a new CSS function called where. So it's a where function, which is weird to think about that in CSS if you haven't used these before. But essentially it does hold, it's hard to explain, but the big thing that it does is it reduces the specificity of your selector to zero. So this is something that you might not be familiar with in CSS, but generally the more specific your selector, the higher the like, essentially priority that that rule will have. So you've noticed like if you use like an ID to select something that that will override the same thing if you use the class to select it. And you know, and it goes, there's a whole lot of rules that get used there. Like if you use just an element selection or, you know, two classes in a row, and there's a whole bunch of rules that go into that. But if you're developing a component that you're going to share to other people, Like for us, we have, we built these video player components. So it's a custom video player and we use it on a lot of different websites. But essentially, whenever we drop that onto some one of the websites we built, we kind of want to override a whole lot of the styles that are in that component on like the color of the play icon might be different on every website. Right. And so a where clause or where function is really good for that because you can say, Hey, I'm gonna give you a whole bunch of styles, but I want them to be very easy to overwrite. And that's what the where function does. So we'll

 

Hmm.

 

include a link that kind of explains what that is. And there's another one that goes with that called an is clause that is like a game changer too. So take a take a read of that, some interesting CSS stuff. And then on that note, I came across this incredible CSS guru named Brad Woods. And I'm gonna give you a link to his website and he's got a whole like kind of like, I don't know what you would call them, but they're not really tutorials. They're more like showcases of like incredible stuff you can do in CSS. And he's one on like 3D in CSS, not 3D, like don't think of like building like a game or something like that. More like there's a whole lot of CSS properties that describe 3D effects. So like perspective is one of them. And we've built some really complicated websites that include weird 3D perspective animations and stuff. using some of these functions and it's really worth looking at and getting a crazy world of CSS is just getting more and more crazy. So those are, that would be my pick and I'll be in the show notes. So this brings us to the, the highlight of the show for a lot of people which is these, these dad jokes that Steve would tell and he's not here to tell them. So he, he chatted them to me and Daniel. I feel like in the spirit of fairness, we should probably read one each, Daniel, because I'm not sure if I've got two in me. So,

 

I've got one of my own. I've got one of

 

you've

 

my

 

got,

 

own.

 

oh, okay, so we have three. All right, well, I'll read two of them and then you can read your own one. So, all right, so I can't do Steve's accent, but if I could, I would do it here. So, the nurse, a nurse says to a man, we need to get a stool sample and a urine sample. And then the man turns to his wife and said, what did she say? And the wife says, they want your underwear. And this would be where we would have some drum snares and stuff from Steve, but we've also lost our sound effect guy. So that was one.

 

I'm not reacting to that. That

 

No, that

 

will

 

was painful.

 

go, we're passing that over that

 

That's

 

one.

 

painful. Next one. Teacher, so Daniel, if you had $5 in one pocket and $20 in the other, what would you have?

 

My answer? Somebody else's trousers.

 

That's... yeah that... yeah that's rough too.

 

Uhhh

 

Um... well Daniel, you have to follow up with your one now.

 

So how did pirates communicate before computers?

 

I guess a message in a bottle.

 

It was peer-to-peer networking.

 

That's good, I actually like that one.

 

I'm not substituting for Steve anytime soon, he is the master there.

 

Well, that brings it to a conclusion here. Daniel, thanks so much for your time, man. And also thanks so much for all the effort and all of what you're doing for the open source community. It's been incredible.

 

That's a privilege. Thank you for having me on.

 

Yeah, thanks for your time. All right, I'll talk to you later, mate.

 

Okay, talk to you later. Is there not any more to upload?

 

Yeah, you're gonna have to crop the end of this one Steve. I Guess not. I mean, it's probably uploading in real time, so

 

But edit, they probably edit anyway, right? And I'm sure there's some editing that happens.

 

Yeah.

 

much editing. The cropping out of fandom, aside from Daniel, that will have to happen. That's a great site.

 

That was great. Okay cool. Well, do email us if you need anything Steve. Like any of these links or anything. And I'll leave and hopefully it finishes uploading. See ya.

 

Bye.