Vite+, Void(0) & the Future of Frontend Tooling: Open Source with Alexander Lichter

The JavaScript tooling landscape is fragmented. Between linters, formatters, bundlers, test runners, and dev servers, modern developers juggle dozens of configurations just to get started. But what if there was a better way?

In this episode of Monte Talks, Jakub Andrzejewski sits down with Alex Lichter (@TheAlexLichter)—Open Source Engineer at Void(0), Nuxt core team member, and one of the most recognized voices in the Vue ecosystem. Fresh from his transition from framework development to build tooling, Alex offers a unique perspective on where frontend development is heading.

We dive deep into Vite+, the ambitious unified toolchain that promises to bring Rust's Cargo-like experience to JavaScript. Alex pulls back the curtain on what "unified toolchain" actually means, how it differs from Vite, and why Void(0) believes the answer to JavaScript's tooling chaos isn't another framework—it's better integration of the tools we already love.

Beyond Vite+, we explore the evolution of Vite itself, its room for growth, and the delicate balance between building sustainable open source and keeping tools accessible to everyone. Alex also shares hard-won lessons on building a career in open source, staying motivated as a maintainer, and why your first contribution doesn't need to be code.

Whether you're a Vite user curious about Vite+, an aspiring open source contributor, or simply interested in where frontend tooling is headed, this conversation offers rare insight from someone building the infrastructure that powers millions of applications.

Read the conversation below, or watch the full podcast on YouTube by clicking here.

Alex Lichter's role

Alex: Thanks for having me. I'm Alex, a DevRel at Void(0), part of the Nuxt core team. I'm doing a little bit of YouTube tutorials here and there. You might have seen my face at conferences online. GitHub issues are also very important—I'm very likely answering your questions on social media. I've been at Void(0) for almost a year now.

I think it's very difficult to be a Vue.js developer and not have seen you at some point—in a conference, in a talk, in a video, or in a GitHub issue where you responded. I even had a very short competition with you at some point in terms of open discussions in Nuxt.

Alex: At a certain point I tried to be as fast and as helpful as possible, but the good thing is everybody won because we all helped people. That meant more discussions being resolved, so I think we're all winners in that sense.

So Alex, if you could tell me a bit about your background, specifically with Vite? That wasn't your first pick, right? You were a Nuxt maintainer when there wasn't even a term such as Nuxt ecosystem or Nuxt core team. You were this special guy who was named Nuxt maintainer. So Vite wasn't the first pick for you—it was Nuxt. So what happened?

Alex: That's true. Actually, I started all the way back in the PHP world, then made a quick stint over to Java, coming back to PHP for good reasons. I got very into Laravel, and from there discovered Vue. Then I discovered that Vue and SEO were a bit tricky back in the day, so server-side rendering was necessary. That's how I found Nuxt.js, and that was all of course way before Vite.

Alex's background, history with Nuxt and beginnings with Vue

Alex: I used Nuxt a lot. I contributed at some point—I think around when Tailwind came out, fixing some docs and examples. It was a lot of fun. I released some modules because I needed them for my projects and there were no such modules. I was like, why not open source it if I build it anyway? At some point in 2018, Sebastian said there was a conference in London—Vue.js London. I was in Dublin for an internship, so I just took a plane over. That was when I joined the core team as the fifth person besides Pooya and Clark, who are not very active anymore, and of course the two Chopin brothers who created Nuxt.

From there, a lot of things happened. Around 2021 during COVID, I didn't do that much open source but focused more on work and consultancy which I built up in the meantime. When Vite came out, the first touching point was like, "Okay, Vite works with all the frameworks," as it was originally planned as a better Vue dev server. Nuxt at some point had a Vite module and I enjoyed using it a lot. Nowadays we can say Vite is kind of the shared infrastructure of the web—every big framework besides Next.js runs on Vite or has a Vite plugin, which is pretty amazing.

What happened eventually is that Evan reached out to me. First, he announced the company Void(0), and I reached out to him saying, "Let's have a podcast episode about it on the DejaVue podcast." Then a couple of months later, almost a year ago, I just came home from the gym and saw a message like, "Hey, do you still do consultancy? Let's talk." We talked and he asked if I wanted to join Void(0). I was like, "Let's do it." So here I am. That's the rough story.

Building personal brand, supporting open-source and community

That's the amazing part of building a personal brand. You have created one. I have a very similar story with Monterail where I work right now. If you do a lot of those things such as being active in communities, contributing to open source, speaking at conferences, having your own YouTube channel or maybe a blog—people notice you. Maybe not everyone, maybe not every company out there, but the people who matter really, like the community, the creators, the maintainers, they will notice it. This thing differentiates you because you put more into appearing somewhere, helping someone, just being part of the community—not just taking everything from it.

Alex: That's right. I think it's so underrated to just share what you do. That can be a blog post—you don't have to make videos necessarily. That can even be, "Hey, I raised an issue," or "I answered this" or "just share what I discovered." Being active in a community and sharing what you're doing will help a lot. I know a lot of people who actually got jobs through that besides us as well. People who are not necessarily active in open source but wrote, "Hey, I found a way to use technology X with framework Y. Here is how we did it," and then someone got hired because of that blog post. There are all these stories, and that's really the reason why I encourage people to put themselves out there and share their successes, their learnings, their stories—no matter if in a blog post, at a meetup (they always look for speakers), or at a conference.

Meetups, events and other knowledge-sharing initiatives

It's funny because you talk about meetups. I am the organizer of the Vue meetup in Monterail which happened two times last year and will probably have two editions this year as well. I can totally confirm that it doesn't mean that you have to be a super expert. It doesn't mean that you have to have 20 years of experience. We even had one speaker who wasn't proficient with Vue at all.

Alex: That's great.

And it was amazing to hear his perspective because he was giving a talk about how he teaches AI as a React developer—how he teaches AI to teach him Vue. We have the recording of his talk in our channel. I will link it in the description of this video as well, because it's amazing to see a different perspective on the same topic like building websites but from the perspective of a completely different user who builds on a daily basis with a different framework.

Alex: Absolutely. I fully agree there. I use Vue daily still. That's the good part. But I also really cherish the opinions of other people using other frameworks and how they solve problems or how they figured out things, and then see how this might be applicable in the Vue ecosystem or which problems we maybe have solved and can contribute back. In a way, this also reflects how the story of things in the Vue ecosystem went, right? Think of Vite—that was the Vue dev server in the beginning. If Evan would have said, "Hey, we can only do it for Vue," we wouldn't be where we are right now. We might still stick around with Webpack—no offense or shame, but of course it's a different level of speed and performance. The same happens with Nitro and Pooya out there with a lot of different tools, right? So I'm very glad to see that people do that.

From frameworks to tooling – why the shift happened

Speaking about coming from frameworks to actual build tools—we were talking about React and Vue, and there are obviously other frameworks such as Angular or Svelte—but you right now transitioned from the actual framework more to tools. Could you tell us a bit more about what challenges you have there while working as a DevRel or open source engineer with tools rather than frameworks? I suppose there can be some differences there.

Alex: Absolutely, yes. The good part is I still use Nuxt quite a lot. Of course, I'm still contributing—I'm not gone in that sense. I still, for example, do videos on my YouTube channel. After the Christmas break I'll pick up the pace again. In a way, it's really helpful to work on tools that are for the JavaScript ecosystem because you get out of your bubble in a certain way. I still remember when I exclusively used Vue—I of course used a bit of React and Angular here and there to play around with it, but not seriously. Then you see bigger codebases adopting tools and you look into them and think, "Okay, this is how they structure things," or "This is how it works in Svelte land," or "This is why they need support for certain other parts." So I think you learn a lot. That's also why I value a lot going to general JavaScript conferences. Don't get me wrong—I love Vue conferences and Vue meetups, they're amazing. But you also learn so much more, especially when you work on these tools or even when you work on a framework or library, how other people solve it. And I think this exchange is very important.

Where to meet Alex? Conferences and events in 2026

Sounds amazing. By the way, do you know already for this year where people could see you? For example, in a conference—do you have any scheduled conferences yet?

Alex: So there are a few things confirmed, a few things I can't spoil yet because I want to wait for the official announcement. But definitely across Europe, also overseas—Asia will be at least one stint. Maybe in the US, that's not entirely sure. I got quite a few rejections already, which is more than fine because there are so many amazing speakers and I don't want to go to every conference as well. Of course, I try to do a bit less than last year—last year was a lot. But I'm more than sure because it's right in my city, more or less, I'll go to Vue.js Amsterdam. That's a given. I'll be around there. Other than that, I'll keep you posted on social media.

Vite+ explained – what "Plus" really means

Sounds great. So speaking about Vite, maybe we can now move to the topic that was quite interesting and quite a discovery last year, which is Vite+. A lot of people were discussing what it is exactly. There was even a thread on Reddit asking, "What the heck is Vite+?" So maybe as a DevRel at Void(0), you'll be able to share with us more about what it is, what we can expect from it, for whom this project is specifically, and basically anything you can share.

Alex: Anything I can share? Okay, let's start with that. So right now our JavaScript tooling landscape is very scattered. We have three gazillion tools for everything. Actually, someone was mentioning that on Twitter the other day—what we want is less tooling. We don't want to have yet another config, yet another thing to change, and "Oh, now I have to make sure that this actually works with all my other tools. Oh, if it doesn't, what do I have to do?"

Ideally, other languages have that kind of solved. Rust is always a good example where you have Cargo and Cargo can do everything from running the dev build, testing, docs, running the actual build, linting, formatting—you name it. In the end, this is our goal at Void(0): to build this unified toolchain, as we call it, to give the same experience. Have a single config, then in there configure your testing, linting, formatting, your build tool, your dev server, and all of that in one single tool.

Now, of course that also gives a lot of opportunities and there is still a lot of vague parts. But this unified toolchain idea is not crazy new. Once again, other languages did that before. A lot of sane languages did that. There were other projects trying the same—Rome unfortunately failed. But I think with Void(0) there's the best chance to make this thing a reality and also to maybe reduce the laughter about JavaScript like, "Ah, it's not a real language, you can't even run a test command," something like that. To not be a joke in that sense, but also to make JavaScript developers more productive than ever before because things just work. You don't have to worry about, "Oh, what other tool do I need here?" No, you can just use it.

The best part is if you have a bigger organization, this is also the same across your team. It's not like, "Oh yeah, here we use Jest, and here we maybe use the Node native test runner, and here we use Bun test, and here is Vitest." No, just one single thing for everyone. Of course, you can configure it slightly different if you want to have other rules, but the commands stay the same. You have this feeling, like if you use a framework in different teams and it's not necessarily just plain React but something that's more structured and uniform, you have this feeling of coming home. For example, for Nuxt—if I go to a Nuxt project, I know where my things are. The same will be with a unified toolchain, and Vite+ will basically allow all of that.

Now the important part is that the single parts of Vite+—the commands like Vite test, Vite lint, Vite format, Vite build—they're all open source tools. We have Oxc, namely Oxlint and Oxformat as linter and formatter. They are separately available in open source under MIT, same for Vite, Vitest, and so on. So the idea is that Vite+ is this umbrella CLI on top of it that combines all these tools, has this single configuration, and very importantly, can make use of knowing all of these tools together. Because someone also was like, "Yeah, why can't we just stuff that all into Vite?" Well, Vite is not this umbrella unified toolchain CLI—it's just, in big quotation marks, just the build tool right now. Giving that all into Vite doesn't really feel right. It doesn't really feel like this is all Vite's responsibility. That's why Vite+ is there.

The idea behind Vite+ What's included and what's not

That's a great answer. I have one more question related to that because I've seen some comments. You know, there is this ongoing meme in the JavaScript ecosystem that every day is a new JavaScript framework or new JavaScript tool. So the biggest promise of Vite+ is that it's not one new part—it's more like you will replace everything with the stack, the Void(0) stack, which is Vite+. For example, it's the linting, the formatting, the build, the test—everything. Not that it's just another JavaScript framework, right? Did I understand it correctly?

Alex: That's correct, yeah. The idea is that you can use the framework you want. It doesn't matter if it's Vue or React or Svelte or Angular—well, Angular has partial Vite support but it's a different story. The main part is if your framework supports Vite, you're good to go. That's the big idea. You can leverage all the benefits there, and also it shouldn't keep you from using your own tooling. If you say for whatever reason, "Hey look, we need a different tool in the mix," well then you can add it. Or say like, "Oh, I have to use ESLint because of some really weird customer requirement," who knows—then you can still do that. You're not forced to use the tooling from Vite+, but of course it's there to provide a default to make things easier. So every deviation from that is at your own risk, but right now everything is at your own risk, so we still win in that sense.

Also to add on that, there is also more because Vite+, given that it's aware of all the tools and also of your project structure, will add some additional features like better monorepo support and also a task runner and caching. So you don't have to worry about, "Okay, I run the build test. Oh, nothing changed. Okay, here we go"—it's just there. Same for everything that's outside of the Vite+ stack itself. The task runner will also cache commands that are not part of our tooling.

Cooperation possibility with other tooling: UnJS, Nitro

I see. In terms of that, I see some similarity with one more organization or team that I know of, which is UnJS run by Pooya, because he also mentioned Nitro and possibly hundreds of other packages that Pooya maintains such as H3 or Citty or everything else that is also part of Nuxt. So do you have in mind some kind of cooperation between those two entities? Because UnJS is also in some way trying to unify the JavaScript ecosystem but from the backend side. Do you see some opportunities here to join forces, or is it completely separate?

Alex: I would treat them as two separate things, but that doesn't mean we don't collaborate. For example, Nitro is a Vite plugin now, right? Nitro v3 alpha or beta is out now already and can be run as just a Vite plugin. So we also see that things are getting closer to this standardization—but also in big quotation marks—but more like aligning on that Vite is this shared infrastructure of the web. There are a couple of options where UnJS is very helpful, for example with Nitro and H3 to make it easy to have server rendering with Vite—not like the low-level part, but just like, "Hey, I need some API routes," or I did it for an internal thing, "I just want to have some basic auth." I slap Nitro on it, set it up, and we're good to go.

So I think that is a part where Nitro and UnJS really shine. Of course, if you decide, "Okay, I want to use API routes or have a framework on top of Nitro," then you can also of course run it in Vite with that. In that sense you have unification that you say this is runtime agnostic and platform agnostic, while Vite+ is also runtime agnostic. So there are some similarities and it also doesn't force you to use a certain platform, because for deployment that's right now still up to you. But who knows if that will be different in the future in terms of a deploy command or something? This is personal ideas—it's nothing set in stone.

I see. Nothing shared yet.

Alex: No, that's also important to mention. It's a good call. Given that there is no public availability of Vite+ yet, we're in contact with a lot of people who signed up. You can still sign up on vitejs.dev to get on the waitlist and get in contact. We step by step open up the circles to get people to test it. We want to make sure we dogfood ourselves. That's also happening right now with a lot of our projects, which means we discover pain points that we as developers have, and the same that maybe AI agents have. We also want to make sure that Vite+ is AI-ready, so to say. We're not an AI company magically, right? But still in the current times, we have to make sure that agents work well with these tools too—even if that's like, "Okay, you use Vite+ and you make sure that there's an agent.md already pre-filled with all the important information on how to set up things and use things so it will just work."

Vite vs Vite+ What's the difference?

Okay. In terms of comparing the whole Vite+ initiative to just Vite—because Vite is fully open source, anyone can contribute, anyone can use it—Vite+ is probably aimed more for the enterprise, right? Because the unified tooling... Does it mean that I cannot use it as a regular developer? What are the restrictions? Is it possible to contribute to Vite+ when it will be live, if you could shed light on this as well?

Alex: Yeah, so Vite+ itself is not MIT licensed, which means we plan to make it source available. So the source code is out there, but it doesn't mean you can just reuse it like you can use Vite. The idea behind that is of course it's a commercial product eventually. Regarding the pricing and how to commercialize it, there are still a lot of ideas in the room, so there's nothing set in stone. There are a couple of options, but the main point is that Vite+ shouldn't be an enterprise-only product in that sense, because how shitty would a unified toolchain be to say like, "Hey, only the enterprise people can use it"? That's not the idea.

In the first draft, the idea is like, "Okay look, there's a generous free tier—individuals and smaller companies and OSS and charity can just use it for free and we're good to go." As I said, there are also other options that we're exploring, so we'll have to wait to be closer to the first or next announcement or first releases to see what's in there more. But what we definitely want to do is we want to make sure that we do not gatekeep. We want to make sure that people can adopt this toolchain, can use it, be productive. But on the other hand, we also want to make the toolchain itself sustainable, because right now everybody in open source is suffering from that.

We've heard about Tailwind having to let go of 75% of engineering, for example. We've seen it with a lot of other projects as well that the funding is simply not enough. So there has to be some kind of commercialization, and we also want to make sure that you can still have the full power of the open source tools. It's not like we want to start moving features from Vite over to Vite+. We don't start gutting the tools. Actually, that wouldn't work because Vite+ uses these open source tools, and if they wouldn't work well, if they wouldn't be adopted, well, Vite+ wouldn't work. So it is in our interest to keep open source sustainable so we can also continue developing these tools in the toolchain and making sure that it's also widely adopted.

These are not always fully in line and it can be a delicate balance, but also there I think Evan with Vite and Vue has proven track records that he can create very decent open source projects and has the open source community in mind.

Making open-source projects profitable - possible or not?

I remember one discussion in Bonn—was it last year or the year before?—when we were there for the Vue.js DE conference. Both me and Alex were giving talks and we also participated in a discussion. I think the topic was about open source maintenance or maintaining open source. There was one question from the audience: "How do I make it profitable by building open source?" And I remember that all of us who had some experience in open source, we all agreed that it's not an easy task.

Alex: No. I think for frameworks it might be a tiny bit easier because they are user-facing or for bigger libraries, but even there we see Tailwind CSS struggling and it's the most famous CSS framework right now. So even if it's popular and user-facing, it doesn't mean you just make money. So if you want to make money, open source is definitely not the right type of industry. You might want to go into finance or cybersecurity or something. But that's also not the main point, right? The goal is not to milk the cash cow. The goal is to create a sustainable toolchain for the JavaScript ecosystem based on open source tools.

Yeah, I agree. I think the best way to do open source is to just do it when you have free time and you do it just for fun, because if it becomes your way of living—like how you earn money for living—you start to rethink how you need to build it, how you need to develop and evolve the project. You start not thinking about how I can make the best software for the users to use and how I can make the community grow and help them develop using the tool. It's more like, "How can I make money out of it just so that I can survive until the next month?" If we're doing it in our free time, we focus on community, right? We focus on the users, on the people who we are building this project with. If we cannot afford that, we are focusing too much on enterprise while making it open source, which possibly won't work. That's my guess.

Alex: Yeah, I think I'll try to be a bit nuanced here because it's difficult depending on what projects you work on and also if you're the sole maintainer of a project or if you have a bigger team. If that team is funded—for example, if I take a look at the people working at Void(0), most of them work on open source projects like Oxc, like Rolldown every day. Their commit graph is just all green and they get paid for that. So in that sense they make a living from open source, but of course the idea there is that this is the part of a bigger thing, for example Vite+. But still you have the benefit that people can use these tools out of the box if they want to, right? Vite+ gives a lot of convenience and a lot of benefits, but as usual you can also DIY it, which is amazing.

I think if you're an open source developer and you're not on the payroll of a bigger company, then doing it for a living always means sacrificing some parts. You can build a premium project. For example, the folks from Directus did that, right? They built a premium project, realized, "Oh, we just cannibalize ourselves and somebody comes along and builds the premium thing we built ourselves," and then that's that. So they changed license. They said, "Okay, we're not open source anymore, now we're source available, and things will become open source at some point after the age of code reached two, three, four, five years." It's a very common thing in the BSL, the Business Source License, and that helped a lot to say, "Oh, if you have an annual recurring revenue bigger than a million or 10 million or some figure, you need a commercial license."

So you can commercialize in certain ways. Other ways are of course, "Hey, I offer courses, I do paid tutorials," etc., though I guess that will also decline now in the age of AI. That might be a bit trickier. Everybody's talking about how we don't want to do hour-long tutorials anymore because nobody's watching them—everybody's just prompting and generating their content. So I'm curious how that will shift. But yeah, open source sustainability is really, really difficult, and the chances that you can live from it just through sponsorships and be fully independent in that sense are super slim. Once again, Evan is the one who was able to do that, but this is in a way a big outlier for a lot of projects where this just didn't work.

Yeah. Just looking at Evan, you know, Evan is Evan, right? Not everyone is the same. So looking at him and thinking, "I would do the same," is risky business.

Alex: Absolutely. I mean, it's also not like he started fully independent, right? Vue was also a side project in the beginning. But on the other hand, I must say that if you are in open source and you contribute, then you also of course have a great chance to get hired at amazing companies. I think this circles back to what we discussed before. For example, at Void(0), people who joined were eventually there because of their contributions to the open source ecosystem. You don't need to have a crazy take-home task—you can just take a look at their GitHub profile and see what they're doing. Then it's more about the cultural fit and how you would fit in the team than your coding abilities, because this is how you were able to show them. I think the same applies to a lot of other scenarios where it's like, "Okay, here's your GitHub link. Oh, I maintain an open source project"—doesn't have to be huge, but just showing that you can pull it off is already pretty amazing. So that's a big plus. Vite+ there we go!

Where Vite still has the most room to grow

About Vite—do you see a place or room where Vite can still grow? Because it is growing every month, every year. There are some improvements to Vite to make it faster, more secure, more stable, more unified tooling. But do you see some areas today where Vite is not there yet but could be or should be soon?

Alex: Yeah, I think there are always ways of improving. I think one part—right now the Vite Environment API is out there for a while and that already gives a good step in the right direction to handle certain parts. Like now we only have client and server, but we might have multiple different environments at once or we deploy to platforms like Cloudflare Workers and so on. So to cover that in the tool is already very helpful.

Then there are a lot of things that framework authors would like to have easier or would just have an easier life when it would exist. For example, an Asset API to have an easier time to extract SSR CSS styles, to have module types in Vite—which will come. For most of these things, you actually need to have Rolldown first as the underlying tool, and that will come in Vite 8, which will hopefully release soon. It's in beta right now, so you should try it because it's super fast and quite stable actually.

So I think there's quite some room to grow. It just takes a while. First of all, it's used by so many people out there. When we had the Void redesign, I did this little bento graphic where it showed some images, and I have to double-check—more than 4.1 billion downloads of all the packages from Void(0) including Vite. Total npm downloads is just insane. It's just wild.

I think it's good that it's not going super fast while other areas are easier to dogfood and to improve, because Vite already has a lot of security mechanisms to not introduce accidental breaking changes. We have the Ecosystem CI that tests all the framework tests with a new Vite version, for example. We have really talented team members who are giving really good input also from different framework backgrounds, which is pretty amazing.

But of course there are more things that can be improved. Also, the whole story—I read it so often: "Oh yeah, if you need SEO, you shouldn't use Vite, you should use something else." Well, you can do that with Vite. You can have server-side rendering. Closing that gap so people can say, "Hey, I want to opt in for a full framework like Nuxt—amazing. Or, oh, I go with a Vue SPA with just Vite to have it very lightweight." In the middle there's nothing—that's not entirely correct. Same for React and Next and so on. Having this middle gap closed would be really nice. So I think there are a couple of ways where this can improve.

Of course, then there's Rolldown, the bundler, where a lot of things are happening. And then we can take a look at the layer—there are so many ways and also so many open issues that can still be tackled for sure.

Other promising open-source project: Vike

When you talked about SSR in Vite without Nuxt or any other framework, I instantly thought about a project called Vike. Which is basically just that—you don't need a full framework such as Nuxt to have SSR in Vite. The project is maintained by the author... I've seen it. I talked to him actually at a conference a couple of months ago.

Alex: Yeah, the project is really interesting. The promise is really nice to have basically SSR without Vue, without React—just have it plain in Vite.

I mean, you still integrate it with the frameworks, right? But I guess the idea is to say, "Hey, this is unopinionated SSR. You don't have to opt into the opinions of a framework, but just say, 'Hey, you can do whatever you want, we'll make it as accessible as possible.'"

On the other hand, with Nitro v3 in a certain way this goes the same direction. Nitro is shifting from what I would say was more of an Express or Hono competitor to, "Hey sure, I can do all of that too, but I want to be this middle ground where you can adapt Nitro in a Vue codebase and have server-side rendering just through that and also don't need any opinions." Now you can say, "I have a server entry file," or "I don't need to use file system-based routing"—which you didn't need to use before, but it's even easier now. So I think these tiny parts, and then once again as a Vite plugin, make things really digestible and unlock a true composable architecture: "Okay, I take this framework, I take this adapter if I need SSR, and I take another thing." I think it's also good that both things exist—both Vike and Nitro—to first of all have different people with different approaches there and to see how things are developing, and maybe they can benefit from both of them in the end.

I just, when you said "Vike or Vite or Vick," I just reminded myself about the time when Evan announced that he's working on Vite. I remember this post on X or Twitter when he just shared that he was doing some experiment overnight and he has really promising results out of it. He shared some glimpse of his benchmark just showing the comparison with Webpack, and I remember the very first releases or showcases of Vite. It was so mind-blowing that you can have such great developer experience of almost instant HMR. If you even combine it with your IDE's ability to auto-save a file after a certain amount of time, it makes it even better because you have almost instant updates on your website.

Alex: Yeah, it's crazy. You can really put them side by side just to say, "Yeah, on type I see save and it will update." Things are getting even better, right? For larger projects right now, the Vite dev server can be a bit slower because of its unbundled nature. But with Rolldown and the full bundle mode that is being worked on, we kind of want to go back to a fully bundled dev server again, but still super fast because it is not only written in Rust but also written with very much performance in mind. So that would be a big blessing for especially these huge enterprise monorepos and enterprise projects.

The future of frontend tooling

Sounds great. So apart from those features that you mentioned that could be added to Vite at some point, do you have already in mind something huge that could be part of Vite? Like something that could completely change how we write or develop web applications? Let me give you an example such as the Webpack versus Vite. This is a groundbreaking change, and it's not only in one framework such as Vue, but it's like throughout the whole ecosystem. Do you think something like this could be happening or possible, or have we reached a point where we basically add on top of something that is already great and there's no need for...

Alex: I'm not sure. I think in Vite itself, the biggest change will be Vite 8 by switching out the bundlers under the hood, right? To replace esbuild and Rollup with Rolldown and making sure that things are still working out of the box, which is already mind-blowing. And also all the plugins as well—with some caveats, but most of the plugins will either be already built in so we don't need those, or will work. So I think this is a big change that applies to every framework, but it is not something that is user-facing where the users ideally upgrade to, like, "Okay, it works, it's just way faster," and that's the experience we're aiming for.

In the end, I think especially with AI on the rise, the question is how web development will look like from now and in one, two, three, four, five, ten years. I feel like we say this every time when something crazy happens. I think the question is what—first there was jQuery, right? Then we had SPA frameworks like reactive Vue. What will be the React or Vue compared to the current reactive Vue? I think this is a big question. I personally don't necessarily have an answer for that, otherwise I'd probably work on that. No, I'm kidding. But I would be at least sharing my ideas with other people.

There are some thoughts. People say, "Oh yeah, signals for example are exactly that possibly." I don't know. Effect is super interesting, more for the backend than the frontend for scripts where I use it a lot. But yeah, in the current light of how AI is evolving, I'm curious how it will go because I don't necessarily want to have a chatbot in every website. It should be more than that. But I also can't imagine just typing my prompt in the URL and just getting a website tailored to me. We will see. That's a magic mystery to solve.

The role of AI in development and DX in build tools

So as we are in the era of AI, I must ask about some things related to AI. In terms of your daily work, how do you see using AI? Does it make you more productive? In terms of your daily work as a developer, as a developer relations person, does it make you more productive? How does it help you, or does it help you, or is it something that's slowing you down and you just avoid it?

Alex: So it depends on how you use the AI, I would say, and what work you do. I think from a development perspective, if you were still on the tab autocomplete AI part, which I've been for quite a while, I think it helps me for a few things, but it doesn't make me crazy productive. But when switching to a more agentic flow or like Claude Code and you name it, that's basically generating the code for you with models that really got really good. This is really improving the workflow for me.

For example, I built a couple of internal things like a dashboard, and honestly most of the code is actually written by AI. Now people might come like, "Yeah, but it's all slop," and I have to say I thought so too, but surprisingly it's not. It's probably also because I learned it to not write slop. I learned it to use the Composition API the right way. I say, "Hey, refactor all this stuff into inline composables," which you should also do if you use Vue and don't use inline composables right now. So I need to have the knowledge about the framework and the structure and best practices and then tell the AI—coach the AI to do so. But after that it could do very well.

So I must say if I would have done the same work for some internal tools by AI versus by hand or with autocomplete, this would have taken me way, way longer to be fair. So it definitely improves workflows, but this is for engineering work.

I think for more—I don't want to say, well it's partially creative work—I would say for writing, for example, as DevRel I'm responsible for most of the social media posts that are on the Void(0) accounts. And there, for example, I post at least three posts a week—two about Rolldown, one about Vitest. People might have noticed that. There it's about highlighting features that might be older and people don't know about, or maybe it's a new thing that could be interesting.

So there I still prefer to write in my own voice, of course, but it can also help to say, "I don't know, let's use AI and say, 'Hey, go through the release notes and take a look at some features and tell me what you think could be interesting and why.'" So for a bit of ideation—no, I don't say, "Okay, I just copy-pasted the first ten things and I'm good." I still evaluate them on my own because obviously I know what I already wrote about or what maybe gets an update soon—I want to wait a bit—or maybe what might not be that relevant for people or for a certain target group, etc. But it can already help process a lot of unstructured data, which is quite helpful.

Same for things like suggestions for phrasing sometimes. So I said I want to write things in my own voice and it's still true, but sometimes as English is not my native language, it's nice to say, "Hey, give me three options to rephrase that. Here is what I want to reach for." That's definitely making me more productive and the result cleaner while still keeping my actual voice and tone. So from that perspective, we have this creative and more content work versus the development part. Yeah, I'm curious where that will go.

Staying motivated and active in open source long-term

I completely agree on the topic of English not being your native language. Even though I think both of us speak quite well, we still are not native. We still don't know every possible word and we're not such fluent in this language. This helps a lot. I can totally agree. When I'm writing some articles or some documentation or maybe for internal projects I'm writing some specs like technical specs, it helps a lot because we are not native—this is not our native language. So I completely agree on that.

So now if we can move on to open source and motivational topics, I would call it like that. What motivates you to be in open source for that long time? Because it's not like one year, it's few years at least, if I'm not mistaken. So what keeps you motivated to do all of that?

Alex: I think motivation also changed over time in a certain way. First of all, the people obviously—the people working together with them. They're just amazing. So big shout-out to them. It's always great to learn from each other, to have healthy discussions, to solve problems together. So in a sense, it's also the community part. Definitely not the money—we established that before. Not saying I'm starving and going broke right now, that's definitely not true. As I also have the luxury of getting paid for open source now, at least partially, for everything that's Void(0) related. That's a blessing and I know it's quite a privileged situation. I'm very happy for that.

But even before that, of course, contributing to Nuxt was always done in my spare time. Of course, I also found a way to make that sustainable for myself by offering consultancy to offset that cost and also to pay the bills, and that worked quite well I would say. Still doing that a tiny bit, but of course given that I work at Void(0) full-time now, I had to reduce that to a good amount.

On the other side, I think open source really improves your skills. I think if you work on a closed-source project, maybe even a small team, it's really tricky because very often you get this tunnel vision of, "Okay, I have my project," and you don't even know about the latest tech and what's going on. Working in open source can really change that and keep you more in—what's going on in a certain way depending on what you're working on. That also keeps you a bit away from reality because most of the projects are kind of legacy and most of the big enterprise projects have different problems. I was in a fortunate situation still that I can see in all of these worlds through the different roles—for consultancy I see big projects and I can dogfood that back once again.

The other thing is of course giving back, right? In the end, I think a lot of projects and a lot of apps and a lot of money wouldn't be out there if it wouldn't be for open source. So I give that back with my time, with the content that I make as well that is freely available. I mean, no shame for those who don't. There's still also an option to give money, so there's your chance to sponsor your favorite people in open source or organizations in open source. That's always a good option, especially if it's not from your money but your company's money. That's a whole different conversation because then people are like, "Hey, I got it for free, why should I?" Anyway, digressing.

In the end, it's quite a few things that keep me in open source and rooted. As I said, there were some breaks to focus on other things—it's also fine if you feel like you don't want to get burnt out, which also happens quite often in open source. Nobody is forcing you. I think that's another thing—you do that because you're intrinsically motivated. You're not doing that because you say, "Oh, I need to get this checkbox in my CV or something." No, you're doing that because it's fun, it's joy, and it's great to see what people build with the tools you're helping build as well. Like if I see a website and the little Vue Dev Tools show and I'm like, "Yeah, it's pretty amazing." So that's also another thing that definitely contributes to me contributing in that sense.

Advice for contributing to open source

Agree, completely agree. So in terms of contributing to open source, to Nuxt, to Vite, what would be your advice for someone who hasn't done it yet but feels underneath that they would like to do it? What would you advise to them?

Alex: I would probably say the same if someone asked me, "Oh yeah, I never gave a talk—like a technical talk—what should I talk about?" Talk about something that you are using. Same: contribute to something that you are using. Because if you say, "Oh yeah, there's this cool project Vite, I never—of course I'm using it in—I have no idea and I'm not really interested," it's difficult. It's easy to say, "Hey, I have a library and there's a bug and maybe I even patched it already because I need to work on it, so you have an npm or pnpm patch file for that already." Fork it and then create a pull request. Or in a better manner, create an issue first. If it's well maintained, the maintainer will point it out and so on.

Drive-by issues or drive-by PRs are also a bit tricky. I still do them sometimes, but then usually as a more experienced contributor, I also know, "Okay, here this is a general way of fixing that," because of course just because it works for your case, it doesn't necessarily mean it will work for others. Disclaimer: it still happens that it won't be accepted. So the rule is make an issue first, even say, "Hey, here is how I patched it. Would that work as well, or is there anything else?" Maintainers are always happy about people first of all reporting bugs and then even being willing to fix them as a contributor. That's great.

Other than that, I like the Boy Scout principle. If you read the docs, for example, you see a typo or you see, "Oh, there's something missing," and you read through that and then you finally understood it and it clicked—someone else is probably also reading the same docs and having the same problem. So adding that—and it doesn't have to be perfect, once again—adding that there to say, "Hey, I was looking for that, it's nowhere documented, here it is," people will be very happy. Because especially maintainers of projects, they know their things inside out very often, so they have this tunnel vision that other people might have with their projects as well. They have this expertise built up. They don't necessarily see the docs from the eyes of a newcomer easily—some more, some less, right? So a fresh pair of eyes is always recommended in the end.

Also, don't go into the way to say, "Oh, only code is contribution." Doc PRs are contributions. Giving talks about it is contribution. Writing content about it is also contribution in the end, because this is how things get adopted—because there is good content about it. That's also one of the reasons why I do the YouTube videos that I would have loved to have in the beginning when I started doing Nuxt and there was not much more than the docs. Because now there is a bit more. So there are tons of ways—figure out what you like to do, don't force yourself, and yeah, then I think if you go on that with good intention, not much can go wrong.

Also, that's important for expectation management: don't be disappointed if your PR might not be merged or your issue might be closed. It could very much be that you say, "There's a cool feature I want to bring," and the maintainer says no. They are fine to do so. You can fork it. If it's a pluggable thing—for example, for Nuxt, not everything has to live in core. Write a module, and if it gets adopted, then it might—if it gets super popular—be part of the core one day. This has happened before. But there's also a reason why not everything is in the core. Everything you bring in as a feature, maintainers have to maintain ideally until the next major. They could drop it, but probably longer because then people depend on it and then it's tricky to make breaking changes.

So I think these were my very short tips on contribution. But just to top that off, if you are a maintainer and someone creates a PR or even an issue, don't respond with "No." [laughs]

Yeah, of course. A bit more context.

Alex: Yeah, I mean, "No because of X, Y, Z." For example, I also reported an issue recently to the Oxc repository like, "Oh yeah, if you have an old version and this and that, then there's not a good error message," and they were like, "Yeah, it's not worth fixing because updating is something you should consider yourself," and that's fine. So it's also all right—people have limited time as well.

Last thing, especially nowadays: please, if you submit a PR to something, make sure it's not AI slop. Maintainers hate AI slop. And with AI slop I mean—you can disclose that you're using AI, it's more than fine, but also disclose how much you actually know about the code. Like if you say, "Okay, I guided AI to do what I wanted and it's passing all the tests, I actually added the test as well, and it's looking all good," that's perfectly fine. But not like, "Oh yeah, Claude Code fixed this problem," and then just commit and CI is failing and whatnot, or in Rust way it's not even compiling or similar. There are some very base levels, and I'll tell you it is quite painful because it takes a lot of maintainers' time to respond to these issues, even if it's just an automated message saying, "This looks like AI slop, closed."

Yeah, if you want to contribute, this is not really the way. And as I said, it's not to say don't use AI—just make sure that when you submit a PR, you are responsible for the code. No matter who generated or wrote it, no matter if it was your friend, no matter if it was me copy-pasting it in a message and you put it in, or if it was AI—you are responsible for that in the end. Make sure that's the case.

Tips for developers experimenting with Vite and Void(0)

Completely agree. So now we'll be shortly moving to the closing phase of today's episode. One question to you regarding Void(0)—is there anything else you would like to share about Vite or Void(0) that hasn't been shared yet?

Alex: I think we covered a lot. I think the key part is: take a look. We got this new very fancy redesign, so if you want to see beautiful websites, feel free to take a look there. Both the agency and Simon who implemented the whole design did an amazing job there. So yeah, take a look and see some very nice animations.

But I think the main part is if you're using any of the tooling on the Void(0) stack—no matter if it's Oxlint, Oxformat, or Vite—let us know if there are any issues. Feel free to raise them to contribute in that way. Join the Discords to keep in touch. If you just use Vite and have not heard of anything I just mentioned, take a look once again—there are the websites. And well, other than that, if you use something like ESLint or Prettier, try upgrading because it should be pretty easy. I've seen a couple of migrations and also quite some open source migrations. So take a look there for not only faster build time and formatting, but also just better rules here and there as well. So I think that's that. And stay tuned for Vite+.

Where to follow Alex Lichter

Sounds great. So final question to you, Alex: where can viewers and listeners find you?

Alex: Yeah, well, as we said before, right? All across the web or at the next conference. I am on Bluesky, on X, on YouTube at @TheAlexLichter, also in the video and probably linked below. Other than that, I have a website. I always say I don't maintain it—it's kind of true. It's still Nuxt 3 I think actually, so I should update it at some point. But yeah, I think socials are the easiest—social and YouTube. I also wanted to stream again, but I just don't have time at the moment to do that. But yeah, these are the best bets. Otherwise in your GitHub issues if you report something.

Okay, great. So that will be it for our today's episode. Thank you, Alex, very much for joining and sharing with us a bit about your life as a DevRel at Void(0), about Vite, about Vite+, about open source. It was a really, really interesting discussion, so thanks once again. And yeah, see you next time!

Alex: Thanks for having me. Bye!