I'm using oxc_traverse and friends to implement on-the-fly JS instrumentation for https://github.com/antithesishq/bombadil and it has been awesome. That in combination with boa_engine lets me build a statically linked executable rather than a hodgepodge of Node tools to shell out to. Respect to the tools that came before but this is way nicer for distribution. Good times for web tech IMO.
in the beginning yes, but VCs want to cash out eventually. Look at mongodb, redis and whatnot that did everything to get money at a certain point. For VCs open source is a vehicle to get relevant in a space you would never be relevant if you won't do open source.
Interesting to see more Rust-based JS tooling. The performance gains are real but I'm curious about the ecosystem compatibility - does it handle all the weird edge cases that existing tools have learned over the years?
Also wondering if this could eventually replace parts of the webpack/vite pipeline or if it's more focused on the compilation step.
Oxc is not the first Rust-based product on the market that handles JS, there is also SWC which is now reasonably mature. I maintain a reasonably large frontend project (in the 10s of thousands of components) and SWC has been our default for years. SWC has made sure that there is actually a very decent support for JS in the Rust ecosystem.
I'd say my biggest concern is that the same engineers who use JS as their main language are usually not as adept with Rust and may experience difficulties maintaining and extending their toolchain, e.g. writing custom linting rules. But most engineers seem to be interested in learning so I haven't seen my concern materialize.
It's not like JS isn't already implemented in a language that's a lot more similar to Rust anyhow though. When the browser or Node or whatever other runtime you're using is already in a different language out of necessity, is it really that weird for the tooling to also optimize for the out-of-the-box experience rather than people hacking on them?
Even as someone who writes Rust professionally, I also wouldn't necessarily expect every Rust engineer to be super comfortable jumping into the codebase of the compiler or linter or whatever to be able to hack on it easily because there's a lot of domain knowledge in compilers and interpreters and language tooling, and most people won't end up needing experience with implementing them. Honestly, I'd be pretty strongly against a project I work on switching to a custom fork of a linting tool because a teammate decided they wanted to add extra rules for it or something, so I don't see it as a huge loss that it might end up being something people will need to spend personal time on if they want to explore.
The goal is for Vite to transition to tooling built on Oxc. They’ve been experimenting with Rolldown for a while now (also by voidzero and uses oxc) - https://vite.dev/guide/rolldown
Let's say 100k files is 300k syscalls, at ~1-2us per syscall. That's 300ms of syscalls. Then assume 10kb per file, that's 1GB of file, easily done in a fraction of a second when the cache is warm (it'll be from scanning the dir). That's like 600ms used up and plenty left to just parse and analyze 100k things in 2s.
I’m assuming they meant 100kloc rather than 100,000 files of arbitrary size (how could we even tell how impressive that is without knowing how big the files are?)
I wonder why did it take so long for someone to make something(s) this fast when this much performance was always available on the table.
Crazy accomplishment!
* You need have a clean architecture, so starting "almost from scratch"
* Knowledge about performance (for Rust and for build tools in general) is necessary
* Enough reason to do so, lack of perf in competition and users feeling friction
* Time and money (still have to pay bills, right?)
I believe it goes back a few years to originally being just oxlint, and then recently Void Zero was created to fund the project. One of the big obstacles I can imagine is that it needs extensive plugin support to support all the modern flavours of TypeScript like React, Vue, Svelte, and backwards compatibility with old linting rules (in the case of oxlint, as opposed to oxc which I imagine was a by-product).
I am fully aware of it, there have been many 'excited' posts in HN history about various programming languages, with related rewrite X in Y, the remark still stands.
It takes a good programmer to write it, and most good programmers avoid JavaScript, unless forced to use it for their day job. in that case, there is no incentive to speed up the part of the job that isn't writing JavaScript.
Some of us, already have all the speed we need with Java and .NET tooling, don't waste our time rewriting stuff, nor need to bother with borrow checker, even if it isn't a big deal to write affine types compliant code.
And we can always reach out to Scala or F# if feeling creating to play with type systems.
You can find a comparison with `bun build` on Bun's homepage. It hasn't been updated in a little while, but I haven't heard that the relative difference between Bun and Rolldown has changed much in the time since (both have gotten faster).
Bundler Version Time
─────────────────────────────────────────────────────────
Bun v1.3.0 269.1 ms
Rolldown v1.0.0-beta.42 494.9 ms
esbuild v0.25.10 571.9 ms
Farm v1.0.5 1,608.0 ms
Rspack v1.5.8 2,137.0 ms
Oxc is not a JavaScript runtime environment; it's a collection of build tools for JavaScript. The tools output JavaScript code, not native binaries. You separately need a runtime environment like Deno (or a browser, depending on what kind of code it is) to actually run that code.
Deno is a native implementation of a standard library, it doesn't have language implementation of its own, it just bundles the one from Safari (javascriptcore).
This is a set of linting tools and a typestripper, a program that removes the type annotations from typescript to make turn it into pure javascript (and turn JSX into document.whateverMakeElement calls). It still doesn't have anything to actually run the program.
I'm going to call it: a Rust implementation of JavaScript runtime (and TypeScript compiler) will eventually overtake the official TypeScript compiler now being rewritten in Go.
No, it it a suite of tools to handle Typescript (and Javascript as its subset). So far it's a parser, a tool to strip Typescript declarations and produce JS (like SWC), a linter, and a set of code transformation tools / interfaces, as much as I can tell.
For the love of god, please stop naming Rust projects with "corrosion" and "oxidation" and the cute word pwns related to Rust because they are currently overplayed.
I've played with all of these various formatters/linters in my workflow. I tend to save often and then have them format my code as I type.
I hate to say it, but biome just works better for me. I found the ox stuff to do weird things to my code when it was in weird edge case states as I was writing it. I'd move something around partially correct, hit save to format it and then it would make everything weird. biome isn't perfect, but has fewer of those issues. I suspect that it is hard to even test for this because it is mostly unintended side effects.
ultracite makes it easy to try these projects out and switch between them.
oxidation is a chemical process where a substance loses electrons, often by reacting with oxygen, causing it to change. What does it have to do with JavaScript?
Also wondering if this could eventually replace parts of the webpack/vite pipeline or if it's more focused on the compilation step.
I'd say my biggest concern is that the same engineers who use JS as their main language are usually not as adept with Rust and may experience difficulties maintaining and extending their toolchain, e.g. writing custom linting rules. But most engineers seem to be interested in learning so I haven't seen my concern materialize.
Even as someone who writes Rust professionally, I also wouldn't necessarily expect every Rust engineer to be super comfortable jumping into the codebase of the compiler or linter or whatever to be able to hack on it easily because there's a lot of domain knowledge in compilers and interpreters and language tooling, and most people won't end up needing experience with implementing them. Honestly, I'd be pretty strongly against a project I work on switching to a custom fork of a linting tool because a teammate decided they wanted to add extra rules for it or something, so I don't see it as a huge loss that it might end up being something people will need to spend personal time on if they want to explore.
It's blisteringly fast
* You need have a clean architecture, so starting "almost from scratch" * Knowledge about performance (for Rust and for build tools in general) is necessary * Enough reason to do so, lack of perf in competition and users feeling friction * Time and money (still have to pay bills, right?)
C is fine but old
And we can always reach out to Scala or F# if feeling creating to play with type systems.
In other words does it treat comments as syntactic units, or as something that can be ignored wince they are not needed by the "next stage"?
The reason to find out what the comments are is of course to make it easy to remove them.
But I guess it wouldn't be an apples to apples com parison because Bun can also run typescript directly.
In text form:
Bundling 10,000 React components (Linux x64, Hetzner)
This is a set of linting tools and a typestripper, a program that removes the type annotations from typescript to make turn it into pure javascript (and turn JSX into document.whateverMakeElement calls). It still doesn't have anything to actually run the program.
I hate to say it, but biome just works better for me. I found the ox stuff to do weird things to my code when it was in weird edge case states as I was writing it. I'd move something around partially correct, hit save to format it and then it would make everything weird. biome isn't perfect, but has fewer of those issues. I suspect that it is hard to even test for this because it is mostly unintended side effects.
ultracite makes it easy to try these projects out and switch between them.