The End of Frontend Fragmentation? How Rust is Unifying Frameworks & Tooling

Imagine you have the great opportunity to start this Greenfield project, and not Microsoft Windows XP, of course. So the first thing that might come to mind is what to choose. What stack, which framework, maybe, right? And hopefully one of these frameworks on here. And now you might wonder, okay, why these specific frameworks? There could be even more, of course, but what do they all have in common? And the answer here is Vite as the shared infrastructure of the web, so to say.

But of course, that doesn't stop us here. We say, okay, let's go back for a second and say, nice, we choose Vue or Svelte or React or Remix 3 or whatever. We continue here more or less with choices. That means now we have to choose a testing framework. So we have to think about, okay, what to use for end-to-end test, how do I do my component tests, my unit tests, etc. And then, well, if we think, okay, we have a framework and testing tool, we're kind of done.

Surprise, we're not. We also have to think about this, linting and formatting, and, well, a runtime as well, because that's the JavaScript we live in. So instead of just making one difficult choice, we make a few. Well, quite a few, too many, if you ask me and many other people out there, because we're all in some way fed up with all these choices we have to make. And if I now tell you that all the tools and the framework you might choose, they also could run on different things under the hood, like one of these things and a combination of these things. Yeah, that doesn't make things faster or better.

So, welcome to my talk, The End of Framework Fragmentation? Question mark, very important. How Rust is unifying frameworks and tooling. A bit about me, I'm Alex. I'm a web developer and dev rel at Void Zero. I am a web engineering consultant as well, and give talks, workshops, etc. I'm also on the NUX team, but that's not a topic for today's talk. And, well, I'm active on social media. I do a YouTube video once a week and stream if I have time, so almost never, but hey. And, of course, I have a portfolio website, and I always say I have to update it. It never happens due to, well, timing reasons. You know the problem as well. But let's talk about our Greenfield project. That's way more interesting, or maybe a legacy project as well. But in all cases, we want the best frameworks, the best tools, the best everything. But what does it actually mean? Well, first of all, they should be easy to use and easy also to set up, right? We don't want to, like, learn a whole new language just to use a new framework, necessarily. And they also should work together and seamlessly with our needs. So that should fit to what our application requires, what the business requires. And as we want to maybe learn a new one or use something existing, we also need some kind of documentation. It should be kind of good. No matter if we, like, old school vibes go through the MD files or through website, or we just ask our favorite AI model, they also need some data to understand the framework, and the code is often not enough. And to not reinvent the wheel, we also want to have a rich ecosystem, right? So plugins, extensions, integrations, etc. And then on all, they should also be blazing fast, but also reliable. So they should work ideally. And, well, we can't go around to talk about being future-proof because we don't want to rewrite our application in half a year when the project is unmaintained. We already talked about rich ecosystem in terms of libraries for your favorite frameworks, component libraries, integrations, etc. But it should also be easy to extend and easy to adapt. So it ideally fits, once again, your needs. And of course, maintenance should be there, should be well maintained, bug fixes should come regularly, and so on, so on, so on. This is not an exhaustive list, but in the end, all that we want is great DX. So, luckily, this here, the shared infrastructure of the modern web, gives that to us.

Because, well, you get a developer experience with an amazing development server with HMR right out of the box. We don't have to, like, refresh our page. And it even works with simple HTML projects. You don't even need a framework for that, which is amazing. We get native ESM out of the box. We get really sensible defaults that we can change if we need to. We get that rich plugin ecosystem based on Rollup plugins, which is still a great API to use. We get optimized production builds and more.

But, to be fair, some of you might not use Vite, right? All the Next.js users out there, for example, because you can't. It's not based on Vite, but on Fabpack and nowadays TurboPack. Still, let's have a quick look in the current Vite stack. Because, well, under the hood, there are a lot of build tools being used. We have ESBuild that's there for pre-bundling for a dev server to, like, at least concatenate some things for transforms and also for modification production. Then we have Rollup, already mentioned, a nice JavaScript based bundler. While ESBuild is written in native language in Go, which makes it pretty fast. So Rollup is, of course, there to do a chunk in the end, the production build optimizations.

Yeah, it's doing pretty great. Chunk control is, well, could be a bit better. And these are two bundlers, so to say. But there is a third one under the hood. If you're using React, then you might want to use SWC, which is written in Rust, and is an alternative for transforms and also supports React refresh. So while this is kind of great, it's also not, because now we have three bundlers kind of splitting up the tasks. And at some point, the point was to think, like, hey, can't we just, like, get rid of them? Can we just, like, unify them into one single thing? And well, that's what happened. So right now, if you're using Vite, you reuse these three different or maybe two different tools if you don't use React or don't opt into that. Well, instead, we just get rid of them and add this one here, Rolldown. That's a new Rust-based bundler. And now I think, God, why another bundler, right? Like, insert XKCD with standards here. Or maybe you're also wondering, wait, but what actually is a bundler and why do I need one? Let's go for it real quick, because it gets obvious after a while. This is a great start. This is maybe how your application might look like.

And the details are not that important. This is basically a dependency graph, but not of your node modules, but your own files. So you might say, okay, great. There is a certain file that depends on others. The green ones are dependencies. Then we have, like, TS files and whatever. And so this is basically how we write code, right? We import different modules. We might want to use dependencies, et cetera. And a bundler eventually will spit out this here.

That's a Dreamweb chart. You might have seen it if you analyzed your bundle. If you've never seen that, you definitely should take a look. And here we see the different chunks. So each color is a different chunk. And then you see boxes inside boxes. So for example, to the right, we have this big box. It says Sheeky on top. And then we have different smaller boxes inside, which are the files that are actually put together in this single chunk. Otherwise, each file would just be standalone. We would download thousands of files. So that's not necessarily ideal. And same for the rest.

But now you'd wonder, okay, why does it happen? I just mentioned the whole download thing, sure, but is there any other reason? And well, a couple of years ago, we might have seen this part here. DHH on stage saying, no, build. We don't need a build step. Well, hard disagree here. We definitely need a build step. So let's go through why exactly. Okay. A very simple case is this one, right? If we take a look, that's JSX.

That's great. Have you ever tried writing JSX in a browser? Well, you can't. It's not JavaScript. So it won't run. So we need something that converts the JSX into JavaScript. Same also for other formats like view single file components, you name it, etc. So this is something you need unless you want to write like render functions or similar React, which is possible but painful. Or if you say, okay, for example, I use view and just use a CDN, but then you don't have them file by file anyway. We have some downsides, no matter what we choose.

And the next thing is this one const a colon number equals one. And that's TypeScript. That's actually also wrong TypeScript because numbers are on string, but it's TypeScript and that also doesn't run in the browser. So we need to strip the types here at least. So we have to remove the colon number. Otherwise, well things won't work. And if you say, okay, you know what, I only use web components and I use plain JavaScript, it's fine.

Let's see what else is there. Let's take this code, for example. Here we say we take a function from date functions, great library until we get temporals and hopefully don't have to bother with dates in JavaScript anymore where the months start at zero. But let's say we want to format the date. Then we only want to use the code that's relevant for the format function and not all the other hundred plus functions from date functions, which are all great, but not for this use case. So if we wouldn't have a bundle, we couldn't do this. We just say, okay, give me all the JavaScript files.

But with a bundle, we can tree shake the whole thing out and remove the dead code. Dead code elimination is not a word for that. And that also means a smaller bundle, which is always great because then, well, the users, they have better experience. They load it faster, less requests, etc.

And then we also have this. Don't worry, I don't expect you to read all the code. This is actually the code from just right now, but minified, so tree shaken and minified. Here we see that, of course, the machine doesn't have to read the code like we do. So we can just do some optimizations and improvements to even squeeze out and make the bundle a bit smaller.

So in the end, we get better performance also here, less things transferred. That's helpful, especially also on low-end devices or with, well, a connection that doesn't work well. TLDR, why do we need a bundler? Well, a bundler transforms your non-JS code into JavaScript. It removes unused code. It will also combine or also spread your code so you don't load all at once.

You only load the things that you need. For example, if you say, hey, I have different pages, you don't need to load the JavaScript for all pages at once. So we can load things on demand. We have less network requests and waterfalls, which is always nice. So that answers what a bundler is and why, but why another one? Well, first of all, if we take a look at the big picture of a Vite from before, multiple bundlers lead to more complexity. So we get that. And there's also inconsistencies between dev and prod if you use different tools.

Another important part is though that there are limitations per bundler or features that neither rollup nor ES built support. So they're kind of out of scope. Also the thing production builds could be way faster, which is why we eventually chose to have a native build tool here. So let's talk about rolldown. And yes, the logo just rolled down. That's correct. And rolldown is more than just a Rustified rollup. It's very important, even though the name suggests that.

Initially the idea was, hey, why not trying to port rollup over to Rust? This didn't work out eventually, mainly because there were so many other great things that are so important to the ecosystem. So instead of just saying, hey, let's take rollup, why not taking all the good things that are there, that exist of prior art, of prior bundlers, and combine them. So we have Rollup's API because we still want to be compatible to that, to the plugin system and make the plugins work. We also want to have ES built speed, so to say, right? Native tooling, but also some behavior like define, inject, etc.

And here's a name you might have not heard for that long, Vappack. Yeah, that was also inspiration from Vappack because Vappack has really, really good optimization features in terms of chunking, controlling to say which JavaScript files should go in a single chunk. How should that look like? Which criteria should we create a new group, etc., etc. And of course, beyond it, there are also experimental features, right? Built-in HMR, inbound generation, CSS bundling, first-class module federation, and so on and so on. And for production-grade bundle, we also need magnification, so it's also there. And great. Okay, we're on a roll, so to say. We have the bundler, and actually, it doesn't stop there because, well, if you build a bundler, you need a lot of underlying tools. You need some kind of foundation, and there we chose OXE. Also before the creator of the project joined the company.

And if you take a look at the logo, right, this is an anchor. It's a brown anchor, so one could say it's rustified. And, well, how, like, you see the water in the background, and how is, like, rust actually being created? With like, yeah, you need water for sure, and air, oxidation. So let's go through what is actually in there, in the OXE compiler, and go through the components, and what you actually do. So, a few things might be interesting, especially for people looking into, like, all these low-level stuff, but there's also things that you, as an application developer, need. Let's go for it. First of all, the parser. So if you say you have your JavaScript or TypeScript code written, then you want to create a technical representation out of that, right? It's something called an AST, an abstract syntax tree, and that's necessary to do more things, to do operations on that.

And actually, for that, you have the parser. So we have OXE parser, which is the fastest JavaScript parser out there. Also important, there are links in the slides for all the benchmarks, so when I say fastest, this is actually a benchmark, not just like a guesstimate and roughly saying, oh, yeah, maybe. It's also spec-conform, so it passes all the tests to state 4 test. It's a conformance test suite. Very important because you don't want your application to fail building or to give a wrong code runtime. So, this is key. It is also three times faster than SWC, and five times faster than BIO. Just as comparison with other Rust-based tools, we don't necessarily have to compare to other parsers because, well, they were much slower than that. Let's have a look at the chart. Here, we also see what we just discussed, that the parser is quite fast here. BIO takes longest than SWC and OXE.

We also see, of course, shorter is better here. That's parsing the TypeScript.js file. Now to resolver, because now we have parsed our file, but we only use one file. Now, of course not, we use a lot of files. So let's take a look at resolving these modules and pointing to different files and dependencies and how it works. Now, we also have ESM and CGS in JavaScript, so different formats of modules. And well, they have different resolutions algorithms. So this also needs to be supported. And one more thing we did is saying, hey, why not supporting tsconfig directly because TypeScript is a given nowadays almost, right? So that also supports project references, extends, paths, aliases, and so on. And probably it's 28 times faster than enhanced resolve, which makes it a fast resolver here. And we have a chart here too. Sure, not a big issue. Enhanced resolve is taking way longer.

So we're here at quite the time. And then the transformer. So now we parsed the file. We can find out the other files and also parse them. But especially if you want to target all the browsers or use like more modern features, then you need to transform code. But also you need to transform TypeScript to JavaScript or anything else. So there are a couple options. This is where the transformer comes into play. And also there it has built-in React Refresh. So for all the React folks, that's amazing. And the syntax lowering that I just mentioned, like converting the knowledge coalescing operator, like the double question mark to the equivalent like polyfill, so to say, or like optional chaining is necessary if you want to support all the browsers. Even if you say we just support baseline, that still means here and there you need to syntax lower quite a few things. Another thing that the OXC transformer can do is it can emit the type declaration files. And of course, way faster than TSC with isolated declarations enabled. The reason there is also, well, because it doesn't do type checking. Here's an interesting thing once again for the React folks. Style components is actually a built-in feature.

Even though it's so to say legacy, it would slow your build down a lot. So why not have that built in to make sure that you can build pretty fast as a transform? If you use style components and you're bothered by build time, then using OXC transformer or roll down, which uses OXC transformer, is a good change. This is also the fastest transformer out there. Speed comparison for emitting DTS files shows that lower is better. Compared to Babel or SWC, lower is better as well.

Let's talk about a minifier a bit. We mentioned that a minifier is important for a production-grade application. However, it's not the fastest minifier out there. The smallest files are not guaranteed with the fastest minifier. The trade-off here is to be super fast and still have small files, making it one of the best speed and compression trade-offs. Benchmark results from Private Number compare SWC leading with a minzip size of 8.19 kilobytes and OXC Minify with 8.4 kilobytes, showing a small difference. Depending on the application, SWC, OXC, or another tool may perform better.

If we look directly at TypeScript, OXC Minify clearly wins the minzip size by a considerable margin. On the other hand, the C-based minifier excels in speed, with OXC being roughly five times slower. The C-based minifier produces a 1.13 megabyte minzip. The key is finding the right balance between speed and file size to achieve optimal performance in the minification process.

So that's basically why we said, hey, let's have a good trade-off there, to be super fast and still in a good way of having small files. So this is one of the best speed and compression trade-offs.

And to have a look at the benchmark, well, I didn't bring any graphs. Instead, we take a look at the benchmark from Private Number because he did a very extensive minifier benchmark test here from benchmarking different files and having different tools. And there, it's also automated. So that's great.

Let's have a look. For example, React, where SWC is leading here with a minzip size of 8.19 kilobytes. And then OXC Minify with 8.4 kilobytes. So we only have 0.2 kilobytes difference. It's not that big. It's interesting because depending on the application, you might see SWC in front, OXC, and sometimes also another tool.

So if we go, for example, to TypeScript directly, then we see that OXC Minify here wins very clearly the minzip size by quite a bit and actually C-based minifier wins the speed here, while OXC is roughly five times slower, so to say. But also, well, the C-based minifier puts out 1.13 megabyte minzip. So that's also a tricky part. In the end, it's important that the goal is, of course, to be number one for most of these parts. This is also a weighted score, so it will take both time and size into account. So, of course, we're working hard on that to make sure we'll come out on top on all the benchmarks at some point.

Most importantly, it is a complex scenario to test and we're on it, but it also needs some more improvements and time as well. Okay, now we talked about all the things that are necessary for the bundler, and the next two things will be super interesting for all of you because I know these are topics a lot of people are bothered with. So let's talk about linting. Yes, we actually have a linter in this set, and important, I mentioned components before. You can use all of these things separately. So if you want to try out the POS or the Transformer for your internal tool, go ahead. You don't need to have the whole suite. Same with the linter here, for example. It's called OxLint. It's a linter for JavaScript and TypeScript, right? So TSX and JSX are also supported. It has support for custom components, partially, and it's 50 to 100 times faster than ESLint. Pretty decent, I would say. We ported over 570 rules over to Rust from popular plugins, ESLint Core, etc. It's used in a lot of big projects and it's stable, but of course we still work on a lot of features like hyperlinting, which exists and is in preview, and that also works faster on TypeScript ESLint thanks to TS Go Lint. We also support ESLint plugins, actually, since like a good month, which means we want to be more performance, but that's something we can tweak on later.

Most importantly, we want to be ESLint compatible, and we covered a big chunk of the ESLint API, more to come, so you can use your favorite ESLint plugin, either through the native rules or if there's no equivalent, just through a JS plugin. Just to give a feeling for the numbers, one of the biggest ones was like, oh yeah, over 265,000 files with the standard rule set in 22.5 seconds. So that's pretty fast, I'd say. In terms of custom plugins, it's really easy. You can even write your own rules or have your company's or team's own rules to be supported, which is a big plus to migrate over. It's all just based on, okay, you can set up JS plugins, put them in there, and then you're good to go to use the rules as you would use them. And from the Linter, we also covered a formatter because this is the second part that all of you might be interested in. It is still a work in progress, a time of recording, but you can technically already try it out. We'll come to that at the very end.

It is the idea to be very performant with pretty compatible defaults, so you can just migrate easily, right? In terms of performance, what does it mean? Well, I have some first numbers for you, which is 2 to 3 times faster than biome and also 45 times faster than Prettier. If you use Prettier with the OXC Pulsar as Pulsar, which you can do, actually, it's like 32 times faster. So still magnitude faster. Now you might wonder though, why just rustify Prettier? Not exactly. We also want to make sure that we can address some typical issues like line wrapping, print width, etc. And also we are aiming for the best Prettier compatible tool, so the best Prettier conformance. So when you switch, it will just work. It won't give you huge diffs. Slotting should be built in, tailwind support as well. And there's an RFC. So if you're interested, please share your thoughts as usual.

And then testing. Well, we came from OXC a bit further to testing itself. We had testing mentioned in the beginning. And of course, now all the big runtimes have tests, right? They're test runners, hopefully also tests, but test runners like Node, Deno, Bun. And of course, with Jest is around and VTest is there too. So, well, with VTest, you have the good benefit that if you use VT, then it will just work seamlessly, but you don't even need VT for that necessarily. It's just compatible API-wise. You get out-of-the-box support for all the modern things, which is amazing. It has a SmartWatch mode, and it also has a mode called Browser Mode. And with the Browser Mode, which is, by the way, based on either PlayWrite or WebDriver.io, you can choose that. You don't need any fake DOM libraries. You don't need jsDOM. You don't need happy DOM. You can actually run your UI tests in the browser with a minimal overhead. That doesn't mean end-to-end tests because you can do them already with PlayWrite or with WebDriver.io or whatever you want to use. Selenium, if you're old school. No, instead, you really run your component tests in the actual browser, still fast and, most importantly, reliable. So that's amazing. And if that doesn't convince you, well, you should try it out for sure, it also has the highest satisfaction among the testing tools according to state of JS 2024.

And it's also now used as the default, not only if you use V somewhere, but also Angular is starting to use V tests as default for V 21, et cetera, et cetera. So we're going in a straight direction there.

And now let's have a look from the top again. You chose your framework, where application code and your UI and logic lives somewhere, like you have code on top of that. Then you go to Vite as your build tool, your dev server plugin system, V tests, a roll down bundler used in Vite at some point, right? For that code elimination, chunking, tree shaking, the bundling process, and then down there, OXC is used as, well, parser resolve for Transformer, Minifier, and also for yourself, with aux and aux format, as Linter or Formatter.

But let's go back to Vite here and talk about the future plans for roll on Vite. Because right now we're in a phase, okay, we have a separate package to stabilize and test roll on Vite. The phase two will be the Vite 8 beta. It might be out already if you're watching this, depending when you do, right? So there's no separate package anymore. Instead, we'll just use the beta there. And then at some point, this will become fully stable, and roll down is then the default bundler for Vite, which makes everything smoother and faster. Big wins.