And now it's the proper time to do it.

Hello, welcome to DevTools FM.

This is a podcast about developer tools and the people who make them.

I'm Andrew.

And this is my cohost, Justin.

Hey everyone.

We're really excited to have Evan Yu joining us again.

Evan, you were with us on episode 12 back a few years ago talking about VUE and VEET.

And we are now like 119 as of recording.

So over a hundred episodes ago.

Wow.

That's, that's a lot of episodes.

We've been doing it a while, but it's, it's so fantastic to have you back.

We are continually big fans of your work and how it shapes the ecosystem.

So excited to chat again.

And we're going to talk about what you're up to these days.

But before we dive into that, would you like to tell our listeners a little bit more about yourself?

Sure.

Hi, I'm Evan.

I am, I have been an independent open source developer since 2016.

And I worked on VUE.

I still actually still work on VUE.

I work on VEET.

And just recently we started a company called Void Zero and focus a bit deep, even deeper that goes into, you know, the full JavaScript tool chain, starting from servers, no, no, no, starting from parsers to linters, formatters, bundlers, transformers, everything that supports higher level tooling.

So the bundler we're building called Rodan is going to support VEET in the future.

And VEET is now supporting a lot of other frameworks.

So essentially we're trying to build this vertical unified tool chain that can support all the frameworks that depend on VEET today and hopefully make everyone's development experience better.

So back, back on that old episode, a long ago, you had actually just released VEET.

And since then it's really become like a pillar of the industry.

Like many a meta framework is based on it now.

And it's like the starter pack for everything.

What was the journey from getting, going from VEET to, oh, we actually have to rebuild most of what's below the surface level and form a company around that?

Yeah.

I think the idea started at one point because when I first started VEET, I was just doing a prototype, honestly, right?

So I pretty much just took whatever that's available out there and try to fulfill the goals.

And there were a lot of trade-offs and nowadays I consider them kind of hacks because I didn't have the, you know, the bandwidth to do all the things myself.

So I have to use what other people have built.

And that's, I think that's typically what we've been doing in the Java ecosystem because we feel like, okay, like we don't want to necessarily reinvent the wheels.

Why not just use things people have already done?

So in the beginning we were, I was using Rollup because I've always liked Rollup's

API and then we ran into performance issues because, so the first step of VEET was to have a native ESM dev server, right?

That sounds simple.

And then we use Rollup to try to handle the dependencies because some dependencies are in CJS.

We want to convert them to ESM so they can load in the browser.

But Rollup was actually quite slow if you have large dependencies.

And so we started using ESBuild for that purpose.

And then we tried using ESBuild for production bundling and it was not satisfactory because it has no control over how the chunks are split.

And the way ESBuild splits code is just a bit counterintuitive if you're building applications.

So we're like, okay, now we need to think about, okay, we use ESBuild for development and pre-bundling, but we use Rollup for production bundling.

And we kind of smoothed over the surface to make them work kind of the same way.

Right?

And later on when people started building real applications with VEET, for example, when people are using VEET with React and previously everyone was using Babel because Babel was supported.

Interestingly, if you use VEET by default and you write JSX in TypeScript, they are transformed using ESBuild, which is quite fast.

But the moment you want hot module replacement for React, now you need to use Babel because ESBuild does not support hot module replacement transforms.

So then Babel, again, made everything slow.

So people also came up with an SWC version of the React plugin.

So you see the problem here is there are great tools out there, but some of them do this, some of them do that.

And now some of the things they both do, they decide to do them differently.

And that's the reality that we're kind of dealing with in a JavaScript tooling ecosystem.

I'm pretty sure if you've worked with custom build stacks long enough, you understand what I'm saying, right?

So in a lot of ways, the reason people love VEET is because we kind of hide this complexity away from them and try to give you a very smooth and consistent entry point so that you don't need to think about these things.

But we're kind of, for me, I think we achieved this goal with the initial version of VEET, but long term wise, when people are starting putting more and more dependence on VEET, right, we've seen more and more frameworks moving over to use

VEET as the base layer, I kind of start to worry because I feel like, you know, the internal is not as pretty as it should be.

And we kind of just swept all the deeper problems under the rug and pretend everything is great.

So I guess deep down, you know, along with VEET's growth and adoption, I've always had this, like, inner urge to say, like, is it really up to the task of being the future of all these, like, next generation frameworks serving as the infrastructure?

Will VEET be able to live up to that expectation?

And I don't think it will if we just keep using this sort of fragmented internals and try to stitch things together and smooth all of the inconsistencies.

In a way, the tool chain we're building right now at Voice Zero is an attempt to kind of attack this problem more fundamentally.

Let's say, like, if we want to solve all the problems we want to fix in VEET, what do we need? We need a bundler that actually is designed for it.

And we need this bundler to be also built on top of a tool chain that can, you know, handle all the different concerns, like starting from the AST all the way to minification and production, bundling, right, through a consistent system.

And at the same time, we also want to make each part of this tool chain individually usable.

So let's say you want to just take the parser and do something crazy with it.

You can totally, you should be able to do that, right?

This tool chain, although it's unified and it's a coherent system, it should not be a black box, right?

You should not have to say, like, you either take it all or you can never use it.

So I think that's, these are the two main premises that we're sort of centering the tool chain around is unification, but without sacrificing the ability to, of composability.

We'd like to stop and thank our sponsor for the week, Mux.

If you haven't heard of Mux, Mux is an awesome platform that makes adding video to your product easy as adding a few libraries.

If you never had to add video to a product, you don't know how many pits of failure there are, whether it's file formats, delivery, uploads, or even playback.

There's so much to worry about and so much that will bog your team down while trying to ship a stellar product.

So that's where Mux comes in.

They have a set of APIs and components that make adding video playback to your app or platform super easy.

And since there are a bunch of experts that know video inside and out, they'll have so many different features that your team would never have the time to get to.

One of those things being metrics, they have all sorts of different fancy metric dashboards to understand how people are consuming video in the apps that you ship.

Recently, they've been adding even more capabilities to their platform.

Now you can see when viewers dropped from your videos, so you can gain better insight into how people are consuming those videos.

So if you want to add video to your platform and you don't want to spend weeks to months doing it, head over to Mux.com.

And with that, let's get back to the episode.

So you've been a independent developer for a while and probably one of the most successful, being able to work on a lot of open source projects and produce a lot of very successful open source projects while working mostly on your own.

And now you're going this route of, so you've raised some VC, you're forming Void

Zero, you have a few people coming to join you to like work on this ecosystem tooling.

So why did you decide to make that transition from independent developer to starting a company?

And like, what about the timing or the circumstances made this a different choice?

So I think overall, I would actually consider myself a pretty risk averse person.

Some of the biggest decisions I'd made in my life, I kind of feel like I just swinged it, but like going fully independent to work on Vue, I didn't really know what that would entail. Luckily, I think I built a lifestyle entrepreneurship, kind of lifestyle business thing around Vue.

So that is enough to sort of support me and make my life sustainable.

So on top of that, right, I'm not starting a company because like, oh, we need to make more money. So that situation.

It's more about starting the company is the more realistic way to essentially fulfill the vision that I'm trying to achieve.

So it's also partly based on the experience of working as an independent developer.

I kind of know where the limit of the current model can go.

I think a lot of people kind of use Vue and use me as a success story example for sustainability of any kind of projects.

But at the same time, if you consider the scale, the scope of Vue, like we have more than two million users supported by, I think at max, we had like three people working full time on Vue related stuff.

Like now it's probably still around three people that's actually full time on Vue.

And then a bunch of part time contributors that we sponsor.

So it's sustainable.

But at the same time, we don't really see it growing, say, to the scale where we can have like a team of 10 people working on it full time, right?

Because I intentionally try to build the business around Vue to be as passive and carefree as possible as a lifestyle choice.

But also that means the conversion rate, because it's not a for-profit business, like we don't do aggressive marketing or we don't push features to sort of drive profit or revenue.

So in a lot of ways, the conversion rate compared to the user kind of view is extremely slow, extremely low, right?

And I'm not saying that's a bad thing.

For me, there's no sort of this or that in terms of open source sustainability or monetization.

I think it all comes down to the goal you're trying to achieve.

For me, Vue is a lifestyle business thing, and I think that's working very, very well for me, right?

I'm happy about that.

But on the other hand, when I think about where Vite is going and thinking about the potential that Vite has and thinking about how we can actually maximize that potential and make the thing, you know, we hope it can be.

And I don't see it happening with this sort of more passive model of like just hoping people donate, helping people sponsor, or hoping someone comes up with a business and decides to donate back to Vite, right?

That actually has a lot to do with, I think, partly with luck.

It takes time.

It also has a lot to do with what layer the project stands on.

For example, because Vue is a very user-facing framework, so most of the income that's generated by Vue is due to the exposure, due to the high exposure and documentation.

And because when people use frameworks, they would likely interact with the documentation very, very constantly.

BuildTools is quite different, right?

It usually sits one layer below the framework.

And also, when you set up BuildTools, once you get it working, you're happy with it.

You really have to actually look at the docs every day.

So when we go even lower, say like we're building parsers and toolchains like that,

I've seen how projects like Babel struggle with funding despite such wide, almost universal adoption across the ecosystem.

So I don't think that model is going to work for the things we want to build.

But at the same time, this is quite an ambitious goal.

So I can't imagine it being done with part-time efforts from just contributors who are like, oh, we want to work on this together.

I don't think that's going to happen, or at least it's not going to happen soon enough.

So I think the only realistic way for us to actually do it is to have enough resource, capital, to get people paid properly to work on a full-time and as a team, right?

So we have a common mission, a common goal, and it's much more serious than your, let's contribute to open source after work on weekends, right?

It's different.

So that also inevitably brings in a question of expectations from investments and returns.

And I think one of the other goals of starting the company is because I always felt like it's a bit sad that the JavaScript ecosystem is relying on a lot of critical infrastructure that's maintained by people that's either underpaid or just as labor of love, right?

In a way, the ideal situation is we hope, okay, like big companies using these open source projects, making a lot of money, they should donate back, they should sponsor.

And I think it's difficult because there is so much logistics that you have to go through to actually set up the proper organization like a foundations and align the incentives.

And there's a lot of lobbying, a lot of like just talking to people and getting people on the same page and to make things like that happen.

And smaller open source project authors really don't have the leverage or the time and the energy to make that kind of thing happen.

And it's uphill battle before you absolutely become kind of the critical infrastructure the entire ecosystem relies on, right?

So I think Voice Zero is also a different attempt where the end goal we hold is we have a sustainable business model that's mostly coming from bigger companies, enterprise, that's paying money that allows us to keep improving these open source parts and keep it free and open source for individual users, for smaller companies, startups, so that more people have, more JavaScript developers have free access to high quality tools.

At the same time, the tools should also be well sustained and maintained.

So is your plan for monetization, like charging bigger companies to use the tools and then like letting it be open source free for everybody else?

Not exactly.

So we want to draw a line where if the code runs on your machine, it should be open source and free, right?

We don't want to do things like, so one thing we definitely don't do is to ship something as open source and change the license later and hope people pay for it.