EPISODE 1676

[INTRODUCTION]

[00:00:00] ANNOUNCER: Vue is a popular JavaScript front-end framework. And Nuxt is an open-source meta framework on top of Vue. Anthony Fu is a framework developer on the Nuxt team. He joins the show to talk about Vue, Nuxt, open-source development, and more. 

This episode is hosted by Josh Goldberg, an independent, full-time open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ESLint, the tooling that enables ESLlint and prettier to run on Typescript code. Josh is also the author of the O'Reilly Learning Typescript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch. Find Josh on Bluesky, Mastodon, Twitter, Twitch, YouTube, and .com as JoshuaKGoldberg. 

[INTERVIEW]

[00:01:02] JG: Anthony, welcome to Software Engineering Daily. How's it going? 

[00:01:06] AF: Yeah. I've been good. Thanks for having me.

[00:01:08] JG: Oh, and it's our pleasure. Could you give the audience a little introduction? Who are you? And what's going on? 

[00:01:14] AF: Yeah. Sure. My name is Anthony Fu. And I work for Nuxt Lab. I'm kind of really active. I'm really enjoying doing open-source. As for the title, I'm the core team member of Vue, Fleet, and Nuxt, of course. And then I made some open-source projects. Testing framework, VTest, and CSS framework, windows CSS, and a slide maker for - that you use markdown to do the slide, which you call a Slidev. And, yeah. 

[00:01:47] JG: That's quite a few projects. How often would you say you start a new project that's open-source? 

[00:01:53] AF: I think it depends on the scale of the project. It can be a small library where it can be a few lines of code. It happens every week, I guess. But for big projects, I would love to do more. But it really depends on when you got the inspiration. Not often. Maybe one or two a year, I think.

[00:02:14] JG: Sure. Only one or two big projects a year. 

[00:02:17] AF: It's not that big, I guess. Yeah.

[00:02:18] JG: Let's take a step back though. How did you first get into programming? 

[00:02:22] AF: For me, I think I got into programming quite young, I guess. I think I start as a primary school, five grade, which is like 13. I got to into open-source because I got a friend, the same age as me, who somehow get know how to do the programming. And he shows me that how he got to do with the Visual Basic and a few like very cool app. It's like recording your keyboard on the background and save to a text file so that you can trick your friend to enter their password. And later on, you can get their password. Something like that. This is very cool. I didn't know this is possible and then you can write it. That's how I get into writing code. 

I starting by learning Visual Basic. And then that time it's like 6.0, which is compile directly to Windows. But I think the very good part compared to now front-end is like you got a visual. You can jog the button and bind the events, something like that, which is you got the feedback very quickly. That really help me to get on board, go programming, because you can see what you got. And you can show your friends what you made. 

And then I took the computer science degree at college. And after getting college, I think, "Okay, it seems like everybody is saying that if you do open-source is a directly proof of your skills. And they're probably good for looking jobs." Something like that. That's how I starting to trying to do open source. And interestingly, end up staying at open-source. And now I've been super lucky to work for Nuxt Lab, which now it's like I've been working full-time on open source. I wouldn't expect my career to be like that. But so far, I'm pretty enjoying that. 

[00:04:12] JG: Would you give that same advice to folks who are now in college that open-source is good for your career and finding a job? 

[00:04:17] AF: Yeah. I think it still do. And so, I think open-source is something that it's basically building public, right? It's basically what you did and how you communicate with you also do. It's also present on open-source. It's like even though you don't get into working really full-time open-source, when doing open-source, you got to practice your skills and you can try to learn and see a lot of problems in different ways. I think that really helps. 

And so, even you got into enterprise to work on something different, still, the skill of solving problems or skill of trying to - even creating issues, you also need to know how to face your problem, face your questions and how to communicate and collaborate with each other. And I think that really helpful. 

And if you are in college, I think that's - for me, that can probably be the perfect chance to get into open-source because you have a lot of time. And you can purely focusing on those different task. Yeah.

[00:05:25] JG: Yeah, it's funny. There seems to be different stages of growth in joining open-source. The first one is doing it at all. Whether it's your first issue, or sending your first pull request, or just open-sourcing a repo. And then after that, some people stick in and keep doing things. More issues. More repositories. Is there any particular point or motivator that you found particularly effective for getting people from that first issue to continuing an open-source? 

[00:05:51] AF: If you mean as a maintainer, I think what I could do is I try and to encourage people to trying to solve their problem they own. But, I mean, that really depends on the issue as well. For me, I find that whenever you have a problem or you have an issue, you have a block of a certain library, you're actually the one that knows this problem the best. And also, you kind have the most incentive to improve them because it'll fix your problem eventually. 

If you kind of throw a kind of challenge or a task to the maintainer, the maintainer might be interesting and implement that as well. But it can be the maintainer doesn't need that feature. But you are the one that need it. I would encourage the original creator of that issue to try to solve this problem and if that's in the scope of the project. 

And so, I think to doing that is - even though sometimes they kind - being afraid. Saying, "I'm not good at creating issues. Not good at sending code, or sending PRs, or an PR get rejected, or something." Usually, it's hard to do the first step to know that you can actually contributing to open source project. But, actually, everyone could. And it's not that hard to do so. At least you can try. As a maintainer, I would try to encourage people to do that. 

And so, I think if you are the one that's creating issues, I think the first thing is like you maybe try to describe your problem better and to try to provide the more information as you could. And maybe, at least I think, before working on that, maybe you should ask for the maintainer if the problem or the feature is in the scope of the project. I think that would help. 

[00:07:37] JG: Yeah. for sure. It's funny. Very, very large companies, multi-thousands of workers, in some ways are closer to open-source than a small startup. Because when you're at a very large company, you might not have any personal or professional rapport with the people you're interacting with. I really respect, appreciate, and agree with your point earlier that those skills of being able to report an issue effectively are pretty transferable to day-to-day life as a software developer in the industry.

[00:08:03] AF: Yeah. I think so. Yes.

[00:08:04] JG: Do you think there any other particular skills that translate to and from open-source in corporate life particularly well? 

[00:08:11] AF: I'm not super sure. But because I think I - actually, after I graduate, I got the offer from Nuxt Lab. I never got a chance to work on a real corporation. But I think communication skill is really important. I think it kind of cover with describing issues as well as part of that, I guess. And then I think is like - I think working open-source project, because the open-source project can be owned by different people or different teams and they may have different principles, or guidance, or rules to be. Even for code style, the code style can be different. Whenever you're contributing to a project, I think it's just like maybe similar to like you going to the other project or something, they have their own rules. The first thing is like when you going into contributing a project, you have to read how they preferred contribution to be made or like what code style they prefer. And it's best you follow their code style. And to have like a consistent look of the whole, entire project. I think that may also relate it. 

[00:09:19] JG: I agree. Let's continue down your personal story towards Nuxt, Nuxt Labs. What was the first big open-source project that you worked on or created that was popular in the dev community around you? 

[00:09:31] AF: Okay. For me, it's actually in VSCode extension called i18n-ally. Back that time, I was like working at a college. I gather with a few my friend to trying to build an app with Vue. It's like what app is not important. But it's like we want to add some like different language into it. We want to do internationalization. Because we also have some friends who they are learning foreign language. They are major in foreign language. Thinking that we can gather all those friends to do the translation for us and we can kind of collaborate to create an app. And I find, okay, the experience of doing translation is not easy, especially for non-programmers. And so, I was thinking okay maybe I could do a VSCode extension for that. Just replace all your extension, all your i18n usage into a real text, so you can preview directly for the content of the text. Rather than the key of the - in the map or something. That's how I get into open-source. And I got a lot of feedback actually. I try to share my project and people really like it. 

And then because, initially, it was only for Vue, and because I only use Vue and I only do it for my need, and people starting to asking, "Is that working for React?" They have their React project and they want to use it as well. Then I started thinking, "Okay, how I can do it? How I can make this open-source for serve for more people?" Then it kind of takes some bigger refactor and make it universal. In the end, it kind of works for 20 different frameworks and it's also extendable. You can create it for your custom framework. Something like that. 

And during that, I find that, okay, open-source is really interesting and kind of rewarding because people send appreciation to your work. Well, the initial work is like I do it for myself and I do it for us. That's how I get into this. And also, then I kind of get my kind of confidence to say, "Okay, maybe I could do more." Then I kind of be more active in the Vue ecosystem and then eventually join Vue. And then Nuxt, yeah.

[00:11:54] JG: That's really lovely and also something that I've somehow found. The internet has a reputation for not particularly great emotions being thrown at folks. But in the open-source community, it is actually surprisingly positive at many times where folks who are doing notable known work that benefits people do actually receive a lot of praise. That can be very rewarding and encouraging as a new maintainer to do that type of work.

[00:12:16] AF: Yeah, that's true. Yeah, that motivates me a lot. Yeah.

[00:12:19] JG: Cool. Let's talk about Nuxt then. You mentioned Vue earlier. And we've also talked about Nuxt. Now not everyone particularly works with front-end frameworks or meta frameworks. Could you tell us what is Vue? And then what is Nuxt? And how does this stuff all fit together? 

[00:12:35] AF: Yeah, I'll try. I think the definition is sometimes ambiguous. And so, Vue is a front-end framework that renders your data into a DOM, which is, let's say, the view of the web page. And Vue also providing some component feature. You can do separation of concern. You can provide different components to do different task and then compose them together to eventually create your app. And that can be interactive and can be feature-rich. That's Vue. And we also have quite a few alternative like React, and Svelte, Angular, something. 

And then for Nuxt, Nuxt is a meta framework on top of Vue. You may say that meta-framework for Vue. What a meta framework is - to me, it's also hard to define. But it's just trying to providing you a bunch of different solution together and to solve different need. For example, Vue itself is only focusing on how to synchronize data with your UI, with your view. Well, that's meta framework - more on top of that is like how you define your data. How you deploy your app and how you're communicating with the server to send data or retrieve data. And how you do like search engine optimization, something like that. 

Nuxt is a metaphor on top of Vue and providing feature like SSR, which is server-side render, so that you can have the initial request from the server that's already pre-rendered with your UI. And then we can have the client-side render, which is just how Vue works. But we can mix them together so that you can write your code once and your code can run on both server-side and client-side. Which if you set up your own, that can be quite a lot of work. We handle that for you. 

And then we're providing some kind of like integration for you to make it easier, so like if you want to deploy to anywhere, it's just like you can just do it without any configuration. Because it handles all these things for you. And then if you want to install something like third-party integrations, we also have module system so that you can use it. 

Yeah. , it's more like - I don't know how to say. Maybe it's like enterprise solution. But it's also open-source. It's a package of different solution for different aspect. And we consider that for you. It's just trying to make your development experience easier and more efficient. 

[00:15:03] JG: I want to go in order of you brought up a lot of really good topics and I think they're all quite interesting. Let's start in order, first, Vue. Vue is, as you said, one of several popular front-end frameworks. Not meta frameworks. Just front-end frameworks now, such as React as well. What is so special about Vue? Or, rather, how does it compare to other frameworks such as React? 

[00:15:23] AF: I think that's - on many ways, front-end framework are pretty much the same. Their duty is just like trying to mapping the data with the UI. And whenever the data changes, you can call it state. It depends on the type of the data. But it's just like when the data changes, it should reflect to the UI, right? It's saying that if a button is been clicked or not and you should present - when you change the data, you should present it in the Vue. 

And so, I think for me the difference between Vue and React is a lot actually. It's not too much. But it's also a lot. If you're taking it very detailly. I think the different is that Vue has its own syntax called Vue Single File Components. We call SFC. That you can have your template, which is the HTML code and your script, JavaScript code, and your style, CSS into one file, into one component, so that we can have this solution for you to say the logic, the UI, the structure, and also the style is all in one single component. You only need to concern about this component whereas React does not handle it. React doesn't handle it for you. 

But react, instead, to say, "Oh, we don't care about this." And without community to do it. And then in the React, you have - I don't know, maybe hundreds of different solution for the same thing. And it's also good in another way. It's like you have a lot of choice. But, for me, in some technical taste or decisions, I kind of prefer Vue and also because I'm learning - I kind of starting to leraning Vue. And because I heard, they say that's the - in The Journal Lab, too, they will say like Vue iew is easier to learn. Other times, okay, I pick Vue. And then I stay at Vue because I also find as the later decision of Vue that make more sense to me. 

But I think in the end, it doesn't really matter. When you're looking at a website, you won't tell it's a front-view already unless you're look into it. And so, I think both side is like depends on what you use. Depends on what you need. And you can choose different framework. And I think on the high level, they are interchangeable in a way.

[00:17:38] JG: I think the way you've answered that, correct me if I'm wrong, is somewhat informed by how a lot of online discourse about these competing front-end frameworks has evolved over the last decade. Where, back in the day, folks tended to be very aggressive, very, "No, you can't use X. You have to use Y. Vue sucks. React, great. React, sucks. Vue, great." But, no. You're right. A lot of the shared ideologies between the frameworks are common. Things the concept of a component is somewhat similar between them. 

[00:18:04] AF: Yeah. True. Yeah. 

[00:18:05] JG: And they've all learned and grown through and from each other.

[00:18:09] AF: Yeah. And I think that's you can see that's also like framework trying to evolve and to adding new features. And we all learn from each other. I think at the Vue 1, the component concept, it doesn't exist. And Vue 2, we have the VDOM, the virtual DOM concept from React. And View 3, we took the view computation API, which will be similar to React Hooks. And then React also kind of takes some inspiration from Vue as well. I think they have like used transition API or something, which is [inaudible 00:18:43] that is inspired from Vue. 

And I think it's basically we are learning with each other. And the newly framework is also like they build on the concept that they already know that's the different tradeoff of different framework. And they build from scratch. But they still based on the knowledge that we kind have different experiments or different tradeoff. Yeah. T think that's also like why I'm joining open-source because it allows different opinion to exist. But, also, eventually, we are building good stuff for people, for everybody to use.

[00:19:18] JG: Yeah. It's a real strong counterpoint I think against building these things in close-source. Restricted to just one company's visibility. It's harder to let people learn from you. And then it's harder to let people contribute. 

Let's talk about Nuxt. Nuxt is a meta framework for Vue, if I've understood right. And it adds in features such as server-side rendering, nice integrations with data fetching. Are there any particular parts of Nuxt that you've been working on recently that you're excited about? 

[00:19:43] AF: Nuxt comes from - React also has a meta framework called Next. And then recently remixed. And so, I think Nuxt comes up around the same time with Next, which is around like seven or eight years ago. Now we are on Nuxt 3. And while that's Nuxt 2 was for Vue 2, Nuxt 3 was for Vue 3. And at Nuxt 2, we kind of build on top of Webpack. And I think Webpack is super popular that time. And that's probably the only valid solution at that time. 

And then for Nuxt 3, because of rise of Vite. We're thinking that maybe we should also support Vte for the better developer experience and the faster hard model replacement and maybe also the ecosystem. In Nuxt 3, we try to integrating Vue to be supported in Nuxt. But we also don't want to abandon the existing user of using Webpack for them to migrate from Nuxt 2 to Nuxt 3. Then we end up to support a bit like agnostic layer of builder so that you can use Vite or Webpack as you want. You can switch two different like underlying bundler. 

And then, also, we kind of create a kind of universal layer of plugins called Unplugin that you can write your plugin once and that work for Webpack, and Vite, and also like the other, esbuild, and rspack, or something. Then it's very interesting. And then we also have a server layer because we need to handle your API request when you host it. And how your server-side are rendered and how you deploy to different platform for the kind of serverless functions. Their output and their format is a little bit different. 

And then we have the Nitro, which is the underlying server engine that we made from Nuxt 3. But then we make it universal. It decoupled from Vue and decoupled from Nuxt, so that everybody can use it. And then now Analog, which is an Angular framework, now is using Nitro to do this thing. And for SolidStar, they're also using Nitro. 

What I want to say is we take the concept of making things universal and we're building some features, the kind of complex problem outside of our Nuxt project to make it as another open-source project and that can be universal beneficial to the others. While that Nuxt itself can be specific to the problem it's trying to solve while the underlying things can be shared with the rest of the community even though they don't use Vue. Yeah, I think that's really excite me about - we don't see it quite often in open-source, in the front-end field. Yeah.

[00:22:29] JG: Yeah. I hope folks learn from you. Before we get into each of those awesome pieces of tech you mentioned, I want shout out, there's a really interesting design principle you just mentioned here, that if you build your layer on top of composable components, that can be swapped out and made available. That A, it lets you focus on the thing you want to do more. And, B, makes more good open-source projects other folks can use. And that almost feels to me like an extension of the classic coding philosophies, single responsibility principle, or the Unix philosophy of say do one thing and do it well. Or only have one reason to change. That you're making these composable blocks that sound like good software principles in general. No? 

[00:23:07] AF: Yeah. I think so. Yeah. And I think also like if you're making your logic or something that can be independent from the original problem you solve is actually you will find a better - even better, how to say, architecture or structure of your problem. It's like you can see the problem more clearly that's why you want to do this or like how you can do it better. And then with a different solution or different approach, trying to use your solution is you can make it more universal and maybe more robust. 

I think, yeah. I think, really, also when maintaining this piece of block is actually a lot easier because you can only focusing on this scope and you don't need to worry about the others as long as the scope, inside the scope, the input-output is how you expect it. And then on the higher-level integration, you can just use as a block to build something else.

[00:24:01] JG: Absolutely. Let's dive into that, some of the building blocks you mentioned. The first was switching from Webpack to Vite. And for those who aren't familiar, could you give us a brief intro on what are Webpack and Vite in similar bundles? How do those fit into the stack? 

[00:24:16] AF: Okay. Webpack comes up with - actually, I think, at that time, it's a very innovative idea. It's trying to bundle everything into JavaScript. And so, I think back then days, you need to serve your HTML by yourself, and then JavaScript, and then CSS. You need to kind of hide those other relationships between each others and how you serve those files. And I think that works well when you serve only one HTML file or all the HTML file is like static and should be relatively easy to maintain. 

When you're adding some like dynamic-generated blocks or like when your website structure becomes very complex, it's really hard to manage those things. And Webpack comes up where the idea is like I will bundle in CSS and HTML as part of JavaScript. And then I can just - based on this page, how many different stuff you use, I'll just make it one bundle or several bundles of those different chunks. And then whenever a user visit a page, the page knows which blocks to be grabbed and then serve those things automatically. And that kind of really make the front-end to be - how to say? It's like from something that it can be only handles a small scale of project becomes - it allows you to do much more complex project in a manageable way. That really evolves the front-end word a lot. 

And then the problem becomes like - because this allows you to do more complex project, so then people will do more complex projects. For sure, right? And that makes sense. And then we kind have some like a bottleneck is like when you have too much files and the bundling and the transpiring process can be very slow. So that's maybe when you're starting a dev server, so you're trying to preview the website you're working on locally, it takes a lot of time. And like taking two seconds, fine. But what if it can be like two minutes or five minutes? And then it's like you need to wait to doing another work. 

But I think in the traditional development or maybe like compiling is just like that, I guess. But fully web is something - is when you also have different type of content, different type of app and you also want to change something. For example, if you're adding a document and the document, whenever you type some word of the content, it can take two minutes to react to be showing the web page. It's not really acceptable. It kind of breaks your workflow and trying to like mind flow. It's like when you're trying to think something but you get interrupt by - or kind of annoying because the tool doesn't catch up your mind, something like that. 

Then, for Vite, Vite comes out - because Webpack is doing a lot of work to trying to bundle in all your package, and when your page relies on a lot of things, it will kind of repackaging all this dependency. And Vite is trying to do it in other ways. We do a bundle list It's like we don't bundle the code. We just serve your code as is. But we transpire it to be consumable by the browser. 

And whenever you change your content, it's only changing that file. It's not causing the whole bundle to be recalculate and also doing this things on-demand. That means if you have a website that has a million of file and you enter one page, you don't bundle the whole one million files. You just only bundle like 10 files that's related to this page. And that kind of solve a lot performance issue from Webpack. 

Yeah, I think that's their main difference. And then I think Vite now kind grows. It's still relatively a new thing. And it's built on top of consumption. It's like browser can consume ES modules. While that's, I think, five years ago it was not possible. Vite will only be possible when the new spec of JavaScript comes out. And it's still a relatively new tool. But now it has a very vivid ecosystem.

[00:28:20] JG: Just a point of information. By ESM, you're referring to ECMAScript modules, the ratified JavaScript modules format? 

[00:28:25] AF: Yes. 

[00:28:27] JG: Swell. Yeah, that's amazing. That it's a direct reflection of work being done on the JavaScript language in the ecosystem. Making its way to the platform to allow better tooling to be built than what was there before for users.

[00:28:40] AF: Yeah, exactly. Yeah.

[00:28:42] JG: Beautiful. Right. Let's go to the next one. You mentioned after that the Unplugin universal layer. There's, if I understand right, a kind of general plugin layer that folks can write plugins for Nuxt and similar. Is that accurate? 

[00:28:58] AF: Yeah. Kind of. Yeah. Basically, because Nuxt also need to some like internal plugins to make the Nuxt convention works. And because we want to support both Webpack and Vite. And then, it basically means that, for the internal plugins, if we're going to support both bundlers, that means we probably need to write our code twice. And that's kind of debate the principle of do not duplicate your code, right? 

And so, we kind of think maybe if we could have like a universal layer that you can write the code once and that can work for both bundler and that can save us a lot of effort to maintain those things. And also, the misalignments between two implementation, which is really hard to kind of solve, right? And that can also affect the user experience because different platform can have a different behavior, which is quite confusing. We're trying to do that. 

And for unplugin, initially, is trying to build a layer between Webpack and Vite. And because Vite is also inherent from [inaudible 00:30:02]. Then we can also naturally support [inaudible 00:30:04] plugins. And then because we have these layers and we made it open-source and people say, "Okay, this is maybe a good idea." And they're starting to integrating more bundlers or more build tools into this plugin layer, and then now I think we have esbuild support and also Rspack, which is experimental. And then all these things, they are like low-level build tools. And then that means like, with this layer, the plugin you author, it's like it works for those build tools and also works for every meta framework I build on top of those tools. 

That means if you are targeting for Vite and that means Nuxt would also benefit from it. And then SvelteKit and SolidStart. And, yeah, maybe Remix. Remix is also migrating to Vite recently. That you are able to use the plugins to use for all those things. And that also like saves a lot. It's like you don't have like - if you want to do some plugin, you don't have a Vite plugin version and Webpack plugin version from different author or like with different implementation. It's not really vendor lock-in. But it's just like you are being logged into this ecosystem. When you want to migrate to the others, it will cost you a lot more to do it. 

Unplugin is just like trying to find a common feature. It's like a common part of different tool. It's not as capable as a native B2 native plug-in. But it's just like, in general, trying to providing the common part of different build tools as for the plugin. Yeah.

[00:31:43] JG: If I were an end user on a team, what would be an example of a plugin that I might want to write that would then work with the Unplugin system?

[00:31:52] AF: We have - if you heard Sentry, it's a telemetry. Telemetry library or something. And I think they made an Unplugin Sentry. That's they are Sentry integration. With Unplugin, it can work for Vite, for Webpack, and for the others while they only need to maintain one single codebase. And I think, at the end user, you're probably not going to use it directly. That for a library author, that would be more relevant. 

[00:32:18] JG: That's really nice. Sentry is also, in particular with open-source, very good about publicizing what they're doing. They've got a great open-source program headed up by Chad Whitacre. Shout-out, Sentry. 

Let's continue. You've been talking about what's currently happening in Nuxt with Nuxt 3. Is there anything coming up on the horizon that you're juiced about for Nuxt in general? 

[00:32:38] AF: Yeah. For the last year, my main focus on Nuxt is trying to build the Nuxt app tool. Because when you say that meta framework is trying to providing different solutions, it can be a little bit like - it's adding too much sometimes. It's not very obvious like what the framework is doing or like what it's doing under the hood. And whenever you have some bug from the internal of the framework, it can be really hard to debug. And you don't know why or you don't know why is this cause. Or like you don't know the relationship between parts. 

I would call it is like lack of transparency. It's like the framework becomes a black box and you don't know what is going on. And it's already hard to try things from outside. We want to improve the transparency of this black box. So, we made dev tools, which it's trying to tell you more information that the framework knows. Like how your components is being located. And what's the relationship between your components? 

And also, for user, user-facing is like how your roots being - how your navigation is being constructed and how your component is being constructed. And how your logic is being organized or something. And at a bit low-level, internally, we will tell you like how each hook, internal hooks of the Nuxt. How long they take? Or how many times they code? So that you can no better of the internal things. 

And then we also have third-party modules, right? And the modules can also providing their own dev tool integration to providing a view of how the modules is doing. For example, we have an audio-image module that can generating dynamic audio-image for different routes. And if you want to preview your audio-image, it's like you need - to the traditional way is like you need to check your source of the page and to grab the link and trying to access the link. And that's okay if you do it once. But that would be too tricky if you want to try in different multiple routes. 

With the module, providing a UI in the dev tools for you to preview. And whenever you navigate a page, it will just preview the content of it. And whenever you change some title or something, the audio-image will be updated automatically. That's something that we are trying to improve the overall developer experience and to make the things easier to use and easier to understand.

[00:35:00] JG: Do you see medium to long-term future where other meta frameworks, you mentioned SolidStart earlier, would also be able to use this kind of dev tooling? 

[00:35:11] AF: We actually have quite a few framework is already doing so. Astro, I think they announced a kind of Astro tool bar or something, which is following the similar idea. And Median. Median is a React library to improve the rendering performance. It's also providing a dev tool. And then I know Qwik is working on their own dev tool. And then Modern.js. Modern.js is also another React framework, meta framework by Binance. And they also working on their own dev tool. I'll would be really happy to see that the more and more framework is trying to providing such integration and trying to make the debugging or like the overall things better for you to understanding or manage your project. 

And we have like a relative long-term goal to say we can make a kind of dev tool kit, which is like infrastructure for dev tool that works cross-framework. But we need to take some time to dealing with the details of it. And it may be tricky to implement, I guess. But we'll see.

[00:36:19] JG: Yeah. To your point earlier, there is a lot of "duplicate work" happening. All those different dev setups, toolbars, and so on are reimplementation of the same idea. But is it possible to unify before all these implementations have experimented? Is there any work that can be done now to unify them? 

[00:36:38] AF: I think it depends on what a different framework would need. And I think maybe not unifying too early would be better for - allows different ideas to come up. I think for us it's like we kind of think that's, for dev tool, it's still a relatively new thing that's not being explored a lot. 

For example, we have a lot of data internally when we're bundling things or when we're serving content. But if we got the data and how we present it, how we visualize it, and how we make it interactive is something that no one did that before. And also, no one have exactly same data you have. That can be a challenge that you basically try and arrow. And you can build something for the open-source and then people will use it and give you feedback to say if they want this better or if they kind need some different information. And then we improve and iterate later. 

I think it's still a very new field. And so, I think different frameworks, they are now trying to present those data in a different way. And probably not unifying those things too early might also help them to say they can work - they can do more different type of visualization presentation rather than you have to use this kind of different or something. It's like you don't need to be limited by the API that's the layer, the universal layer provide. I think it definitely depends. While that's universal, it's a good thing. But it's not always the best in many cases. 

[00:38:12] JG: Sure. You mentioned the DRY philosophy, don't repeat yourself, earlier. There's a corresponding philosophy folks in the front-end also sometimes like to say WET, write everything twice. You can't really know what you're doing until you've done it. 

[00:38:24] AF: Yeah. Like a render twice.

[00:38:27] JG: Yeah. Cool. That's a lot on Nuxt. And I do want to ask also any other particular projects you're working on. Have you been playing in open-source recently on stuff outside of Nuxt that you want to talk about? 

[00:38:39] AF: Yeah. Very recently, I've been working on a rewrite of another open-source project. My project called Shikigi. And the project - it will be an ES rewrite of Shiki. And Shiki is a syntax highlighter that's based on VS Code Text Mate grammar. That means that you can reuse all the grammar you have for the VS Code. To say that if someone build an extension, A VS Code extension for a certain language, and Shiki can use that language syntax to highlight the code, your parser. You don't need to do the work twice. Well, it can providing a very accurate syntax highlight, that's the other approach, may not be easy to approach. Because as the VS Code evolves, this thing will also evolve as well because they share the same engine. 

The reason I'm doing this thing is because I find I'm actually also a maintainer of Shiki. But we have some like long-term issue about like how we're loading those grammar or how we're loading the WASM dependency. WASM is WebAssembly, which VS Code use it. And so, we have to use the same WebAssembly in order to achieve the same effect. But this is a kind of static asset, we need to import it from somewhere. 

Originally, we use a file system to read it. And then coupled with that. Because we use a file system, that means this code can only run on node. But we also have some demand that's to run on the browser or run on the age environment in a worker so that it can be relative low cost, faster. And then this dependency of file system or the file paths kind blocking that. 

And while that's - in other ways, if you want to change all these things, you need to break a lot of things. That will break the existing user. I'm thinking, "Okay, maybe a safer way is like I would do it from scratch as another project." I can break as much as I want and I can try different ideas. And then after these things, okay, this kind actually works out. I can use the ESM. Oh, yeah. By the way, a lot times, probably ESM is not popular enough for Shiki to adopt it. But now it is. Now I'm able to load a lot of things from ESM. And ESM is also trying to support the web assembly natively. But that's a spec for the future. It's not yet now. 

Basically, with the whole rewrite, it can achieve more efficient and more environment agnostic thing. And then because I break a lot of things. Trying to being creative and trying to use the cutting-edge things as much as possible. And then looking back, if I compare to what I break and what is breaking and actually I can providing a compatible layer. 

For Shikigi, it will also have a Shikigi compile package. That's just using the same engine. But it's just trying to providing the legacy format input and output. You can basically swap the original Shiki without changing any code. And then it also works but more efficiently. And while that's if you prefer the new things that you can migrate over. Something like that. 

We are trying to find a way to merging the Shikigi project as the next version a major version of Shiki. Eventually, these two project might be merged together so you don't have these different things. And I'm still talking with the original author and we are trying to find a way. That's what I've been working on.

[00:42:09] JG: Good Luck.

[00:42:10] AF: Yeah. Thank you.

[00:42:14] JG: Well, I wish we could dive into more. But, unfortunately, we have a non-infinite amount of time. And I do want to get to a few questions at the end. You have what is probably my favorite personal website background of all time. It's this beautiful little visualization that slowly grows when one visits antfu.me. Can you tell us about that and what generative art is? 

[00:42:36] AF: Oh, thank you. I think back in 2022 - no. Is that 2021? Or something? It's like I was with my friend to say maybe you should do a generative art challenge. Generative art is like you're writing some code to draw something, to generating some graphics that looks interesting. And because you have the program, the input can be randomness. You can use some random function or you can use something programmatically to generating these things. And with the canvas, you can do it dynamically. Basically, you can draw an animation. Or even with - you can do some interaction. You can grab the position of your mouse and take that data to do something. Generative art is like just creating some - any graph with some code. 

A lot of times that we are trying to do a 100-day challenge to say, every day, you're going to make generative art. Every day can be different. I'm trying to think about different way of doing that. That's why I have a website to hosting all my experiments. The link is like 100.ntfu.me is my website. 

But, yeah. Unfortunately, I didn't finish the 100-day. I think I end up at 41-day or something. But the background of my website is coming from one of the day. It's a growing tree. I call it plum. Because the branch is very short. It's more like a how plum grows. The logic itself is very simple. Also, that's why I love it. It's like you grow a branch. You draw a branch. And after drawing a branch, you kind of roll the dice. 50%, it will grow a left branch. And 50% will grow a right branch. Eventually, some branch will end up with no new branch and some branch will continue growing. 

And then with iteration, like every 500 milliseconds, you draw a new branch and then it's growing and starts growing. And that's really interesting. The rule is simple. But the outcome, I very like it. I put it as the background of my website. Yeah. I think I should do more actually.

[00:44:45] JG: That was my next question. Do you ever plan on resuming that 100 days challenge? 

[00:44:49] AF: Yeah, I do. But it's really - yeah, I think I'm really enjoying that period. It's like you trying to be creative and trying to think of different approach. But also, really tiring, to be honest. It's like you have the pressure to be, "Oh, today, you're going to finish it." And if you want to be easier next day, right? You have to think before. 

After you finish today's mission, you start to think about the tomorrow, right? If you kind have the rest of the day, you can think about it. It's like it will be easier for you to like having half a day. Or, of course, you have a life to go on. You have work to do. You have to find time to think about it. But it's like I think idea doesn't comes from hard working, I guess. You don't think really hard to come out with idea. You got a inspiration. Yeah, I think probably that part really scare me out. Maybe I should try. Yeah. But I just like think about that is just really hard for me to go back to these things. But, yeah. 

Also, I think that also challenged me a lot on my programming skills. How to do the animation? How do it in efficient way? And how you can - yeah, I think it especially evolve with the graphs. Graphics is like - because you have the metric, you have like millions of dots to deal with. And you have millions of loop. And you also need to optimize it in order to not running on a very low frame rate, something like that. I think that's really fun. Yeah, I cannot give a promise. But I probably should continue doing that.

[00:46:23] JG: Well, let me know if you do that. It'd be lovely. There is I think an interesting parallel or a contradiction, almost a dichotomy, in how one writes graphics or graphics-intensive code versus traditionally what you would want in open-source. In open-source, you want your code to be clean and readable. And someone who has no idea, anything else in the project, can come in. But then in graphics code, the opposite priority comes into play. It needs to be efficient. And you need to micro-optimize. And that can really harm readability. 

[00:46:48] AF: Yeah. That's true. Yeah. And I think that's kind of quite a challenge that's like you try to looking for the balance of both. It's like what if you can write a clean code that can be efficient? And, yeah, that's - for me is like a really fun challenge to me to work with. Because in the end, you got the fast and also clean code. And that's really satisfying. But, I mean, that's based on the fact that you're going to - you end up with that. But it's not always the case. Yeah.

[00:47:15] JG: On the other hand, do you ever feel a sweet happiness from no longer having to worry about writing clean, readable code for the prospective newcomer to just hack some crap together and get it onto the page? 

[00:47:26] AF: Yeah. I think, yes. But, also, one thing I find is interesting is like there are some like hacky code, right? And you will feel bad about it. But if you extract it into a library and you just import it from a library, you don't mind it anymore. Because the complexity is hidden in the library. The hack it's not here. It's there. I don't care. Yeah. 

[00:47:46] JG: That's beautiful.

[00:47:47] AF: But I think hack is also like a relative term to me. It's like, at this moment, when you think about an idea is hack. But it's like when you well-maintain or well-test by some library to say it can be a reliable thing if you deal with that and someone is maintaining that and probably it can be a valid solution to something. 

[00:48:06] JG: The industry is constantly learning how to do stuff better. The most beautifully written code today in the latest and greatest meta frameworks, we would probably consider that to be a hack and looking back at it 20 years from now.

[00:48:17] AF: Yeah. Exactly. Yeah.

[00:48:17] JG: Well, that's a lovely note to end on. Last question for you. Where would people be able to find you online? 

[00:48:25] AF: I have my website, antfu.me. Antfu is my handle. On GitHub, I'm also Antfu. And on Twitter, it's a with a 7. Antfu7. And I think basically like you can find all the links on my website. Yeah, it's a very pleasure to be here.

[00:48:41] JG: Oh, it's a pleasure to have you. Thank you so much. And to any users of any of your software who are listening, I'd highly encourage them to go sponsor you on - what sponsorship platforms actually are you currently on? GitHub sponsors? 

[00:48:52] AF: Yeah, GitHub sponsor. Yeah.

[00:48:53] JG: Well, that's great thank you again so much, Anthony, for hopping on the podcast. This has been a pleasure. Cheers.

[00:48:58] AF: Yeah. Thank you.

[END]