The Oxc Project, and the Effect of Performance Engineering

Hello, everyone. In this talk, I'm going to talk about the JavaScript oxidation compiler and the effect of performance engineering on this project. To start things off, my name is Baotian.

For the last decade, my job has been a frontend configuration engineer. I configured lots of JavaScript tools such as Grunt, Go, Webpack, and you name it. As part of my interest in experimenting with new programming languages, I began working closely with JavaScript tools written in Rust. These projects include Roldown, RSpec, BIOME, SWC, and RBRs.

In the meantime, I started and became the lead of the OXC project. So what is the OXC project? It is a collection of JavaScript tools written in Rust. Some parts are standalone and some parts are support other projects. The completed tools are the first three. The parser, which is currently three times faster than SWC, the linter, which is 50 to 100 times faster than ESLint, depending on the number of CPU cores you use, and a modular resolution tool called the resolver, which is 28 times faster than Webpack's enhanced result.

Next three things are what we are working on right now. A formatter, which is going to be pretty compatible, a transformer or transpiler that is going to be bevel compatible, and lastly the BigBoss modifier. And finally, OXC also supports the rising stars, the Roldown and RSpec bundlers.

It's rather hard to show why OXC is the next big thing, so I will let these people do the talking for me. Ivan Yu was amazed by the speed of OXLint, which is a linter for OXC. He ran it on the Vue repo and took 50 milliseconds. Joe Savanna, who is the lead of the React team at Meta, showed interest in the project and found it pleasing. Eric Simons, CEO of StackBlitz, also recognizes that it may be the next big thing. And Miles, the creator of Moon repo, was amazed by OXLint again.

Lastly, we have Jason Miller, Shopify DX and Creator of Preact, who said the following. OXLint has been a massive win for us at Shopify. Our previous linting setup took 75 minutes to run, so we were finding it out across 50 past workers in CI. By comparison, OXLint takes around 10 seconds to learn the same code base on a single worker and the output is easier to interpret. We even caught a few bugs that were hidden or skipped by our old setup when we migrated. And after a few months later, I talked to Jason again and he said they probably saved millions of dollars on infrastructure after they switched.

Let me quickly show a demonstration of the linter. Here we have OXLint running in the VS Code repo and on my Mac Pro, it completed 4.8k files in 850 milliseconds with the default 90 utilizing all cores. Yes, the linter finished the whole VS Code repository in less than a second. Now let's look at the diagnostics, where for each rule we try to pinpoint the exact same exact issue. Sometimes you don't even need to read the error message to understand what's wrong with the code. The first rule, no const binary expression, is my favorite rule, which has been inside ESLint version 8 for more than a year now. This rule could have cost so many bugs in the past year if it were turned on by default in ESLint when it was first introduced. But unfortunately, it is a breaking trend to turn on new rules, so it has to be introduced in a major version and was only turned on by default in version 9, which was released in April. In my opinion, one of the major tasks of the linter is to view hidden bugs, so such bug-revealing rules should be turned on by default as soon as possible to help people ship better code. Users of OXLint have been enjoying this rule since the beginning. And like for example, for this rule, it's pretty obvious that, but it's not obvious that the knowledge operator has a lower precedent. So to fix the code, you actually need a parenthesis over here. And for these rules, if you just look at the red line, you'll probably understand what's wrong with the code and fix it. What I'm really excited about OXLint today is that we can perform cross-file linting. This means we can implement rules from ESLint plugin import, which are notoriously slow if you enable certain rules, such as the no cycle rule on the left-hand side of the screen.

However, in OXLint, cross-file linting is done in parallel and ASTs are shared. So the only overhead we encounter is to wait for dependent files to finish passing. Once again, in the VS Code repository, completely running the no cycle in less than a second, which probably take a considerable amount of time with ESLint plugin import. And I think the diagnostics is a little bit better, which shows what the cycle is. If linking the VS Code repository under one second is not impressive, I also stress tested on the large internal repository, it completed 122,000 files in 3.4 seconds. What this entails that if you put all your companies or your own projects repositories side by side, and then run OXLint in the parent tree, you should be able to learn all your code in one go in a couple of seconds. This is great because with every OXLint upgrade, you will probably catch a few more bugs for your entire company or your projects in a few seconds, saving a lot of maintenance burden and infrastructure money.

So how did it get started? Well, my focus on performance started two years ago during lockdown. I was actually left with a super slow laptop, the Intel i5 with only 8 gigabytes of RAM. Everything was so slow. I had nothing else to do, but this laptop put my time perspective in slow motion. At that time, I discovered, and at that time, I discovered the Bion project, which was called Roam at that time. I brought in the whole integrated tool chain concept of frontend tools, but I was faced with two problems. One is the slow computer problem, and the other one is actually imposter syndrome. I didn't know what I was doing, so I eventually ended up learning from scratch. From learning what an ASC is or what an imposter is, I wasn't even good at Rust at that time. I just kept on learning and persisted with adding more code. And now, many months later, when I was out of lockdown, I discovered this. I somehow created the fastest JavaScript parser written in Rust and learned her with unimaginable speed. Performance plays such a big role in the project. So I eventually came up with this principle after getting inspired by a few community members. All performance issues are considered as bugs in this project. So performance does not mean just program execution time, but also compilation speed and continuous integration time. Everything that feels slow should be broken as a top priority.

Let me demonstrate these concepts with the OXE repository. This is the GitHub actions page showing the runtime of all the jobs. It runs tests on Windows, Ubuntu, macOS, and WebAssembly, and then checks the health of the codebase. All of the jobs are completed within three minutes or so, which I believe is faster than most of the larger Rust projects and some of the larger JavaScript projects as well. So I think for a project to sustain well, it needs to provide contributors a very fast feedback loop when they are unfamiliar with the project. And I have a story to tell.

As you may know, I also work on the ISPAC project. The CI time was around an hour when I joined, and it took me a month to get down to 20 minutes. I had no more tricks up my sleeves. I tried to fix every code issue that existed, but then I eventually gave up because there was nothing else to fix, or it's way too hard to fix. So the final thing is I convinced my managers to throw money at the problem and brought the CI time to five minutes. So slow CI times cost human time, and making it faster may actually cost a lot of money.

We also have a benchmark setup called continuously benchmarking using Cosby as the tool and platform. What Cosby does is it records metrics such as CPU cycles using Valgrind, and then it computes a speed number and stores it in a database for error commits. This makes benchmarking reliable, removing computer hardware out of the equation. This screenshot shows one of the most mind-blowing performance improvements in the history of the OXC project, which made our parser from two times faster than FWC to three times faster, and running all our test benchmarks, test cases, which there is around more than a dozen test cases, and they are all done in five minutes. Yes, when you push code to the OXC repository, you will get this benchmark result within five minutes.

Performance is actually a very vague concept when we work on it. It is often neglected and is the last thing to consider for a project. It's hard to convince people to work on performance as a priority until it becomes really slow, mostly because of the famous fallacy. The out-of-context code premature optimization is the root of all evil. But this all changed when I started watching the MIT OpenCourseWare performance in terms of software systems. In its first lecture, it stated the following. Performance is the concurrency of computing. Often, you can buy needed properties with performance. It's really hard to understand what is needed properties. Well, there are actually things like correctness, testability, maintainability, reliability, usability, all sorts of things that comes with creating a software. Performance is one of them.

To demonstrate this concept, here we have a conformance sheet testing all of our tools against test262, Babel, and Hydro test sheets. It essentially checks the behavior of our tools against our predecessors to make sure we conform to the same behavior. Here in this screenshot, we completed running more than 50k test cases in only two and a half minutes. I think test execution time becomes a bottleneck for logical basis when you get to this many test cases. But in NeoXe, since everything's fast, completing the tests are also faster. If you aren't aware from the numbers in the screenshot, it currently passes 99% of the test cases. This means the parser is ready for production and you can use it. When I talk about buying properties with performance, I believe we can also buy innovation with performance.

This comes to our last topic, performance as a path to innovation. When I worked on JavaScript infrastructure, I always wondered why we needed to compile JavaScript and publish to SDNs. We enjoy the last JavaScript features, but they need to be transpiled to an older version, then shipped to the user, which results in a code bloat. And then, slow website. It is where to sacrifice performance for the tail end of users.

We have been doing this since the beginning because performance is actually the elephant in the room. Because transpilation's slow, modification's slow, pushing to CDN and serving files as well. Everything is kind of slow. When Jared Sumner created BAN, his project goal was to create a bundler, not a runtime that we are seeing right now. He independently realized that once peak performance reached, we can just do bundle on demand with a layer of caching. In this way, users using newer browsers will get smaller files, leading to faster websites.

And this is a screenshot of the benification benchmarks for our current JavaScript minifars. We have SWC, ESBuild, and two minifars written in Go, the third one and the fifth one. And one written in Rust, the first one SWC. And then once you're writing JavaScript, the second one, AgilifyJS, enters number six. What's interesting that the current era of tools written in Rust and Go can minify a megabyte of file. But the tools from the past era cannot. For a lot of larger codebases and larger web apps, the amount of code we ship to the user is even larger.

So as our codebases grow larger and larger, especially for large web apps, some of the existing tools become really slow, just crashes out of memory. What's really interesting, though, is Google Closure Compiler on the list. It actually has an advanced mode, which can probably beat other tools in compression size. But unfortunately, it only works on Google infrastructure and nobody else can use it because it's really, really slow. It does a ton of ASD passes in Java. We can't blame them, though. Google Closure Compiler was created so early and Java was the only supported in-house languages. So if OXC gets the chance, all our current work will lead to creating our own minifier, which will aim to have the best compression size similar to Google Closure Compiler with smaller performance to SWC and ESP. So OXC was my independent project for the last two years but will be no longer. The project is now on a mission to fully support the Rolldown founder as well as seeking better and newer solutions to JavaScript infrastructure with Yzero, the company.

And if you have any questions, feel free to visit our website or reach out to me on our Discord or my Twitter. Thank you for listening.