Rust Meets React: Diving Into the Next Generation Build Pipeline for React Apps

How to Get Started with React When we think about our favorite setup, quickly, this comes to our mind. Not the Windows XP screen, but actually a Greenfield project. And there it starts already. When we think of a Greenfield project, we have to make a lot of choices. First of all, which framework do we use? Do we go with plain React, with Solid? Do we use something like React Router, Waku, CanStick Start? Or are we going with Laravel plus React, or Rails? Or going with Next.js? And of course, this is just one of many choices. We think of all the libraries we can choose from for state management, UI, etc.

And once again, not even talking about meta frameworks and so on. And then when we think about application code, okay, there we go. But we also should write tests. So there we have also a big choice from, well, of course, the runtimes that actually offer test runners nowadays, from end-to-end testing tools, or also simple test runners and more complex things. And there are sometimes not one tool is enough, but you need multiple ones. One for end-to-end and one for running the rest. And once again, I tell you, this is not the end yet.

We also have to think about things like linting, formatting, and the runtime itself that we mentioned, and so on, so on, so on. And we didn't write any line of application code yet, where we often also pull in other dependencies. So the classic problem of choice is actually being multiplied by, well, even more buttons than the ones you see here. And if I tell you now that this also means that all the tools that you choose in your build pipeline, they might rely on different things under the hood that are not necessarily compatible, and you might not even know about that. Well, it's clear why builds become sluggish and feedback loops become slow.

So, welcome to my talk, Rust Meets React, diving into the next generation build pipeline for React applications here at React Advanced London 2025. A few words about myself, I'm Alex. I'm a DevRel at Void Zero, also a Web Engineering Consultant, Speaker, and Instructor, as you can see here. I'm also part of the Nuxt team, so kind of an intruder coming into the Red Conference here from the Vue side. Nevertheless, I'm also posting regularly on social media, YouTube, and if I find the time, I also go live on Twitch. But that's rarely the case nowadays. I also have a portfolio website, but well, as you all know how it is with portfolio websites, they come usually last in the chain of updates, but we're getting there. But back to the talk. Technically, we want the best things for our project, the best frameworks, the best tools. And if we think about what best means, well, that means they should be easy to use, right? And also easy to set up. We definitely want to make sure that they work together seamlessly for our needs, not just in general, but also for our scenario. You should have a great documentation, a rich ecosystem, of course, because we don't want to reinvent the wheel.

They should be suitably fast, right? Reliable, future-proof. It's always a big word, but it's also like you don't want to rewrite your application every couple of months or years. They should be extensible and adaptable, so once again, we can fit them to our business needs, especially because they also might change every now and then. And also maintenance in general. Way to maintain this is important, so we make sure that also bug fixes and new features are released, and so on, so on. But this all can be summarized to, we want great developer experience.

And if we would start a Greenfield project now, cool, we can pick the best tools we can think of, and we can get started nicely. But unfortunately, most of us don't really work in a Greenfields project, so to say. Otherwise, well, I guess you can be lucky about that. But I'll tell you something. In this talk, we go through how we can actually get a bit of these Greenfield vibes back right into your project, at least for the pipeline and developer experience. And there's one simple thing to start with, and this is VEET, aka the shared infrastructure of monolab development.

For Next.js users out there, first of all, sorry, but no worries. There will be a lot of content for you in here, too. Hold on a second, we'll get there. But back to it for a sec. So VEET gives you, of course, a development server with hot module reload, native ESM support, very nice defaults, a rich plugin ecosystem. So you can choose any JSX-based framework you want and also integrate easily with metaframeworks, like 10-Stack Start being a VEET plugin nowadays, right? You get optimized production builds, thanks to rollup, under the hood, and much more.

But if you have a look at VEET, while it's not perfect, of course, the current VEET stack is actually quite interesting because VEET is a build tool that uses different bundlers under the hood. Here we have, first of all, ESBuild written in Go, and that's used for some small pre-bundling tasks for transforms and for minification in a production build. And then we have rollup, which does the bigger chunk for the production build, right? The bundling itself for production. It has the plugin API that we all love, and also VEET plugins are based on. And it can also do some chunk control here and there. And then for all of the people who prefer even faster things, there is SWC as an alternative to do transforms and also for React fast refresh. But most of you are familiar with that, of course.

Now, three tools under the hood for VEET is, well, it's a bit tricky, right? It makes things more difficult. And sometimes the thought comes, why not unifying this underlying bundler? So instead of saying, hey, we have three tools, let's just get rid of all of them and instead use one new tool called Rolldown. And now you might think, well, okay, why a fourth tool? Why another bundler? And maybe some of you think, wait, what is a bundler, actually? And why do I need one? So let's answer that question real quick.

First of all, we have this lovely graphic here. You don't really have to get into the details because it's basically just a dependency graph, but it's not about Node modules here necessarily. Though to be fair, there are some. The green ones are Node modules, but the rest are actually just files in one of many, many projects. So files that rely on each other or where you import different files, etc. And a bundler takes this, let's say, convoluted graph and puts it into that. Yeah, it's not just another representation. This is a tree map chart. And here you see that things are combined in a certain way. All colors are basically like one JavaScript file per color. So you have a light blue here, right? Like you have a cheeky one that's quite big. Then you have in the bottom the index and like a rust red, orange-y color and the top shortcuts and so on. Finally, these are the slides here. Also just made with SlideF and Vite. Under the hood. And yeah, the bundler is basically doing this in this representation. But you might wonder now, okay, why do we need this? Why do we need to combine all these files we've seen before? We can just shoot them all up, right? And there are some people who think the same. I say, look, we don't need to build. Actually, why do we even need a build step? Most famously, DHH said that a couple years ago at RailsWorld, right? But I'm here to tell you, well, we kind of do need a build step. So go ahead and build.

Let me tell you why exactly. We start simple with this. You all know what this is. This is a JSX component. And I would be super curious if someone could show me an example of just writing JSX in the browser so the browser understands it without a build step in between. Funnily, this applies also to other custom components like Svelte, Vue, etc, etc. And also this one here, right? We have, of course, this TypeScript, right? Also, wrong TypeScript because number is not equal to string one. That doesn't fit typewise. But nevertheless, also here you would need a build step or at least a way to strip these types if you use so-called erasable syntax. If you use enums, for example, or namespaces, then you actually need to generate some code and it's not enough to just strip the types away. So also here we need at least some kind of build step.

Okay, so far so good. There are two things we commonly use, right? JSX and TypeScript. So here's another one. Let's say we have a library and we just want to use one function. Then of course we don't want to import all the other, let's say, gazillion functions of date F and S here. Instead, we just want to take format and whatever format is calling under the hood. The problem is, well, usually that's not how it works. You just get everything unless your, well, build step, your bundler is doing some dead code elimination, also known as tree shaking. So to do that, once again, you need a build step.

And then there's one more thing. This one here. Take a few seconds to think of what it is. Probably most of you already guessed it. I mean, we're React advanced here, right? This is minified code, actually minified code from just before. So that code just here, of course, not the full one that would be a few more lines than 20, but we see some things like T times seven might be weak. T times 365.2425 could be a whole year, et cetera, et cetera. So we see that the code is there. And of course we want to minify the code to make sure we reduce our bundle size, which means small applications, less bandwidth and will happy users because they can download your application faster. So the TLDR of what is a bundler? Well, why do you need one? Bundler is there to transform a non-JavaScript code into JavaScript.

It removes unused code from dependencies, right? It recombines the code that you use into files. So you don't have to download them all at once. For example, an unused code can be downloaded later. You don't have to do it straight away, right? So that means JavaScript on demand, which is pretty amazing and therefore reduces network requests and also the waterfalls. And nobody likes waterfalls. I mean, except the real ones right there.

And last but not least, we also have the smaller bundles due to minification. So, okay, now we know what a bundler is, but the question might be why another bundler here? And for this, let's think about the VEED scenario. Well, first of all, we had these three build tools, right? And we wanted to make sure that we reduce the complexity because, well, all of them under the hood, it's not that easy. And also there are inconsistencies between development and production, given that VEED's dev server is unbundled.

So compared to Webpack, for example, they always had this bundle step before. Their dev and port are way more aligned. So this is also another thing that Rolldown can solve in the long run. And a bigger factor there is that actually there are limitations for all of these tools where, for example, neither Rollup nor SBuild nor SWC support or want to support. We say like, hey, look, it's out of scope. It's fine. And of course, last but not least, the production builds, wait, they could be way, way faster. And we'll see soon how. So now it's time to meet Rolldown.

Yes, the logo just rolled down from top to bottom. You got me. And while the name sounds like, okay, let's just take Rollup and port it to Rust, it's actually more than that. In the beginning, this was the thought like, okay, let's just Rustify it. But very quickly, the realization came like that doesn't fully work because there are a lot of tools out there. And just taking the fact that VEED relies on ESBuild and on Rollup, you have to combine a few things. And there is more.

So why not just take the best of all the worlds, the best of prior art exists and combine that into a fully new thing. So here we take Rollup's API, Rollup's plugins ecosystem, because while we want to stay compatible with all of them, and Rolldown is. So that's great. We want to take the speed like quote unquote, because while ESBuild is written in Go and Rolldown is written in Rust. So not the same language, but still native. So the speed of it, of ESBuild, and also some behavior like define, inject. There were a lot of good ideas down there.

And even from Webpack, there were some inspiration being drawn because of one thing that Webpack can do super well, which is chunking, right? Advanced chunking to define which JavaScript should be grouped, different constraints. So that is extremely helpful. And Rolldown will also do better chunking than, for example, Rollup or ESBuild. And then there are some more experimental features like built-in HMR, import map generation, CSS bundling, that's also coming in the future, and also first-class module federation that should all go into the bundler directly, which is quite important.

A lot of these things like HMR are just handled straight away by Veed, so by the layer on top of it, but you actually want to handle all of this on the bundle level, which makes things even faster. And then minification is also handled through OXC. And now you might wonder, okay, great, Alex, why talk about this Rolldown and Rolldown Veed? Why does it matter, right? And I want to tell you why it matters to you as a React developer out there.

First of all, faster production builds and faster builds in general mean faster feedback loops, right? So you don't have to wait for a PR forever and ever to run through. If you can cut down your build time by magnitude, it also means, for example, 10x faster feedback, which is always great. It makes faster deploy preview, deploy pre-prod staging, etc., etc. So you also have more time to build features, less context switching, and so on. It also means lower CI costs, which is great for a company, or if you paid yourself, you don't go that broke on this. And another thing, Rolldown can even lead to smaller bundles. It depends, of course, on the project, but there are also some things there to gain.

Last but not least, you can always make sure with this advanced chunking API that could probably fill a whole own talk that you can reduce the initial JavaScript and make sure things are chunked better. And the real impact is quite interesting because, of course, Rolldown is a work in progress for a while now. It's in beta right now. And here we have a minimal React router application, and we see that the bundle size, it got like two bigger bumps. But since then, it goes continuously down, down, down over the versions of Rolldown itself. So also we see that performance boosts are coming steadily, and this is all by just updating the version, which is also pretty amazing. Then Clues, of course, benefits from the minifier, so from the OXC side and from that code elimination and so on.

Okay, but this still doesn't tell us how a real-world project benefits from that, right? So here we go with Xcalibur. One of the great examples, React application open-source, uses Vita already. So let's have a look. And what I just did is, okay, I'll took it, and I say I'll build it with plain Vite. The latest one, 7.2 point something. And I'll just have a look. And it's built in like 52.5 seconds. All right, and we see roughly also some chunks here. And then I was like, okay, you know, I'll just do one more thing. I just want to change the whole thing to Rolldownbeat. So I upgraded that, and here we go. And the build times, well, they're just 7.5 times faster. And this is without fine-tuning. This is really just like switching out the dependencies. I have a few more steps to get to the latest speed. I'll tell you in a second. But this difference is really just a different alias for dependency, and that's it. I'll tell you there's more fine-tuning possible because Xcalibur already saw a 16x build speed increase in the past through Rolldownbeat. So there's more possible. It's just like the easiest way of trying things out.

Then we also see that there are partially smaller files. Some got a little bigger, some got a little smaller. But in the end, we should get out there with a smaller GZIP and minified size, which is also amazing by just, once again, switching out the dependency. So that's pretty strong. And all that while having compatibility as before, while having the functionality there. Now, let me quickly tell you how I did it. And as I said before, I just updated everything to the last VEED version, so the stable VEED version. I had to bump SAS because of, well, some outdated APIs. And then I just switched to Rolldownbeat. So that's more or less all I did, nothing else.

And that didn't even take long. So this was like, I don't know, less than, I think, 15 minutes. And most of this was dealing with SAS. So it's great. And Xcalibur is just one of many examples.

We have the list here. It's from a repository called Rolldownbeat PerfWins. And here we also see, all right, great. Xcalibur is here listed from 22.9 seconds to 1.4 seconds. This is definitely an older version that was tested. So before it was that fast. Plus, of course, your mileage might vary depending on the device.

But here, SafiRad, one of the VEED core team members, also part of Void0, took the chance to just create a trimmed down build, and we get a 16x build time improvement. Most notably, Outline, another great open source application, also built with React. There we got from 47.27 seconds plain VEED all the way down to 2.12 seconds, which is, yeah, it's insane. It's a 22.3x increase. And there are many, many more. Of course, not everybody has these huge, huge numbers. And that's also more than fine.

But we'll go in the right direction there. And these already have magnitudes. So that might be a great opportunity to try things out.

Now, of course, it doesn't stop there. Because, OK, now we have a bundler. But to build a bundler, you need a lot of tools and some kind of foundation. So let me talk a little bit about the OXC underlying, the JavaScript oxidation compiler, and a bit about a few components here.

Because, well, to build a bundler, you need a few things. You need to have a parser. So you need to take your JavaScript files or TypeScript files and transform them into a technical presentation, right, into an AST, an abstract syntax tree.

And OXC parser is the fastest parser here. It's spec-conform. So it parses all the conformance test suites from the TC49. So it tests 262 ECMA Stage 4 tests, which is great. It's three times faster than SWC and roughly five times faster than BIO. You have a quick chart that shows that exactly.

But all the things are also linked to benchmarks that we do. So this is all like has a good base, not just like, oh, yeah, it's the fastest. There are actual numbers behind it. Then we need to resolve some modules, both for, well, TypeScript, JavaScript, right, and ESM, and CGS. So we have different module resolution algorithms that's also implemented.

And the good thing is that the resolver also has support for your tsconfig, right? So that will be pretty nice if you have things like project references or path IDSs, which you should use according to TypeScript team, but people still do it. So we have to support it. There's also 28 times faster enhanced resolve. It's a fast resolver out there, so pretty decent.

Also, once again, quick comparison, of course, lower is better. And, well, then we want to talk about the transformer real quick, which is, of course, the big thing that transforms our TypeScript into AS Next or JavaScript into AS Next as well, like lowers that or JSX into JavaScript.

It has built-in React refresh, of course, and the syntax lowering is possible, so you can say, hey, I have JavaScript, but for example, the knowledge coalescing operator should just be converted into a polyfill because the browsers don't support it yet. So you can give in your targets there, and you're good to go. You can also emit DTS files, but, of course, it won't do type checking.

So that's also why it's quite fast. Faster than TSC, but it needs isolated declarations. That's also quite important. Otherwise, it won't work.

And then we also have something quite special for all of the Stack Component fans in here, or people who are still using Stack Components. It has built-in support for it, not for every feature, but for a subset that you can use. This is part of the transformer.

So before, usually, Stack Components, well, they're in every component if you use them, so they might slow down your build. And, well, with this, not anymore. And it's actually also the fastest transformer out there.

There are also comparisons to charts, one just to emit DTS here, and the other one is for transforming and lowering compared to SWC and Babel. Okay, so far, so good.

Let's talk about the minifier real quick because, well, the minifier is actually not the fastest. It's not the minifier with the best compression. So, so far, it was like the fastest, or, well, with minifiers, it's a bit difficult because the fastest ones, they never produce the smallest files.

And the ones with the smallest files are really the fastest. So let's have a look here. The benchmark that I didn't do myself, it's also not from us. It is from private number. He did a great job there comparing minifiers.

And the OXC minifier, I can spoil that already, is the one with the best compression speed trade-off, or at least one of the best. Okay, let's have a quick look. I said one of the best because it also depends on which file you benchmark.

With minifiers, it always depends on the actual source files that we check. For example, for React itself, to minify that directly, we have SWC, let me make it a little bit bigger, SWC winning here pretty clearly with 8.19 kilobyte in 12 milliseconds.

And then quickly behind that 8.4 kilobyte, so just 0.2 kilobyte more, OXC, minify. And then we have that in roughly 1 4th of the time, so in three milliseconds here. Whereas if we have a look at, I don't know, Moment.js, for example, they're also SWCs in the front.

The difference is like, I don't know, half a KB roughly. And we always have one quarter of the time for OXC minify.

If we take a look at TypeScript itself here, for example, OXC minify takes the leads in front of the rest when it comes to minzip size while still being faster than SWC, for example. So we always see that, as I said, it depends a lot on the files tested, but definitely things are in a similar range.

The good thing is though, we're of course working on the whole thing to make sure that we can also climb the top on the benchmarks, not for the sake of the benchmark, but to get you smaller files for, well, still a pretty fast time to build.

But now coming from things that are usually interesting for people building, well, frameworks, libraries, bundlers, et cetera, because you can use all these components separately.

The things that are interesting for you, if you're not a framework author, which probably most of you aren't, that's also more than fine because you all build amazing applications, I suppose. So let's talk about linting.

And I want to talk a bit about Oxlin, which is the linter part of OXC. It is a linter for JavaScript and TypeScript. So yes, JSX, TSX, of course, included, and it has partial custom component support. For now, more is on the roadmap later.

It is roughly 50 to 100 times faster than ESLint. That's without type of linting. And we ported over 600 rules, so more than that, over from popular ESLint plugins. So that also means that a big chunk of React-specific hooks are already built in. So for example, exhaustive debs, rule of hooks, et cetera, et cetera. Good to go.

By the way, there's still a few that are not implemented yet. So if you're interested in contributions, that's a great chance to also look into Rust a bit more. Nevertheless, it's used in pretty big projects like Preact, Bund, Vue, Linear, Shopify, Airbnb, and so on, so on. So that's quite worth it. It's already stable as well.

We had 1 to 26 times of release. And there's still some features being worked on. For example, type of linting, which works already. It is there in technical preview, but there's still a few more things to do. And it's one of the key things why your linting is usually slow.

So that works together with tsgo lint, and it's pretty decent fast. And there's JS plugin support. So actually custom lint rules that you may have wrote or somebody on your team or company, or you just say, hey, I want to use some ESLint plugin because the idea is they should be performance, but the performance comes afterward, right? Make it happen first, and then you can make it nice and fast.

But the idea is to be ESLint compatible, and that already works pretty well.

So if you have any kind of ESLint custom plugin that you want to run, you should give it a try. Most of them will just work. And there are some more things we can talk about what to work on. But most importantly, some numbers. If you think about like 265,000 files, how long it would take to lint with your favorite linting tool? Well, with Auxlint, it took 22.5 seconds with 10 threads and 101 rules, which shouldn't include typo rules, but still it's pretty amazing to run through that. So you should definitely look into that if you think, oh yeah, my linting, that might be a bit slower than it should be.

And before coming to the next part, let's have a look at the custom JS plugins once again, because this is our config for Auxlint. You don't even need a config. That's the best part. You can just run it, and we'll by default just go for correctness, which is what linting is there for, right? Some plugins are just enabled by default, but we can also define them on our own or say we want to remove some. Here, for example, we take TypeScript and React, and for them the correctness rules. But now with JS plugins, we can just say like, let's take ESLint plugin solid, for example.

We make sure it's installed for our favorite package manager, and then this is a good start. And in our rules object, we can just say, for example, solid prefer for, give us an error, please, when that applies. And of course, it doesn't have to be an ESLint package from npm. It can also just be your own rule that you point to, your own plugin, including the rules. And then you can say, hey, this is my awesome plugin, never ever use a fact to do just me. And of course, throw an error if that would happen. Would have helped some people here and there, right?

Because here, Oxlint does not do any stylistic rules. There is no support for that. We might get to JS plugin support for that. But internally we didn't import anything that's purely stylistic. That is part of the format.

And Oxformat is, well, a work in progress and a time of recording. An alpha release is quite short pending. So that might be already out when you see this talk. The idea is to have a performance formatter with Prettier compatible defaults. And of course, to make sure migration is easy, but also want to address some issues.

We have some benchmark numbers preliminary, right? It's the very first one. This is like two to three times faster than Biome and roughly 45 times faster than Prettier. If you use Prettier with the OXC pause already, which you can do already, then it's like 32 times faster. So still pretty, pretty decent. And as I mentioned, we want to address some issues like line wrapping, print some pain points with the current Prettier ecosystem. But on the other hand, we also want to make sure that you have the Prettier conformance by default.

But on the other hand, we also want to make sure that you have the Prettier conformance by default. So switching will be super easy because ideally nothing should change. There's also an RFC, if you're interested, where we discuss why you, for example, want to add built-in imports sorting, first-class tailwind support, and so on. So please make sure to share thoughts if you have any input on that, it's always, always appreciated. And if you want to, then feel free to try it out. But we'll come to that in a sec.

Now, once again, Excalidraw. Let's take a look. ESLint for the whole codebase took like 26 seconds in total. And for OXLint with similar rule set, we are down to four. So that's pretty decent. Without type-aware rules, actually would be down to 0.9 seconds, so not even one second, which is also really, really good. And then we say, okay, plus roughly 200 milliseconds for formatting. That's right now only JavaScript and TypeScript, but I think that's also still pretty much acceptable for the whole codebase. In this case, the JavaScript and TypeScript files only on JSX, TSX as well.

So in the end, it's important to mention that the performance is always improving, similar to the chart for smaller bundle sizes. For Rolldown, we'll also see always improvements to OXLint, Oxfam, and the whole OXC suite as well. Okay, so let's have another look at our whole Greenfield project or your Brownfield project that will get a little bit more Greenfield-y vibes. And of course, we start with your framework, your application code, your iLogic, etc., etc., etc. And under there, you have Vite as the build tool, the dev server, plugin system, and much more in the future, so to say, or maybe something else. But nevertheless, this won't stop you from using Vitest that we didn't even talk about because, well, time. As a Vite-based test runner, you can also use a standalone. That's the go-to library for running any kind of tests nowadays, no matter what you use. And yeah, then you can use Rolldown either separately if you want to for some kind of libraries through tsdown that we also didn't talk about or as part of Rolldown Vite for that code elimination, tree-shaking, bundling, and chunking.

And then Rolldown itself uses OXC. It's like the parser, resolver, transformer, and unifier. And you can use also parts of that, especially linter and the formatter. And then we have more or less the whole toolchain together that you can use separately but also like that.

So at the very end, I just want to quickly reiterate on the future plans of Rolldown Vite, actually. And the phase one was basically, okay, we have this separate package to stabilize and to test. And then in phase two, we get like the Vite 8 beta and no separate package anymore. Then we have a phase called 2.5 where we get an experimental full bundle mode. So we bundle in dev again as well. That's another interesting part.

If you have a question, run it, feel free to shoot me a DM. We'll definitely get there to make sure that our, let's say, a dev server start, the code start, not the hard reload for bigger projects will be way better because that's one of the shortcomings of unbundled. And now with a super speedy Rust-based bundler, there are more chances to improve that. So that's great, especially for the big projects. And then in phase three, well, we get everything in Vite and we get the default bundler for Vite is then Rolldown, and that would be Vite 8 then. So that's the rough overview and rough plan.

So the question is, are you ready to use the tools? For all Vite it's pretty easy because most of you might be on Vite already and let's use Next.js in this case. Yeah, unfortunate, but luckily there are also other cool meta frameworks and Vite itself can also do SSR if you didn't know that. So if you're on Vite, switching is super easy. It's basically from here over to there, straightforward. Or if the beta is already out, then we'll just go for 8.0.0 beta. And that's fine.

For AuxLint, it doesn't matter what you use under hood. You don't need to use Vite or anything. It's fully standalone. So go ahead and just run npx-auxlint on your projects to see what would come out there and to see how fast it would be with the general default rule set. Of course, you can configure things and type-aware anything. There you need to install the auxlint-ts-golint package just because it's still in preview. So then you can run it with npx-auxlint --"type-aware." And also see there how things will go. And you can add a config and do more stuff. But that's the easiest way to get things going.

For aux-format, well, if you're really eager, then just run npx-aux-format to format your files. And that's kind of that. Actually, there's one more thing I just want to mention. Vite Plus writes our approach for the unified tool chain for the WAP. So if you're interested in all these tools, but running them together, then it might be worth to take a look at viteplus.dev. And that's all I have for you today. Thank you so much for your attention. And if there are any questions, I'm curious for them right now for the Q&A. Thanks, everybody.