Alexander Lichter - VIDEO EDIT
===

Paige: . [00:00:00] Hi, and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. Log. Rocket provides AI first session, replay, and analytics, which surface the UX and technical issues impacting user experiences. Try it for free and start understanding where your users are struggling@logrocket.com. Hey everybody. I am your host today, Paige Ing House, and I am joined by my co-host, Noel Mincha. And today we have Alexander Lichter Dere at Void Zero. Here to talk about roll down How beat bundles at the speed of rust. Welcome to the show, Alexander.

Alex: You know, thanks for having me. Yeah. Happy to be on Pod Rocket and I'm curious, uh, what we'll talk about all, there's so much to cover.

Paige: I mean, void Zero has really been making a lot of news lately with the, just the creation of the company and your kind of focus on making the bundling and building ecosystem better and more unified. So this is really gonna be an exciting one.

Alex: Absolutely. It's, it's so funny [00:01:00] because like a year ago I was sitting like exactly in the opposite where you are right now of like interviewing avenue during, like Fest Japan during conference when he just announced Void Zero. And, well, how do tales have to earned to now? Uh, I, I joined the company as a devil and, uh, yeah, I'm, I'm really excited to talk more about it.

Paige: ~Absolutely. So, uh,~ if we're gonna talk about what you talked about at at some of com, some of the conferences, it's how VET is kind of transforming, uh, bundling and how you're making it better with rewriting everything and rest, which is what everybody's doing in the JavaScript ecosystem these days. So. Let's, let's talk about how yet another bundler is kind of a common critique. It seems like, like I said, everybody is rewriting their tools. There's lots of different bundlers to choose from. So how does Rolldown really set itself apart from rollup or ES build or any of the other bundlers that are kind of coming along in the ecosystem right now?

Alex: Yeah, I think that's a good one. So first of all, the typical [00:02:00] like rewrite it in. It's almost a mean nowadays, and we wouldn't do it if it wouldn't be necessary from our point of view, like, um, rolldown is a bit of a, is a bit of a special bundler because. Even though the name sounds like, oh, it's just rollup ified and it's common that people think that and say that it's not the entire truth. The fact is that we took inspiration and also, for example, Ronan's, API, but from all the different predecessors, so to say. So we thought, okay, yeah, rollup, it's, it's great. The plugin ecosystem is amazing. The API is very friendly and it's what ve uses and extends that a little bit. Uh, and it's, it's really good to use.

So of course we want to have compatibility. Es built has certain behavior and functionalities like, uh, injecting, defining variables, et cetera, that we also want to have there. And also certain things of correctness that Rollup might not cover in that way. And even inspiration from web hack was drawn because, yeah, all the way, one of the good old bundlers, um, web hack had really amazing [00:03:00] features in terms of chunking optimization.

So where you can decide. Where parts of your JavaScript should live, which files should be grouped together and generated. So we also want to offer that, and that's one of the reasons why we said, okay, we can't just say let's contribute to one of the existing bundles, because some of the things are simply out of scope for all of them.

And in addition, we also wanna have features like Build and Hot Module Reload, which V is covering right now, but we want to have it built into the Bundler and more and more support for other things such as Module Federation. So we thought, okay, let's take all the good things that are out there. Bets on the actual ecosystem APIs.

So we want to reduce the churn for the users. Ideally, people can just switch by switching a package in the future. And you can even do it right now as a preview. Uh, and that's the, the whole idea. But in the end, of course, rust helps with speed, but it's more than just rust, rewr.

Noel: ~Do you think,~ do you think that to some extent, uh, like roll downs, a little bit of a victim of its own success and that like API interoperability? 'cause I feel like everyone makes this ~complaint and then I'm always like. Or, you know, the, it's,~ you had get another bundler complaint, but then I'm always like, are you really [00:04:00] even doing that much config anymore?

Like, there was a time when I feel like everyone had to know all of this, like all the, all this config and everyone was upset and like, my team can't keep track of all these bundlers, but I feel like as time goes on I'm like, I'm using V and like, I don't really think about my bundler that much. Have you guys found that that is, ~is is kind of, you know, like a, a,~ a component of this discourse of ~the, the like, you know, is, is this just,~ is this just roll up with a.

~Different,~ different, ~uh,~ underlying language.

Alex: I think that's definitely part of it, but I would say that. Best compliment. Like you could get say like, Hey, I don't know what's going on the hood. I just use it and it works. And that's exactly what we want to get to the point with roll down vi uh, as well. So the people just use it, it all works. It's fine.

The same amazing developer experience, but even faster. And then also while, let's say, eliminating parts of the weaknesses of VI right now. Because like weed is amazing. We, we switched to it because it has an unbundled dev server. Um, but as soon as we got into the enterprise, which of course always takes a little bit to transition over there, uh, then it starts with like, okay, we don't have like just a couple components.

We have like tens of thousands of files. And then the unbundled [00:05:00] strategy, well, it doesn't fully work in that scale. Like it's still fine, but it takes a long time to refresh the page in dev mode or to start the dev server. So also Rolldown should like work and eliminate that problem by offering. A full bundle mode again.

So basically what Web Hack did in the past, there we go also once again, but also thanks to Rust of course, way Faster. And giving the best of both worlds. For a small, medium sized project, it'll be the same speed. And for like enterprise projects right now, it'll be faster than the current setup, but it's definitely a thing where people more think about like V as the BUILD tool and then some people don't even know, oh, V uses ees build under the hood for daf. And like for other things like ification and roll up actually for the production build, because we don't dig deep into all these layers. But that's also why I'm here and try to explain these things and why things are different. And once again, thanks for having me on to, uh, well shed some light on that for the, the listeners.

Paige: I mean, the whole idea of vet is such a breath of fresh air after coming from working in Webpac for years and years because I. I've even taken [00:06:00] like online courses on how to do webpac configs 'cause it was so complicated and just difficult. So just being able to put V in and have it do everything else as a developer is like the best experience.

Alex: That's what we're aiming for. Yeah. I, I can't cut anything with that as saying that's, that's how it should be. Right. Only worrying about shipping features actually, and fixing box here and there.

Paige: ~Absolutely. So you,~ you talked a little bit about the kind of inspiration and pieces that you're taking from all of these different bundlers that have come before Rolldown. So it sounds like there's kind of, uh, an emphasis on unifying pieces of the tool chain, the bundler, the parser, the linter and so on. Are there any risks of having too much consolidation in the ecosystem or under one team, do you think?

Alex: I think the risk is more during the development to make sure that like the, the whole community, the whole ecosystem at once is, is behind that. But I think like when Evan started the whole endeavor, it, it [00:07:00] also started with V right? Where it's like, okay, this was a thing, just a better developer, a developer experience for, for view than seeing, hey, this. This works for more than you, and then getting in touch with all the framework authors. And I think the same, more or less happened with the whole like. Tool chain, so to say, from Rolldown, to make sure all the, the framework offers from, I don't know, selt, overreact, router, uh, to quick, uh, viewing, kn, et cetera.

They're all behind it, and they can all give their input on what they need, uh, how things should work. Um, that's, I think this is a key part. Uh, other than that, well, I, I think it works pretty well also in terms of contribution. Very common risk in this consolidation is. I would say rarely in terms of the ecosystem that like, oh, we only have one choice because there are tons of other, like linters and and rs out there as we know as well. Um, but more of like, oh, now people have to write rust to contribute. How would that work? Uh, and also in terms of linting, we'll talk about oxland, OXC, uh, I guess in a bit. Um, this is a common criticism, but I think we're on a, on a good track there to make sure that people can also do it in [00:08:00] JavaScript.

Paige: So with Rolldown aiming to kind of match the flexibility of the rollups. Logins, how do you ensure the compatibility while also taking optimizing for the rest performance?

Alex: Well, the good thing is that we don't have to fully imagine something new. It's because there were so many tools in the past that did a lot of things very well, but not everything at once. Um, and having an extensive test suite, of course, it helps to say, Hey, there's a certain behavior. Let's take a look at how that works in roll-up, or in ES build or maybe even in web. And see how that would fit into our scenario and how we can tweak it. For example, saying, okay, we want to maybe even a different API, different options because the options back then they don't fit very well, but it's easy to migrate. We can just say, Hey, use the old ones, it's fine. We'll set the defaults correctly, and at some point we deprecate it and you can move over.

Uh, for example, with, I don't know, setting up JSX, um, this is way better configurable now than it was before. Um, so I, I think it [00:09:00] all, it all matters about. Considering the, the current situation and making it, yeah, as hassle-free while still providing good defaults and then transitioning over to something that is, for example, more powerful, more descriptive, uh, or just works better, but without leaving the current users out.

Noel: ~Yeah.~ How do you guys kind of determine what, which plugins and like features to prioritize there? ~Like what, what, how,~ how do you keep a pulse on like what people are using or have a grasp of,~ you know, like what,~ what are the things that are causing the most pain? ~Is it, is it kind of more like anecdotally,~ like you have a vibe or do you guys have like a data source that you, ~you, you, uh, ~monitor?

Alex: ~So I think a lot of it is, lot of,~ a lot is really based on user feedback. Um, because like V Powered by Rolldown is already available under the Rolldown V package as a drop in replacement for V. People can try it out. A lot of people did, even bigger companies did, and they reported quite some amazing numbers. Uh, there's also a repository called, uh, rolled on V perf wins, which shows like, Hey, build time before, build time after. And it's like sometimes like 16 x 20 x, uh, built speed improvement, which is is pretty 

Paige: Wow. 

Alex: Um, but, but coming back to the original [00:10:00] question regarding the plugins, the best part is everything.

Every JS plugin is compatible by default. So you, you can just use rollup plugins. The, the most important part there is to make sure that these can be called efficiently from the rust side. So, there are a few things that plugin offers even now can improve. Uh, there's a thing called plug and hook filters.

So let's say there's a rollup plugin and says, oh, I want to transform some code. Then usually they check, Hey, for example, is it a TypeScript file? If no, don't do it. Don't do anything.

The problem is if you check it in a function, that function has to be executed for every file because, well, you can't determine that.

So instead we have a hook filter, RegX or a glob that you can define even in ~v and rolldown now, uh, sorry,~ V and roll up, and of course also rolldown, uh, now and that will already work. So we have some kind of intraop layer there, uh, that is beneficial as soon as you use roll on beat. Then the function doesn't have to be called from the rust side again and again, but we can just take the regular expression or glob and say, okay, here are the files that we include or exclude. And then match. I think that's one thing where every plugin author can do something. There's even an, [00:11:00] an, issue, a tracking issue in the ecosystem performance initiative. It's like initiative that tracks or like reducing dependencies, making things faster, et cetera. Really cool project. Um, so that is helping a lot as well. And then when it comes to porting plugins to native, then it's about taking a look at what gives the best performance. So giving things a try, doing proof of concepts, starting with the v native plugins, and also see, uh, what is like popular demand. For example, rolldown can do JSX transformations out of the box.

Uh, it can even do style components. Uh, so there is a transform for that as well, just because of the popular demand and, uh. Yeah, if people are interested in certain functionalities, then it's always good to either raise an issue or if there's one, uh, thumbing it up to see what people are interested in the end.

Paige: ~Fair enough. ~So you talked a little bit about the plugin hook filters and lazy A ST deserialization. How important are these kinds of low level optimizations in building developer trust and a good experience?

Alex: I think it's [00:12:00] pretty important because like, just because you re rewrite things in rust, they're not automatically performant. Um, and that's, that's always the thing where also people end up like, okay, it's in rust now, but it's, I dunno, it's just 1.5 times faster. It doesn't make a big difference. Um, so then not like, I dunno, 16 or 20 times, which is what we're, we have right now. So the idea there, and thanks to the amazing people, uh, on, on the whole team, that like, they really worked hard of thinking, okay, what are the low level challenges and how to overcome them. So like, how to make these world plugins, um, actually work without much overhead and also without much overhead for the developers to adapt things. Uh, also seeing contributions from the community in a really easy way to say, okay, here's what you need. Here's how you can identify the cases, what you have to change. So also try to guide people there a bit. The whole like, um, there's a raw transform and yeah. Lazy ST deserialization, these are like very low level optimizations to make sure that we don't have to, uh, like do the same work twice.

So instead of saying, okay, I have my [00:13:00] abstract syntax tree of my code, so the technical representation, so to say, and I have that in rust and I have to somehow copy it over all the way into JavaScript. That's a lot of work for bigger files. So instead we just store that in, uh, basically, uh, a shared array buffer. And we, we just don't like, do the same work twice and for the future. Same idea to say, okay, I only want to take a look at part of the abstract sodex tree, like a specific type of, uh, node, for example. That will be very nice for linting plugins. Then we can do that without, once again doing all the work for the whole thing. But just partially. And these are very interesting concepts, uh, that that really helped for performance. And we hope to bring that even, uh, further to like roll down plugins, et cetera, et cetera, uh, to make things even faster.

Paige: So are these types of things that you. Optimizations that you're doing, are they things that, uh, library or, or plugin authors would need to think about? Or is it really just things that they'll benefit from as they're writing to work with Rolldown?

Alex: So for the [00:14:00] lower level optimizations, that's usually something that we cover behind the API, so people don't have to worry about and get the speed out of the box for the plug and hook filters. That's something that either the plugin authors have to implement themselves, or as I said, con uh, contributions from the community. Or we also give the option to the actual end developers to say, Hey, I use a plugin. It's maybe not very well maintained, but it still works. I can apply that myself. Or for example, I have a plugin there and for my use case, I know I can even narrow that down further to not cover, I dunno. All SVG files, but only SVGs files in a certain folder. So we even give that option to the, the developers to make their bills even faster. But I think that's most interesting for like the, the end user and like very big applications and smaller ones, it won't make a big deal for like 20 milliseconds,

faster, slower. Um, and of course, as I said, for plugin authors where we have a very big migration guide. To make sure that they can cover all the things and also support rolldown v and v at the same time. So to detect, oh, is Rolldown V there? [00:15:00] Then I want to use a different transform function, or I want to set different, uh, different options, for example.

Paige: Wow, you are really trying to cover everything and everyone, and that's that. That's awesome though. That's so good.

Alex: I think that's part of the mission. Like we really want to make sure everybody is in and uh, like all the use cases are covered, and if not, then people should let us know. It's also so nice for everyone who like submitted a feature request or a bug report saying like, Hey, I tried it out and in my case it didn't work.

It's always yet another point that we can improve. We can write a test case for, because. There are so many options out there, and also people doing so interesting and sometimes also obscure things that like you wouldn't necessarily think about it, but it's great that people test it out and I really appreciate everybody taking the time, getting the faster builds.

Of course out of that, that's also great. But um, yeah, just uh, just test that and giving feedback. So if you out there think, Hey, let's try that. Give it a shot. Definitely worth it.

Paige: ~Excellent. Alright, so~ earlier in this podcast you talked a little bit about Oxland and OXC, so let's. Switch gears and talk a little bit about what it [00:16:00] is, um, how it kind of claims really big speed advantages over things like Babel and SWC and even TSC. So what are the biggest challenges that you've seen in making that speed usable and stable at scale?

Alex: It's, it's very interesting, maybe to, to give a little bit of context there, because we started with like, okay, we have wheat and we want to unify the bundler and. Then the point is, where do you stop? And it continues further. Like right now, yeah, we have tons of different parsers. We have different options for linting.

We have different options for formatting, and the idea is eventually to have a unified JavaScript tool chain where we don't have to make all these choices. So basically the foundation for all the things is the same. They can, for example, also reuse caches, not like, oh yeah, here for that transform. I use a different tool.

And there is another thing doing that. As the end user, you might not even know because you might pull in the plugin. Let's say you pull in the React compiler, react compiler uses, uh, Babel. So then you have Babel automatically in that sadly won't change, um, until a rust based React compiler comes [00:17:00] out.

There's an open issue about it, and I hope that will happen in the future just for the speed gains and, and the aligning with all the tools. Um, but it's these, sometimes these are things that you don't know as someone just shipping features and fixing bugs and doing amazing work because. Nobody dives that deep into the tool chain. But yeah, to building some kind of bundle, you want to have a foundation. And that is OXC, the oxidation, uh, JavaScript combiner. And the idea is, is basically all the things you need, uh, for JavaScripts from parsing, resolving the modules, um, from transforming as well. So like syntax lowering also JSX, uh, et cetera, et cetera, based on the browser target. Minifying also very important for a production grade bundle. And then more interesting for the end users, once again. Uh, a linter, oxland, and a formatter. Roll Rolldown is using part of these things, funnily, even other tools like Web Hack considered using the OXC parr over things like acorn because it's way faster.

So great to see that this is really in the spirit of open source, uh, getting adoption across, across the ecosystem. That's the [00:18:00] idea. You can use all of these separately or as part of a bundler. Uh, and then of course for the linter. Yeah. Uh, you can use it in your projects right now. Um, you can convert your esly config all the way over to it.

We have a migration script. And the speed gains are compared to plain Es lint without type of linting. It's always important to mention like 50 to hundred times faster in benchmarks. So that's, that's pretty nice. I would say. Um, all the other tools as well, we have benchmarks for all of them, so we just don't throw numbers up there.

We want to make sure they're flo and tested. Um, so also if we say, oh yeah, we have the fastest, fastest parer that, uh, is fully correct, then we back that with actual numbers linked to the benchmarks are on OCRS and probably also in the show notes. For oxalate directly. I think the biggest steps that happened recently is the, the dreaded type irrelevant thing, which is often the problem, let's say when, when it comes to like slowing. Because very often you have rules on from TypeScript Dent and they're important, but they need time information, so you have to [00:19:00] run, uh, the TypeScript com. Of course, they have to, like in prototypes, do all the work, and that's commonly very slow. Now with TypeScript imported to go, um, we had a tool in the ecosystem, it's called TS Goland.

It was made by one of the core team members of TypeScript. The Sland, just as a proof of concept to say, okay, let's have a lender based on this. Typescripts native option. And, um, he said like, okay, I don't have the bandwidth. I don't have the time. Here's an example. You can do whatever you want with that, basically, but I, I don't want to.

So we got in touch, said like, Hey, we would be interested, can we like fork that work on that? And, uh, he even helped us further, um, work on that. So, uh, a OV read, uh, is the, the contributor's names like, okay, yeah, let's take a look. Uh, even dedicated some more time. And, uh, eventually we have the integration called oxland dash, ts golin.

That's in technical preview right now. Which runs, um, 40 type aware rules. So the typical like ts uh, es l rule set and that's quite fast. Now we're still improving the performance because well go [00:20:00] is not necessarily an easy language. Uh, and they're like also basically shimming parts of the TypeScript go, uh, API brings other challenges, but we're on that and it's, it's just nice that we have something that's like correct and that's working on top of Ts go.

So really happy to see that. Uh, and also of course there are the speed gains.

Noel: ~It sounds like there's, like,~ you guys are kind of attacking this problem from a bunch of different angles. ~Like it, it kind of,~ it kind of brings up. Two questions for me. One is ~like, how, again, how, again, how, like, ~how are you guys determining ~what, like, which,~ which of these things is the priority? ~Um,~ and it also like,~ makes me a little bit curious.~

~It kind, it kind of seems like, um, you know, there, I guess it is the case. So there's like a lot, ~there's a lot of work going on in this space. ~And like there, there kind of was already,~ and you guys are kind of stepping into this and providing this like, overarching tool chain. ~Um, is there, is there like.~ Is it tricky to figure out like what pieces of this you guys are like carving off and going to take on next?

And then once you do, like allocating that work, ~how, how,~ how are you guys kind of managing that internally?

Alex: Is tricky because yeah, there's just not enough time in a day, right? But we all, we all have that problem. Uh, I think in terms of what work to do, of course we wanna focus on making Rolldown production ready. So getting that stable and making that a [00:21:00] default bundle in feet. And for that, of course, sometimes we have to go, uh, a few levels deeper and et cetera.

And the same time working on this unified tool chain to just make sure, okay, we have a wonderfully working mentor, we have a format that's work in progress right now. Should be pretty compatible. It's also work in progress. Uh, and then seeing, okay, what, what does the community need? Once again, listening to the community, making sure people can, can voice their opinions. And then also see, okay, we have, of course, people dedicated to OXC and oxland, people dedicated to rollout. Uh, and then, then see what's, what's actually possible. For example, there are a lot of things on the roadmap that might take a bit longer. Now we have typo linting, that's a technical preview, so it's

already working. We wanna make it that stable, so better IDE integration. More like more tests, making sure that everything is actually fully correct, better performance, et cetera. But for example, one thing is custom component support, so supporting selt view, astro components, et cetera. That works partially in oxen, so you can link the script part because while

it's then just JavaScript and

TypeScript, but the rest not really, once again, custom [00:22:00] templates, that's, uh, always bit tricky. Uh, same for everything that's not necessarily JavaScript or TypeScript, which is the focus right now. Also including JSX and TSX. So, uh, we do that, but we don't do any h TM L or CSS is similar, so. We have to really keep the, the scope a bit smaller and then say like, okay, we, we, yeah, we can't tackle everything at once, otherwise in, in five years might be ready. Um, and also there iterating, seeing also what, uh, what companies need. We work together, uh, with a lot of people trying things out, reaching out. There's also contact form. It's like, Hey, we have this, this big use case, and we really struggle because our bills take age. I think that's a perfect use case to see what problems are at large scale.

And if you can fix them for large scale, then it will most likely also work for, uh, a smaller scale if done right.

Noel: ~Nice. Have you, have you found it, um, I guess how, how do you kind of manage the balance? You mentioned that there's, again, ~this is like largely all open source tooling and there's like a lot of maintenance and stuff happening. How do you guys kind of manage these projects that you're. Taking a much more active role in becoming stewards of, and ~like, like the,~ the existing communities there that are contributing externally.

~Like how's that, how's that? Uh, kinda, I dunno if transition process is the right word, but how,~ how's that [00:23:00] just kind of relationship played out?

Alex: I think the relationships are pretty well. I, for like, for Rolldown, OXC, it's pretty clear that Void Zero is like doing stewarding and and governance

there. Uh, v itself is in a way like a multi-stakeholder, uh,

project where you have people from different companies contributing. Uh, and in a way I think that's, that's great because. The web ecosystem needs that. I think it would be really bad if there would be just like, Hey, here's one company and we force all opinions on that. We, I would say we are exactly the opposite, that we want to make sure people are heard, uh, and, and to make sure things, things work out. Uh, and of course also like VT members, uh, the Core V test maintainer, they're on the payroll, avoid zero. Um, but that, that doesn't mean that they just push our, um, I dunno, our opinions or, or, or goals there. This is more like to improve the whole thing at once.

Paige: You said that you take feedback from everybody who opens bug reports or brings up GitHub issues, and one of the ones that you take feedback from is the larger enterprise [00:24:00] level applications or companies. So what are some of the, I guess, bottlenecks that you've seen most often in those really big repos, and where can they, I guess, get the most benefit from bringing rolldown or beat or different things into their build processes?

Alex: Yeah, I think like the two common things are really like long, long builds, um, build processes and the slow dev server, that's what we want to tackle with the full bundle mode, which is work in progress right now. So they're like against the build time. We can do something at the moment for the dev server time, that might take a little longer, but we're getting there. The other thing is definitely linting and there are companies, uh, that do, that do either of that, right? For example, Airbnb is not using Rollon at all, but they switched, uh, to ox lint to lint, uh, the check for, uh, barrel files, I think it is. Um, so it's also totally fine to not use all of the tools, but like, hey, if you have a slow lending process, post hoc for example, also switched. Switched over to Oxland and said, okay, this, this makes me way, or the company way more productive, [00:25:00] all the developers, because I might have things in an, uh, pre-commit hook and I don't know, wait, I don't know, 30 seconds, um, until things work, but just like one, so it, it really depends on use case. But I think the, the common thing is slow linting, um, most. most. often type, aware, linting related, but also not always, for example, barrel files and cyclical imports. Still, you have to check all the files to find out if maybe some files refer to each other in a, in a cycle. So that's also something where, where oxon can help a lot. And, uh, I think, yeah, these are, these are common use cases, so if you have anything that feels like very slow, um, it might be worth to check what it is and how any of the tools can help.

Paige: Yeah, I mean it, it's, that's such a cool idea that even if you're not using every part of the unified tool chain that you guys are building, you can kind of drag and drop the things that make the most sense for your project. So it's not one or all or nothing, I guess.

Alex: Yeah, I mean of course if you use one part, it might also make sense to switch, switch over. But if you say, Hey, no we are, we are happy with our tool and there, then it's also funny to [00:26:00] say like, Hey, we pull in v test in a project where we use, I dunno, web hack because we don't wanna switch over, we don't have the time for it, but. We want our test run faster, and it's also in a way of like an incremental adopt that, okay, I'll pull piece in here and maybe there, and at some point, um, you may be able to to like say switch, switch fully. Uh, and it's also great because everything is open source, right? There are no strings attached. You can use all of that.

It's MIT license and it'll stay like that.

Paige: Do you see any, um, maybe bar barriers to entry getting a little bit bigger because so much of the JavaScript tool chain is being rewritten and rust? Or do you think that there is still plenty of people for, for who are just JavaScript or TypeScript developers to get involved and contribute to the ecosystem?

Alex: I think it's like contribution wise, I'm personally pretty happy to see that OXC is a project where like there's always that one story of someone who said like, okay, I'll look into that. I wanna learn rust. And uh, he became part of the core team. So it's like, I think all of these projects are very open for contributions and. [00:27:00] Like, uh, very friendliness in a certain way. Of course, like if you maybe don't have a in-depth bundler knowledge, it might be difficult to contribute to roll down directly. But for example, for OXC, there are so many like isolated and well scope parts, it might be a bit easier. Um, and the problem that like, okay, you'd write tools in a different language for the JavaScript ecosystem, that always comes down to like, okay, you might have less people to contribute, but also nowadays with. Getting a bit of help with, uh, AI to like have a, having a first shot on the first draft and then iterate on that, um, is, is already quite helpful. So I, I would say it could hamper contribution a little bit. But it doesn't make it necessarily impossible. And the other thing is, for example, with oxland and all the rules that are ported over as native rules, right?

Because we have like over 500 ees, land rules and, uh, plugins, uh, ported over. So 500 rules from, from these plugins and all the native ees land rules. Um, you don't necessarily have to write your rules in, uh, rust in the future, right? You [00:28:00] can in the future use all the ees L packages, um, almost right? We try to aim for an ES l compatible, API there. That's still work in progress, but that's the idea. To also not avoid, like, okay, now you can only use a tiny subset. No, if you have like a, an an own custom rule, you don't have to rewrite that rust luckily. So there are also parts we say, okay, we, we don't want that to write all your rolldown plugins and rust or oxen rules.

Of course there are parts that we wanna port over because they might be very popular and also like they perform way better, um, on rust. So that it's just a, a good speed boost. But it's also good to just have an option for developers to do what they they did before. Uh, and it's of course a difficult balance to keep the compatibility, but still make things, um, quite performant also with like multiple threats.

But yeah, that's a whole topic on its own.

Paige: Well, that's actually a, a great segue. I wanted to ask like there are so many ES LT rules that exist, as you just said. How do you kind of balance supporting them all but also [00:29:00] being as fast as you can to get through the rules and make sure that people's code bases are adhering correctly?

Alex: Yeah, I think the start was really like porting the popular rules over to Rust. Um, that already helped quite a bit also with like. Caching the A ST on the rust side, so making sure you don't have to parse, uh, files multiple times. That is helping a lot. And then with the upcoming custom JavaScript plugins, that will be really nice so we don't have to like port every single rule over, so people can use it, they can decide to do it.

It might be slightly less performant. But then once again, if you have a rule that, for example, touches every file, ideally we can cover that. Or if it's like a rule that you write yourself, then you might live with the perf penalty. And it's not like it will just become 10 times lower. We also make sure this is optimized in the start.

It might be not as performed as will be the end. We'll, we'll get things first going. A simple, uh, prototype out there. People can try it and then iterate on that, making things, uh, better and better. And I think that's a, in a way, a really good way to say, okay, we're still very [00:30:00] performant. We're still better than your current setup. And from there things get better. But first you can also migrate over so we don't keep you from like, okay, I have to wait until this is released, until the next versions were like. You can, you can get it out trying and once again, give feedback, which, uh, shapes the direction a bit more.

Paige: You said that, um, you are taking, you know, inspiration from Webpac and other webpac is apparently taking inspiration from you or different companies that are using it are. So are you, is there a collaboration or a sense of competition between things like OXC and Biome and some of the other new up and comers who are getting into this ecosystem?

Alex: I would say like for example, OXC and Biome, we are in touch with, with the authors there. Um, biome actually even used the OXC Resolver for a long time until they went another way, which is of course totally fine. So I, I don't think there's like any hostility in that sense. Um, it's also open source eventually, and we are, we are of course looking into what other people are doing and [00:31:00] how that might be, uh, something that we can improve on, on our side. Um, but I think that's the general way of open source being inspired from each other, seeing what works. And in a way I think the competition part is more interesting for benchmark to see, hey, what runs faster, for example, uh, in terms of bundlers or also in terms of mini fires, there are really good benchmarks out there to see.

Okay, WC provides quite a small bundle. They're really good at, at Minification and there's still some advanced optimization that we wanna do. Uh, we can do it a bit faster. So that's another factor there. Um, but it's always nice to, to be pushed a bit more so to say.

Paige: Do you think that there's any sort of a path to kind of, uh, a shared infrastructure or a convergence, or is it more beneficial to keep going down kind of parallel paths, trying different things and then learning from each other in that regard?

Alex: I think the, the part of with the convergence will be more interesting in terms of adoption because tools can be as good as they want to. Right? We all still use a query keyboard, um, and we all adopted [00:32:00] that, that in a certain way. Um, so I, I think with that, just having v will be a big plus point for sure.

But of course, ideally we're building a unified JavaScript tool chain, also looking into V plus, um, for, well, later this year. Um, then to make sure, okay, it'll be very easy and people don't have this like choice fatigue, which is, I know a very common thing when, for example, I teach like JavaScript workshops, like, okay, oh, we need this and you need launch of that and you need to have a build tool.

And with feed has already got easier, but it's like, okay, need linting, I need formatting and this and that. Before you even write a single line of code, you have like all this tooling set up and it is painful. And we're not even talking about things like mono repositories. We just talk about a very simple, like single repository for a single project. And having all of that just stripped away and saying, here's something that works. It integrates both, all frameworks. I think this would be the, the overall goal. And if you say, I don't know. I don't want to use your linta, I wanna use something else, or formulator. Sure, go ahead. Like it's all open source.

You can assemble it on your own as well, but we want to make sure that the end goal is to make it [00:33:00] easy for people. Just like, Hey, I want to adopt everything. No problem. I have no headache and can just build my application.

Paige: That's excellent. Well, Alexander, it's been great talking to you. Is there anything that we haven't really touched on yet that you wanna make sure listeners are aware of?

Alex: think we covered a lot of things from V over to Rolldown, OXC. I'm, I'm personally, personally really interested in, uh, V con coming up, uh, this autumn, so I'm, I'm really curious about the releases there. Can't spell too much, but I, I think you might be too. Uh, so, so definitely check that out. Um. And other than that, I think we, we got into all of it.

Paige: So when will vConf be happening for

those who want to either attend or watch online, if that's possible.

Alex: It'll be possible, but of course, attending in person is always different vibe. Um, it is October 9th and 10th in Amsterdam, uh, the Netherlands and Europe. And, uh, I, I can just say like we have a really amazing lineup from like Tenor, Linsley, rich Harris Avenue. Of course, a lot of people from void zero from different [00:34:00] companies giving feedback on using Rolldown in the wild.

So for example, framer Linear will be there. Yeah, the agenda is pretty packed and I think there's something for, for everyone there. Uh, so definitely worth checking out the V com. Amsterdam. 

Paige: Well, Alex, thank you again for joining us. If people wanna get in touch with you to learn more about Rolldown or talk about BEAT or anything else, where's the best place to find you online?

Alex: I think the best place is Blue Sky and Twitter. Um, so I'm there at the Alex Litter, uh, on, on Twitter and Blue Sky is the alex lter.com. Uh, otherwise yeah, follow the roll down Void. Zero accounts for all the updates. We also post blog posts regularly void. Zero dev. I think yeah, these are the, the best channels.

And of course if you want to get in touch and chat about features, box, whatever, then uh, join the discord as well, uh, for rolled owner for OHC Info Vi of course as well. Uh, whatever you interested in, hope to see you there. I'm also around, uh, chatting regularly,

Paige: Fantastic. Well, thank you again for joining us. Thank you to Noel for joining us as my co-host.

Uh, we will see you again [00:35:00] on the next episode of Pod Rocket.