Latest / The MonkCast / Inside the Acquisition: VoidZero Joins Cloudflare with Evan You

Transcript

Inside the Acquisition: VoidZero Joins Cloudflare with Evan You · The MonkCast

• speaker-0: Hello, my name is Kate Holterhoff. I am an analyst at Red Monk and welcome to this Monk Cast. My guest today is Evan Yu. He's the founder and CEO at Void Zero and now on the open source team at Cloudflare. Evan, thanks so much for joining me. My pleasure. I invited Evan to join me ⁓ after chatting with him at VueConf, which was conveniently in Atlanta this year. and ⁓ I was so jazzed to have him come on and just kind of talk View with me, talk ⁓ frameworks, things like that. Little did I know that he was gonna have this tremendous news coming out. So I wanna begin by just saying huge congrats to to the entire Void Zero team ⁓ on the acquisition. You know, lots of interesting projects are coming out of Cloudflare. So Evan, ⁓ way to go. This is this is exciting. speaker-1: Thank you. Yeah. ⁓ yeah, everyone on the team's also excited. So yeah, I think we joined at a pretty good time. speaker-0: It's it's remarkable. Yeah, no, too cool. I've I've read all the blog posts that I could find on the subject, so I'm I'm hoping we can dig into some of the details here today. ⁓ but for folks who are maybe less familiar with the front end community, with you know what you do, could you ⁓ just introduce maybe your background and and what it is that Void Zero does? speaker-1: Sure. ⁓ so I've been working in open source since like twenty thirteen, fourteen. ⁓ so I was still at Google at that time and I started Vue.js as my side project. ⁓ so VJS is a front end JavaScript framework. ⁓ so I worked on that and in twenty sixteen I started doing open source full time as an independent developer. ⁓ so that's like purely based on sponsorships and some, you know, partnerships with people who are making content on top of UJS and you know, collaborating with people selling products to, you know, developers and they would sponsor the project or ⁓ have different kind of, you know, small partnerships and which made it actually sustainable for me to just work on it full time for ⁓ almost a decade actually. Right. So ⁓ in twenty twenty I created another project called Vit, which is a JavaScript build tool. ⁓ and it got quite popular. ⁓ so ⁓ in twenty twenty-three I started a company called Voice Zero, essentially trying to ⁓ leverage the momentum and ecosystem around Vit and to ⁓ expand that and build a full tool chain for JavaScript development. And yeah, the rest is what happened recently. ⁓ Voiceero was acquired by Cloudflare and now the whole team has joined. speaker-0: That is a clear and succinct history. I appreciate that. I I think it's valuable because ⁓ many folks may have heard of the acquisition and and and be less familiar with ⁓ the breadth of experience that Cloudflare is now bringing in. ⁓ and so I guess just worth noting, I invited you on here before you were an employee of Cloudflare. So you're ⁓ you're here on your own auspices. This is you you did this to yourself, Evan, is what I'm saying. This is Okay. ⁓ all right. So Exciting. I think many folks in the front end community when they hear about this sort of ⁓ an acquisition, they get a little nervous. And I feel like you addressed this very well in the blog post, but ⁓ could you help us to understand like what is it that ⁓ this is gonna mean for the view community, the V community? How are things gonna be changing from their perspective? speaker-1: Mm-hmm. So, first of all, for View, right? ⁓ I also ⁓ talked about this on X. ⁓ so Vue is not part of the acquisition. Actually, Vue has never been associated with Voice Zero in the first place. ⁓ this is also a kind of a common thing I had to explain over and over again when I started the company. ⁓ people are like, you know, what does Vue get out of VoiceZero? And I'm like, well, they are separate, right? Which is intentional. ⁓ Vue is an independent project. It's still my project, but ⁓ I intentionally have a very clear boundary between Vue and Voice0 of the company, right? So ⁓ for example, the IP of, you know, on the IP aspect, I actually signed the part of my IP of VEET into the company. ⁓ but Vue has always stayed out of this whole thing. ⁓ and similarly in the in the acquisition, Vue was just never part of it. Actually I have an explicit clause in my employment contract which says View is prior art. And it has nothing to do with my employment at Powerflare at all. Wow. So yeah, so that I've already been really intentional in keeping the sort of independence of view because ⁓ in a way it's it's a special project to me, right? And also my intention with Voice Zero in the very f in the very beginning is to say, Okay, this is going to be a company, this is going to be we're gonna raise VC money, right? We're potentially gonna sell it to other companies in the future, right? So I know this is potentially gonna happen down the road, so which is why I always kind of was really careful in not dragging view into it. ⁓ in a way I like having the ability to sort of operate view in its own capacity without having to worry about, you know, having other stakeholders trying to get a piece out of it. speaker-0: Yeah. Okay. What a unique situation too. Because like we've had Daniel Rowe on the podcast talking about when Nuxt was acquired by Vercell. ⁓ I've talked to to folks on the the React ⁓ foundation team. ⁓ Seth Webster's come on. So I I feel like there's always this sort of nuance with these acquisitions. ⁓ but yours is is so unique because you have so many important infrastructure and, you know, community type projects. that you're you're balancing here. So I can imagine that the ⁓ the lawyers were were having a hard time with that. ⁓ And yeah. And when we talked at VueConf, you gave a great talk. It was it was like a you know an hour-long sort of ⁓ discussion of of where does AI fit into this, like what is the future of VEET, all these things. and a lot of benchmarks in there, and of course all the different projects. ⁓ but one of my my takeaways too was that how much you had built that ⁓ was working with the Cloudflare ecosystem. So this feels like a very natural fit. ⁓ so they maybe I should have anticipated this. I am an analyst after all. ⁓ So I guess you mentioned thinking about it ⁓ between twenty twenty-four. How long have you been considering Cloudflare as like the the best home for this? speaker-1: specific for the acquisition, it's not too long ago. ⁓ I guess the ⁓ the initial ideas started when I was at Cloudflare Connect ⁓ in October 2025. so I think that also was around the time we announced our Series A s but you know, these like funding announcements is always a bit delayed. We actually closed our series A earlier in the year. ⁓ And I was at Cloudflare Connect because ⁓ I think ⁓ one of the things is Vit has always been this sort of entry point for web development, right? People start building apps with Vit. And then ⁓ but for a very long time, people also think about Vit as just this like front-end build tool. Like I they can use React or Vue or some other frameworks with it and they produce some static assets and that's it, right? ⁓ when you think about full stat development, how do you get into the back end? Usually it involves another framework, right? So there are frameworks, a lot of frameworks being built on top of Vit. There's like ⁓ Astral or ⁓ Nuxt or ⁓ Tan Stack Start. ⁓ but traditionally people kinda always I guess before these Vased frameworks got more mature and popular, people always kind of look to Next.js, right? And when you look at Next.js naturally. There's this for sell sort of story where NextJS helped for sell get off the ground and, you know, get all the users. ⁓ so from my perspective, like when we're working on at 4.0, ⁓ we've obviously tried really hard to see if there is a way to just monetize on top of the tooling itself. But as you can imagine, that's actually really hard. ⁓ so DogRail, we've always been thought, okay, like, you know, eventually we may have to go into. Just thinking about how we can leverage V and build something that's tied into sort of server compart compartments. Right. Because like monetizing on tooling or front end alone is extremely difficult. But the moment you have a server running somewhere, right, you are running compute for people. That makes it easier for people to pay you. So ⁓ I guess down the road, we always felt like if, you know, just like pure tooling based up monetization doesn't really work out, we always have that around. That option. And in fact, Void, which is the project we kind of, you know, launched right before the acquisition, is our exact attempt at that. So we've been thinking about potentially going into a cloud offering. ⁓ I guess like for a very long time. ⁓ one of the reasons we didn't do it is because we just had so much work to do before that. And also ⁓ we were kind of trying to see if, you know, just the ecosystem, how does it mature? ⁓ Obviously I've been doing a lot of research on my own and just thinking about if I were to build a full stack solution that's kind of serves as an extension of Vit, right, what it would look like and where should it run. ⁓ in a way, then it ties into the question of like where should it run? And usually people would say, okay, it needs to run everywhere. You need to be vendor agnostic. ⁓ which makes sense for a tool like Vit, right? But at the same time, I think The thing with vendor agnostic solutions is that you are always constrained by the lowest common denominator. ⁓ because the same thing needs to work everywhere. Which means like if a platform offers something pretty unique, ⁓ but you cannot replicate it on other vendors, then you can't can't support it, right? ⁓ which is a pity. So and unfortunately, no one has really explored that, right? So when I look at Cloudflare, I've always You know, then for Cloudflare specific, I've always been like a fan of the primitives they're offering. ⁓ you know, it's very effortlessly scaling globally. And they have they added over the years they've added D1, R2, you know, KD. a lot of the primitives you typically need for an application. But ⁓ if you've used Cloudflare, you probably know that the ⁓ the experience of stitching these things together and get your code to actually run on Cloudflare hasn't always been a s Super smooth experience, right? So I just saw the sort of, you know, it's it's a space I'm interested in. It's also I see some sort of opportunity where we can potentially leverage feeds power to make that experience smoother. And we've already had some collaboration with Cloudflare prior to the acquisition as well. because ⁓ because like I said, Cloudflare is a pretty unique runtime. It has a lot of its own quirks. And ⁓ when people try to do local development, they don't have the actual Cloudflare system running locally. Right? So it's very different from say if you're deploying to a pure Node.js hosting platform. You're running look Node.js locally, you're also running no Node.js on the server. So you expect your code to behave exactly the same, but that is not the case for Cloudflare for for a very long time, right? ⁓ like maybe A few years ago, if you were to deploy it to Cloudflare, ⁓ you'd actually be running your code locally in Node.js and then the deployed code runs in Cloudflare workers. And there are different runtimes. There are a lot of behavior differences. That's just not consistent. And you only find out after you deploy. That is not ideal at all. Right. So ⁓ so what we kind of worked with Cloudflare on was this thing called environment API in VET. ⁓ It's in a set of API that allows you to basically take the user's code. ⁓ even if the user is starting their local development process in Node.js, which is Vit runs in by default, Vit can actually take their code and then put it inside a separate a different runtime, which is, for example, Cloudflare's runtime. ⁓ it's called worker D, right? So we can put you take the user's code, transform it through Vit's pipeline, bundle it on the fly, and make it run in worker D. locally on the user's machines. Now the behavior will be consistent between the local development process and you know the remote, the deployed version that runs actually on Cloudflare. ⁓ so that kind of solves a big you know gap in the development experience for Cloudflare. And that's a also part of where the synergy came from as Cloudflare saw like, okay, V can actually help us solve this problem. And for me, I was just like looking at like, hey, we can solve a lot of problems Cloudflare have. We can also give Vit a natural sort of step up. Like for a VT user, they can now say, I want to build a full stack application. I can just do things like this and it just run on Cloudflare without having to go through all the extra trouble. ⁓ so I started ⁓ I guess like we we we didn't like explicitly talk about this until I ⁓ I came out with Void, right? So there has been a bit of interest on both sides when when we ⁓ talked at ⁓ Cloudflare Connecting October, right? But it wasn't it wasn't like, hey, let's just like start this whole like acquisition thing. It was more like there ⁓ could be more opportunities for collaboration here. And I think when Void came out, it just became super obvious that, you know, the synergy ⁓ is just Like on our side we have, you know, built this thing on Cloudflare that shows them, hey, like there are great things that can be done here and on Cloudflare side, they've always been thought thought thinking of VET as this ⁓ thing that A helped them with local DX a lot and B can potentially bring more users onto Cloudflare. speaker-0: Yeah. ⁓ I appreciate that you have ⁓ brought in that ⁓ the subject of like how Cloudflare is gonna be leveraging VET. Because when I ⁓ read that press release, I assumed it was gonna be more like, ⁓ no, we're just, you know, we're adding this to our what, our portfolio here and that this is gonna be more like benefiting you, that you'll you'll take advantage of all Cloudflare's resources. But no, it comes across very clearly what you're saying, that they're gonna be building on top of VET. ⁓ in these significant ways. ⁓ and it actually kind of reminded me a little bit of how anthropic has ⁓ w when they ⁓ acquired Bun, ⁓ just in the sense of like these are open source projects, but there's something to bringing that team in-house, having the skill set on hand and also just that ⁓ deep knowledge of like how to leverage these tools and to to take advantage of them to to their fullest. ⁓ so it I mean it speaks a lot to maybe Cloudflare's own strategies and and what they're looking at in the future. I mean, ⁓ needless to say, AI takes up a big part of their announcement as well. ⁓ so yeah, it ⁓ there was a lot of ⁓ takeaways there. I don't know, did did you wanna respond to any of that ⁓ before I move on? speaker-1: Yeah, I guess ⁓ ties back it I want to talk a bit about about like you know like ⁓ companies acquiring open source, right? ⁓ it's like there's always this concern about like will this thing stay neutral, will this thing thing stay free? ⁓ I think ⁓ I do want to emphasize Cloudflare has made very, very serious commitments here to ensure that, you know, like we obviously ⁓ the purpose of the acquisition is to you know, leverage VEET and try to get more people to use Cloudflare, right? That makes total sense. But we want to do it in a way that does not distort the incentives ⁓ of the project itself, right? The goal of the project is still to be the best tool possible. Right. And in order to get people onto Cloudflare, we do that by keep making V great and just making the specific part of VEET and Cloudflare integration smoother than before. But it should not We should not do it at the expense of making it worse for the other platforms. So that is super important for us because ⁓ in order to keep Vit great and keep people trusting Vit, we need to keep it, you know, usable and beneficial to everyone else, even if they're not using Cloudflare. speaker-0: Yeah. Okay. That makes sense. And ⁓ so I ⁓ but before we move on from the monetization issue, because you know, obviously that's that's really important here. ⁓ I'm interested, did you consider any other business models before you moved into thinking through acquisition? For instance, having a a sort of mixed licensing ⁓ mode or the void deployment platform. how serious were you with those initiatives ⁓ before deciding that acquisition was the way to go? speaker-1: it was obviously very serious. ⁓ we are a VC funded company after all, and we we know you know, we were under pressure to find a actual business model. ⁓ so V Plus was the original thing that we were trying to ⁓ see if the the mixed licensing model so for context we ⁓ we built this thing called V Plus, which is a essentially a combined unify tool that combines V VTest, roll down, OXC, all the things that we've worked on and more. Right. It contains something that's unique to V Plus itself. For example, we have the task render system with ⁓ automatic inferred caching based on file access. ⁓ we have ⁓ it bakes in Node.js version management and patch manager management. So it ⁓ it's almost a one-stop shop for your whole JavaScript TypeScript development workflows. ⁓ and we think that actually we we're still pretty, you know, confident that it's probably the best thing for your agent to use when it comes to to TypeScript development. and we thought it would be valuable enough so that we could isn't so w well the license model we tried is kind of interesting because ⁓ we made it free for for most individual users, right? And the license model we tried is companies above a certain revenue threshold would have to pay for it. ⁓ Right. So, ⁓ so we were testing the waters with what that threshold should be. And we got a very long list of companies interested in it. We actually got to, you know, conversations of people actually are like, hey, we want to actually just pay for this so we can use it. Like what is, you know, what what exactly how much do we pay you? ⁓ and we got into those conversations, but when we got into the actual details of like what they actually want, they started asking about support. And they started asking about like you know, ⁓ how many hours of support do we get each month? And if we run into issues, who do we talk to? And we realized, I guess, ⁓ the expectation with selling software like this is ⁓ because it's not it's not like a hosted service where as long as things keep running, people are happy. using tooling is, you know, inevitably they will have to they will run into all kinds of issues. ⁓ it's kinda like you get so we already get a lot of GitHub issues. We already get a lot of bug reports. And now ⁓ once they become paying customers, we kind of have to prioritize this. And ⁓ we have to have people just out Slack sitting all day answering questions pretty much. And we have to build a whole support team. ⁓ and we realize like the scalability of this isn't ideal. ⁓ because we don't want to turn into a support, you know, company like I mean, no disrespect to Red Hat, but like we don't want to have to like have a team of, you know, like fifty like so our core team is just like less than fewer than twenty people, but we don't want to have to build another like fifty people solution engineer team just to answer questions all day. ⁓ that is just not the business I sign up for. ⁓ so so we then we started thinking about void. Like I said, like, you know, ⁓ selling hosting is has always been The kind of thing like we know we can do if we really want to, right? ⁓ the reason we didn't get into too early is like we're like, let's explore what we can do with B plus. and quickly we realize, okay, like it it's not the it's not the thing we really want to do, right? Because embedding a company, ⁓ it's always kind of tough balancing like, you know, how do you actually make money and what do you really try what are you trying really trying to achieve? ⁓ and I think In a way, having having good investors ⁓ is nice in that way because our investors really didn't like pressure us so much in like they were not short sighted enough to force us to just like you ⁓ you need to actually start having revenue like by year two or something. Right. So ⁓ so we got the opportunity to try things and then we got the opportunity to explore what we can do with Void. And and for Void specifically, I guess it definitely helped the conversation the the acquisition conversation because it just made things so obvious. ⁓ but we realized, ⁓ so for Void specifically, it's it's a whole the reason we didn't get into hosting too early is because hosting is a whole domain of its own, right? Like once you get into the hosting business, there's this whole new category of things like how do you design billing, how do you, you know ⁓ some companies may want SLAs, you know you get to get through like all the security, data retention, a lot of problems that we did not have to deal with before and now we have to deal with it. Right. So as we are the as we are sort of still in the private beta phase of Void, we started to actually working on these problems and we're like, well, this probably is gonna take quite a bit longer than we hoped before we can actually say this is production ready and start making real revenue from it. ⁓ But then again, in some way, ⁓ it's great that we can build this thing and p eventually make money. But also like, you know, we feel like a lot of our passion is in the tooling itself. ⁓ and now we have this whole pl ne hosting platform thing. And we need to hire more people to work on hosting. I have to split my attention between tooling and hosting. it's, you know, deep down we're like, we wish we could just keep focused on tooling, right? And so the acquisition actually just gave us that opportunity because look, we're building on top of Cloudflare. Cloudflare is already offering hosting. It's like compute, you know, all the it's a cloud platform, right? And the cloud platform wants to support us and we can keep working on tooling. And our tooling will benefit the the cloud platform. It's it's basically, you know, allows us to kind of skip that phase and directly jump into what we actually want to do. speaker-0: Okay, well let's stay on that subject of ⁓ like deployment vendors, like these cloud platforms. ⁓ so Cloudflare obviously fits in that category, but some other ones include, you know, Vercell, Netlify, there's many others. and it is no secret that Cloudflare and Vercel have had a little beef. ⁓ I as I'm thinking back on Connect, I remember Sunil Pai showed me ⁓ a blog post where there was some some static going on there. ⁓ so no need to be quoting ⁓ Tweets here, but ⁓ but we're we're we're all familiar. ⁓ I know I know you're you're chronically online, Evan. ⁓ so talk to me about how the community should feel about that, especially folks who maybe use versel, like who should folks who ⁓ use projects like Nuxt and Svelte should they be concerned at all about support for VET ⁓ or any of the Void Zero products? speaker-1: Mm-hmm. Yeah. I think honestly, I think the beef is it's just like it's a social media thing. ⁓ I'm pretty sure like they are to some people, it's on a personal level, but I think at the business level, obviously there are they are competing businesses, right? They are trying to compete for the same sort of positioning as like the the cloud for agents, the cloud for the future of web deployments. ⁓ which I think there is so I think there are basically three parts. A, there's this like personal beef stuff, which I don't think matters in the grand scheme of things. ⁓ and then there's the actual business competition, which I think is it is what it is, right? ⁓ companies gotta gotta do business. And then there's the people who are actually working all these things, right? ⁓ which is very different from the beef people are perceiving. ⁓ actually You know, the the people who joined for sale as part of the NUPS acquisition. In fact, one of the ViewCore team members, Eduardo, who's probably one of the oldest members of View team, I've been personally sponsoring him for over all these years. And he just recently joined for sell and is actually really happy about it. And he's like, You can stop sponsoring me now because I I get paid pretty well by Vercel. ⁓ and I can still, you know, sp spend some spare time working on Vue, which is great. ⁓ So I'm still good friends with the people on the Nux team with Eduardo. ⁓ there's really nothing that changes the dynamics of which is also a perk of me keeping Vue independent is we can still keep collaborating on these things on the side. ⁓ it doesn't really get affected by how, you know, some high level people in these companies kind of hate each other. ⁓ doesn't really affect us, right? ⁓ Yeah, and and I think it's it's also like even even at the speaker-0: Well put. speaker-1: open source parts, I think generally people working even on the in these two companies, even they're working on competing products, they have a lot of respect for each other, right? Cause, you know, it's it's it's it's just a matter of fact that for sell is shipping a lot of great open source. And Cloudflare is shipping a lot of great infra products. And there are things we can learn from each other. Right. ⁓ and we have people who previously worked at Forcel now work at Cloudflare and vice versa. So ⁓ there's a lot of cross pollination. And I think for the users, I generally think it's actually better that there are companies, ca ⁓ competent companies competing in this space. It's kinda like, you know, similar to how I think the the AI space would be worse off if Anthropic and OpenIR were not competing, right? Because it's the competition that forces them to kind of just keeping up the pace and trying to one up each other. I think it's similarly, you know, in the in the web development space, in the in the agent hosting space, you know, you gotta have competition to have people just keep innovating and coming out with great ideas and better implementations. And users end up benefiting because, you know, ⁓ because like having choices also forces these companies to avoid doing, you know, blatant vendor locking. Because if you do that, people see that. And people are not stupid. They will be like, ⁓ if you want to lock me in, I'm just gonna not gonna be using you for the fur in the first place. Right. So I think overall, you know, this kind of competition just benefits end users. speaker-0: Yeah, a and as part of that, ⁓ I know that the press release talks about this one million dollar independent fund as part of the pledge to neutrality. Do you have any insight into who's gonna be seeing any of that money? 'Cause divided by all the maintainers isn't gonna be much. ⁓ but a nice gesture. speaker-1: Yeah, we we actually already have part of the ⁓ part of the deal considerations flowing to some of the long term contributors because they we actually granted some of the contributors some options in Voice Zero. ⁓ so they they're already, you know, there are already some money flowing there and this one million actually is like extra f on top of it. And this is gonna ⁓ be ⁓ openly administrated by the VitCore team. ⁓ so V Core team consists of me and Safi who is a Voiceero employee, but there are also four other people who are not part of Voiceero or Cloudflare. Right. So it's going to be just this like very ⁓ kind of open ledger thing. If we were to disperse the money, it's going to be just like public records. Who gets what, you know. speaker-0: Okay. Is it an ongoing fund? Is there gonna be like a million dollars every year? It's just like they're this is the pay? speaker-1: No, it's a one time. ⁓ we probably it'll probably take some work like for us to like, you know, even make use of this properly. ⁓ so yeah. So matias, who is probably the one of the he is actually the first person I got onto the VT team. ⁓ and he's been with us through all this time. So he's the c our community per community person. He is just like the Helped us get things off the ground, talk to all the people, making sure they're aligned. ⁓ he knows everyone and he is also really well respected. So we're gonna, you know, I trust him in just making good use of this. ⁓ obviously I'm going to be sort of involved in the process to say this looks good, but ⁓ I kind of want to sort of I don't want to be the person to say, you get this much, you get that much, right? This has to be sort of a team based decision. speaker-0: Okay. Okay. So let's take a step back maybe and talk about the lessons from this experience because ⁓ Astro joined Cloudflare ⁓ you know, what is it, earlier this year? Now V. ⁓ so what sort of advice would you give to folks in that are maintainers or that are have built these projects ⁓ that are open source and are maybe struggling with the monetization issue that you've struggled with? ⁓ you know, what sort of advice would you give to them? And and frankly, just like from a the state of software today, what would you say we've learned? Like what is it viable to have standalone open source infrastructure in twenty twenty six, ⁓ without being absorbed into these like infra giants? you know, is that really the only end game possible? Like a and maybe have things even shifted? Is that how it's always been? Like this was always You know, th this has always been a problem. ⁓ I don't know. So yeah, lessons that you would share with folks who are in similar situations and like, where are we today? speaker-1: Mm-hmm. That's a sharp question. and so I think for this question, there are two different ways to think about it, right? Okay. So I kind of have experienced two both sides of it. Right. I still keep view independent, and view is sustainable. ⁓ even without the acquisition money that I I personally so now I after the acquisition, I'm planning to personally kind of, you know. put a b bit more to support other people working on view. But even without that, Vue has always been sustainable. Like we have Open Collective, we have ⁓ GitHub sponsors, we have ⁓ historically we had a bigger Patreon ⁓ sort of income, but like it's much smaller now. But there's still something going on ⁓ that we allow us to support maybe, you know, two full time people actually just working on Vue and nothing else. ⁓ but But Vue has historically even like so Vue given Vue's usage scale, right? It's downloaded like, I don't know, like close to ten million times a week now. ⁓ so it's like the second most popular JavaScript framework in the world. But the amount of sponsorship we get, it's sustainable, but it's definitely not not, you know, not substantial by any means compared to the scale of impact it has created. Right. So, but even that view has been an outlier for independent open source. I've seen many projects like Babbel, ⁓ which has been critical in the JavaScript ec ecosystem. It has historically always struggled with funding. ⁓ and then we have ⁓ So if you are running a an an an open source project purely out of ⁓ out of your passion, ⁓ nowadays I think it is actually really difficult, right? ⁓ before I started Voice Zero, people have always come to me to say, Hey, how can I make my open source project as sustainable as Vue? ⁓ I always feel like, you know, A, the thing I do with Vue is Very hard to replicate because every open source project is different. It's kind of like every startup is different. You gotta find your own way of monetization, your own way of you know, your own business model. And open source is similar. ⁓ View is unique in the sense that it has w a big reach. It is a JavaScript framework. People interact with the documentation a lot. It has great exposure to end developers, right? But if you're a a more tooling infrastructural thing like for example Vit, right? Vit actually quickly has more download numbers than Vue does, but like Views, ⁓ VIT sponsorship numbers has always been lower than Views because it just you know, when people use V Vit, they treat it as a tool. They install it, they get it configured, they get it working and they forget about it. Right. They they love it when when it works, but once it starts working, ⁓ They don't think about it as much. Unlike a framework, when they write code every day, they would look at the docs and they have deeper engagement and then the sponsorships become more meaningful. ⁓ for so so companies are more likely to sponsor frameworks compared to tools. So there are a lot of these intricacies between different kinds of props open source projects. So it's very hard to give people very generic advice on how to monetize your open source. Right. ⁓ so on the other hand, we also see a lot of you know, open source with different like motives, right? There are open source projects where you start just because you want to do it. Like I started View and Deeds just because they want to do these things. I didn't really think about commercialization or monetization when I started these projects. ⁓ so it's more like passion driven. And then I try to figure things out along the way. Right. ⁓ the way View sponsorship model works, like It just organically evolved. I didn't really try to force it into that way or try to like design it from that way in the beginning. ⁓ but then we also see there are a lot of companies or startups nowadays where they're doing open source, right? But open source is only part of the whole ⁓ commercialization strategy. It's a means to an end. ⁓ the whole idea is to build a successful business and open source is just a strategy that they happen to pick. to to help them achieve that goal. Right. So I think the incentives is very different. ⁓ so I would say the the first category, the passion driven ones, it's getting harder and harder, right? especially with AI. Because the thing is the the cost of A, like you no longer get the same level of the the the joy of craft ⁓ when you work on these good ideas. ⁓ so when I worked on View, I I would keep, you know, polishing these little details over weeks, months, and I I was happy just working on it because, you know, it gave me this sense of like sort of I'm I'm doing something that's really great, I'm proud of. But I think AI nowadays sort of A it kind of takes away some of that joy because it's so easy to just come up with an idea and like type a prompt and you get something working in like twenty minutes. Right. ⁓ Yeah. And the idea is also much easier to copy because like you can open source something and the next day someone would fork it with AI and add a bunch of features and say, I made a better clone of your stuff. ⁓ so yeah, it it's it's tough. I think I don't really know what to make of it at this ⁓ at this point, because like if if you're just starting out a new passion driven open source project, I think like it's definitely tougher than what we got back then. ⁓ and monetization would even become more of a challenge. And and even with commercial open source, there's been this kind of like, you know, ⁓ there are companies who are just closing off issues because people are sending spam PRs ⁓ with AI. And there are people just go went straight to closed source because they worried about people just, you know, forking their thing with AI and just like be a c become a competitor overnight. ⁓ so the dynamics is changing. and there are definitely a lot of new problems we need to think of when it when it comes to the interaction between AI and open source. And ⁓ honestly, I don't have clear ideas or answers to these yet. ⁓ I'm concerned, ⁓ but at the same time, I think ⁓ what I do want to encourage people to do is to ⁓ still keep you know, keep the the open source sort of etiquette or just like be be good actors in the space, right? Still sort of respect what original ideas that people come up with. Don't just like take people's stuff and fork it just because you can with AI. Right. ⁓ try to collaborate. Try to still like ⁓ be ⁓ pull your efforts together to make great things together rather than ⁓ like everyone can just do their own version because AI is gonna write all the code. I don't I don't I that's not the future I want to see. speaker-0: Yeah. Agreed. ⁓ I mean on that note, ⁓ I gotta bring up, you know, Cloudflare is actually ⁓ I wanna say notorious, but they they have a history now of of what, creating vibe coded versions of front end ⁓ things. Like so they they just did most recently a a a ⁓ a WordPress clone as well as a Next clone. So I'm I w was there a part of you that was worried they were gonna do a VT clone? speaker-1: Really? ⁓ I think the next one is is controversial, but there's been a long history of people wanting to deploy Next.js on Cloudflare and running into all sorts of issues. ⁓ and in a way, I think the V Next thing is really just came out of the frustration in trying to support all the edge cases have like trying people trying to run Next JS on Cloudflare. And they were ⁓ because the the fork on V Nex is actually next running on Vit. ⁓ and it runs much better on Cloudflare because it's based on Vit. ⁓ so that's the that's the actual reason. It's not like forking just because they hate each other, to be honest. ⁓ yeah. So there are there are technical reasons why they why they try to do it. and VNS is in fact also used in a pretty prominent project. ⁓ that's actually open open AI sites. as far as I know, is deployed on Cloudflare and running on V next. ⁓ speaker-0: I didn't know that. That is interesting. It seemed like a hobby project, kind of like a look what like a cool look what we did. ⁓ I didn't realize anyone had actually deployed it. Because ⁓ I think it was TJ Vantol, ⁓ who is on his own podcast, the front end fire one, was actually talking about trying to use it as a drop in replacement and because there's no like documentation or there wasn't, I d I don't know what what it looks like today, he wasn't able to get it working. Now, I don't know how much time he spent on it, maybe, you know, I'm sure there's extenuating circumstances here, but ⁓ I this is the first time I've heard of it actually being used. So this is this a good proof point that this is interesting. speaker-1: There are there are a lot of different use cases for these things, right? Because I honestly wouldn't recommend people trying to ⁓ say take an existing production level Next.js app and try to migrate it over. There's really little point in doing that. ⁓ I think the idea is you can quickly spin up new projects that's still using Next.js style code, right? But make sure that it can actually run smoothly on Cloudflare without problems. that I think that is the main incentive. ⁓ Steve, if you see this, correct me if I'm wrong. ⁓ Steve is the the one who worked on these things. and ⁓ Yeah, and and I think the ⁓ in a lot of ways ⁓ dash isn't even a fork in a sense. ⁓ I personally do think the whole ⁓ there are a lot of like public communication around these around V Nex ⁓ dash can be improved. Like ⁓ I've actually talked to Dane about this. ⁓ I think I think like we acknowledge there are definitely like, you know, certain ways we can communicate these things better. ⁓ like for example, for Amdash, it's not even a fork per se. It's like it's written in a completely different language. ⁓ it does the same functionality, but it's not like we take it's not like they took the PHP code base and tell the AI to say, Hey, like rewrite this in TypeScript. ⁓ it's a pretty different code base. ⁓ It just does the same thing that WordPress does. ⁓ and in a way, I don't know if like calling it the spiritual successor of WordPress really helped. Because like, you know, obviously a lot of people took issue with that. so yeah. And ⁓ honestly, I'm not too involved with that project. So I probably should reserve my comments here. ⁓ so I only know enough about the technical implementation of it to know that it's not just a slop fork. Yeah. speaker-0: Yeah. Okay. Well that's fair enough. I I won't force you to ⁓ speculate on on what's going on there. But ⁓ it obviously got a lot of press. And I think it just also signals something about what Cloudflare ⁓ you know, th their strategic approach to front-end top-of-the-stack technologies. I mean, it's just it's been interesting to to follow that because I I I think it kind of is is a little surprising ⁓ when we think about what Cloudflare was known for in the past need to be ⁓ CDNs, things like that. More infrastructure level. I mean, I actually, as a former front end engineer, I love it. I'm like, well look, look how important we are. This is it. Everybody knows. We're all paying attention to the front end now. This is the this is where the cool stuff is happening. ⁓ but of course Evan, you've already you've always known that, so you know, I don't have to tell you. Okay. So I want to hear a little bit about ⁓ your thoughts on the open source situation because That is was one of the things that we discussed actually at VueConf. so talk to me about your overarching thoughts on the state of foundations today, because ⁓ Vue is famously independent. ⁓ what I ⁓ I've heard it characterized as a benevolent dictatorship, as many ⁓ great open source projects are, right? ⁓ have you considered Putting View into a foundation, I mean, now seems like kind of a pivotal point. You said it was weren't written into your contract that it's independent. Many folks have reservations about foundations, understandably. I guess I'm just interested in where do you sit on the foundation question? speaker-1: Yeah. ⁓ hist yes, we've been asked whether we want to put view into a foundation. ⁓ I guess I just really didn't see the benefit back then. or still don't really quite see the the full benefit of it. ⁓ part of it is because ⁓ there are two types of situations where where I see projects going into foundations. A is the project is so big. So critical, right? People put it in a foundation with many big companies backing it, and they're like, This is too important to to be left alone. So we're gonna just like support it all together, which is like Linux, ⁓ or React. ⁓ so, but like I guess like for View for a very long time, it's just like in this sort of like limbo where it's kind of big enough where it's like people kind of think, ⁓ it deserves a good sort of sustainably model or like. People we need to take care of it, but it's also not big enough for multiple big companies to say, hey, we need to put money into this foundation to keep you going. There just isn't such incentives. So and if we want to get enough companies to be interested in this, that's gonna be a lot of work on itself. And but ⁓ and for for me personally, it has been sustainable already, right? So ⁓ we just didn't feel the urge to go out of our way to like build up the foundation, then try to like pitch all these companies to pull money into it. ⁓ so it it just didn't really make sense for us. and my personal take on foundations, ⁓ I guess like I don't want to be ⁓ I guess historically I just don't really get how Like what actually the foundation would help for a project like Vue specifically. I can only speak from my own experience, right? ⁓ for some some other projects, maybe they are not they're not as sustainable as Vue on themselves. It definitely helps for them to just look for a home where they can be like, hey, take care of this. ⁓ but for Vue, it's like when we when we were asked, Do you want to join a foundation? I'm like, what do we get out of it? And they're like, IP protection will. Help with this and that. But a lot of that for us is just sort of, I guess, not critical. and ⁓ yeah, I just through those conversations and just never really found convincing reasons for us to say we should put you in a foundation. ⁓ and I think even after this, I also thought about, you know, setting up a foundation myself, ⁓ So that it could be ⁓ I I actually thought about this, right? I looked into how to do it, but like I obviously getting certified as five ⁓ one C three is is a very complicated process and I just never had the time or energy to follow it through. so what I'm doing now is kind of like we have we're probably gonna have an entity that is still dedicated to supporting View, but whether it's going to be in the form of foundation or just a you know normal business, ⁓ like to be honest, I just don't really don't really think it's gonna make a fundamental difference for View specifically at this point, as long as w we can make it sustainable. maybe in the d a few years down the road when I really want to say I'm I'm going to be retiring. I don't you know, I need someone else to take care of it. Maybe that's when the time I'll think about putting it into a foundation. But for now I just feel like, you know, I don't I don't think it adds real value to to view specifically. ⁓ I can't really speak for other projects. speaker-0: Okay. and then I just I I gotta ask about some ⁓ the benchmarks and roll down. And I have done a little bit of research into some of the bundlers and I'm curious about how you're thinking through the single page applications and how they relate to ⁓ just I guess this ⁓ arms race right now, ⁓ in terms of like roll down RSPAC. ⁓ TurboPack all of these different bundlers. And and what is your so okay, so I did ⁓ a number of interviews as part of my research on this. I didn't get a chance to interview you, so this is my opportunity. I got I gotta do this. So ⁓ talked with ⁓ Tippius Coppers, Creative Webpack and now TurboPack. ⁓ talked with ⁓ Zach Jackson, who's an engineer ⁓ at ByteDance. He works on the RSPAC team. And s I you know I got some spicy takes during these interviews. ⁓ but both of them Pointed me towards artifact size as being a big component of the reason that we have this arms race. Because at the end of the day, it's hard for engineers to even keep up, right? It's 10 times faster, it's 50 times faster. You know, I it's great. But I I do think that they're changing all the time. Developers get this sort of benchmark fatigue. ⁓ AI has only made it worse. And so I'm I'm interested to hear your sense of. this because I I I mean I I'll say like Zach Jackson had the maybe the spiciest taste. He says that like he it's ⁓ but the Bundler war is really about artifact size and that's the dirty secret. I love I love that term. Dirty secret. So do you agree with that that it's really just about the size or have we moved past us? Is the spa wars, you know, is that overblown? It's not really about JavaScript size being pulled down onto devices like are we where where do you sit on all that? speaker-1: Yeah, I so I agree. Like artifact quality is actually important. And ⁓ every bundler is more or less trying to balance between raw performance versus 'cause like there are two different metrics, right? One is how fast you can build your app, the other is how fast your end user loads your app. So for engineers working on a project, ⁓ bundling performance helps the developers because you can debug you you can build and debug your app faster, you can run your CI faster, you can run your tests faster, right? There are real benefits there. But for your end users, out of fact size is what determines like how fast your app can load, how well you can split your bundles so they get more efficient page loads. J you know, they're able to to load just a fraction of the code to be able to get the page load faster. So both are important, ⁓ but they're not mutually exclusive, right? So I think ⁓ historically Webpack has been this really, really powerful, extremely powerful thing. And it has a it gives you all these, you know, knobs and levers so that you can fine tweak your artifact output so that ⁓ so that you get the best possible like end user performance at the expense of being the architecture being a bit more complicated and therefore the performance would also suffer because, you know, all the additional complexity it has it has to handle. So when we started with so it could also I or would it also involve some other, you know, notable solutions like ES Build, which is ⁓ made by Evan Mollis, who's the CTO of Figma. ES Build is probably the first bundler that really kind of started this arms race when it, you know, ⁓ its benchmark basically showed like ES Build is a hundred times faster than Webpack plus Turser, which is the standard combination back then, right? So that was when like, you know, when that came out, people realized, okay, like we can actually have fast bundlers, right? But it is true that the artifact quality of ES build is not as great as, say, Webpack plus Thursday, right? historically ES build has larger bundles. The minification quality is worse, and it doesn't really have any sort of code splitting control. It only has one automatic code splitting mode and that's it. So you can't really like do fine tweaking. ⁓ to your needs. So if you use ESBO to bundle a large user-facing application, your user will actually have worse performance. Like they will load your app slower. Right. So that's the trade-off. Right. So when we started with with Vit, we initially st used roll up, right? And then we started working on Rolldown, which is our own Rust implementation that is now powering beat eight and above. And for roll down it really kind of takes time for the thing to mature because you gotta first get things working. Then you get into these deep optimizations. Right. So ⁓ the nice thing about Rhodon is like when we got the first basic functionality working, we know okay, like it's like three times faster than R S pack. And we're both written in Rust. Right. So that's kind of like where, you know, we're we're still more than twice as fast than the RSPAC nowadays. and over time we've been adding. So So the interesting thing is in the beginning, Rhodon is indeed producing noticeably bigger bundles. And it doesn't have as a powerful sort of control over code splitting as RSPAC does. It is true, right? So that's why we have been consistently trying to improve on that front. ⁓ but the nice thing is we've been able to add all of these features. We've had l so we've implemented better minification, we've implemented better tree shaking, we've implemented better code splitting over time. without degrading the performance. So that is the important thing, right? So ⁓ so overall we've been catching up in terms of artifact quality. And in fact, I think we're really, really close to RSPAC nowadays. ⁓ so the capability is pretty much equivalent. At the same time, RSPAC has been making great improvements in terms of performance, right? So they've always been this like more feature rich because they they are effectively a one-to-one port of Webpack. Which has all the things that allows you to fine tweak all things. Right. So initially they started a bit slower, but they've been tweaking the performance. So they're getting a bit faster over time. So we are basically starting with this like much faster but not as feature rich kind of starting state. And we are trying to stay as fast, but we're adding more features. And they're coming out from this like really feature rich but slower kind of place, but they're optimizing the performance to try to catch up. So I think, you know, at this stage they are still still slightly better in terms of like overall artifact quality. I'll give them that. ⁓ but it's really, really close now. And at the same time, they've been getting faster over time, but we're still you know, comfortably faster. We're like still more than twice as fast than our S Pac. So I think this is again a case of, you know, healthy competition where ⁓ in fact like four of our current team members came from They they're they worked on Asp R S Pack at some point. ⁓ so you know, we we have like people who were previously worked at Bedance, now currently working we're at Voiceero, now actually working at Cloudflare on Rhoda. So it's a lot of like people that we know each other and we kind of, you know, have a lot of mutual respect as well. speaker-0: Yeah. Okay. That's exciting. ⁓ a and now you're you're able to leverage all of the engineering talent at Cloudflare to to keep working on this problem. ⁓ I mean, yeah, Zach really ⁓ pointed to the the fact that he he also mentioned Tursor and that a lot of that code doesn't run. So it sounds like there is a lot of opportunity to to try to optimize and make sure that these things are, I don't know, as stripped down as possible. So and, you know, using I mean everything's on Rust now is like the big ⁓ I think that was like step run. Everything's on Rust ⁓ or go. and and after that it's like just these these tweaks that you're mentioning. ⁓ do you find that developers are overwhelmed by all the these benchmarks and like ⁓ I I feel that way, but maybe I'm projecting. Like do do speaker-1: We are I think what we the the reason we're we did all this work at Voice Zero is to eventually try to ⁓ you know converge, ⁓ give people a sort of like this is, you know, the default starting point, so you stop worrying about all this stuff. I think it's still good to have choices. I think RSPAC is particularly useful for people who are coming from a legacy webpack webpack application. And they're like, we just use all these advanced Webpack features and we can't just like easily migrate to Vit, right? So R Spec is perfect for that use case. ⁓ obviously we believe for Greenfield projects we provide a ⁓ overall a better set of trade offs, but ⁓ it's good that, you know, people using Webpack still have options to modernize their code base and get better performance. speaker-0: Okay. All right. Fair enough. ⁓ yeah, I will say when I was ⁓ doing research on this, ⁓ I could find the most data from Vit, the your team, and from Farm. And then there were a lot of like little ⁓ like just individual developers who had who had put each through their paces, kind of created their own benchmarks. So ⁓ you know, for as many numbers as there are trying to like track ⁓ down, I I found to be a bit of a challenge. So just just curious on what what you're seeing. ⁓ speaker-1: Yeah. I think nowadays these benchmarks are more or less for tooling nerds. ⁓ 'cause for end users, most of them, especially for nowadays if you're just like vibe coding, like yeah all these things are fast enough. speaker-0: Okay. Yeah, I I know. okay. I am gonna wrap us up here. I know we didn't even broach AI nearly as as deeply as we could have, but ⁓ we'll just have to have you back on, Evan. ⁓ okay, so before we go, where do you direct folks ⁓ to follow your musings? ⁓ to what's your social media channels? You know, how can everybody keep up with what's new and exciting ⁓ at VoidZero Cloudflare? speaker-1: Sure. ⁓ so I'm on X slash Twitter. I'm just at Ad and you and ⁓ that's my main social channel, really. ⁓ I have a ⁓ I have a Chinese alt on X as well. That's but it's completely personal. It has nothing to do with technical stuff. But if you just want to follow for the kicks of it, you can do that. Yeah. speaker-0: We love kicks. All right. Well, I have really enjoyed speaking with you today, Evan. Again, my name is Kate Holterhoff. I'm a senior analyst at Red Monk. If you enjoyed this conversation, please like, subscribe, and review the monk cast on your podcast platform of choice. If you're watching us on Red Monk's YouTube channel, please like, subscribe, and engage with us in the comments.