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.
I thought oxfmt would just be a faster drop-in replacement for "biome format"... It wasn't.
Let this be a warning: running oxfmt without any arguments recursively scans directory tree from the current directory for all *.js and *.ts files and silently reformats them.
Thanks to that, I got a few of my Allman-formatted JavaScript files I care about messed up with no option to format them back from K&R style.
> running oxfmt without any arguments recursively scans directory tree from the current directory for all .js and .ts files and silently reformats them
I've got to say this is what I would have expected and wanted to happen. I'd say it is wise to not run tools designed to edit files on files you don't have a backup for (like Git) without doing a dry-run or a small scope experiment first.
I assume you mean what’s more properly called Java style [1], where the first curly brace is on the same line as the function declaration (or class declaration, but if you’re using Allman style you’re probably not using classes; no shade, I’m a JS class hater myself) [2] or control statement [3], the elses (etc) are cuddled, and single statement blocks are enclosed in curly braces. Except I also assume that oxfmt’s default indentation is 2 spaces, following Prettier [4], whereas Java style specified 4.
So maybe we should call it JavaScript style? Modern JS style? Do we have a good name for it?
Also, does anyone know when and why “K&R style” [5] started being used to refer to Java style? Meaning K&R statement block style (“Egyptian braces” [6]) being used for all braces and single statement blocks getting treated the same as multi-statement blocks. Setting aside the eternal indentation question.
One thing worth noting: beyond raw parse speed, oxc's AST is designed to be allocation-friendly with arena allocation. SWC uses a more traditional approach. In practice this means oxc scales better when you're doing multiple passes (lint + transform + codegen) on the same file because you avoid a ton of intermediate allocations.
We switched a CI pipeline from babel to SWC last year and got roughly 8x improvement. Tried oxc's transformer more recently on the same codebase and it shaved off another 30-40% on top of SWC. The wins compound when you have thousands of files and the GC pressure from all those AST nodes starts to matter.
It always comes as a surprise to me how the same group of people who go out of their way to shave off the last milliseconds or microseconds in their tooling care so little about the performance of the code they ship to browsers.
People shaving off the last milliseconds or microseconds in their tooling aren't the same people shipping slow code to browsers. Say thanks to POs, PMs, stakeholders, etc.
TBH I don't know how to do that work. If I'm in the backend it's very easy for me. I can think about allocations, I can think about threading, concurrency, etc, so easily. In browser land I'm probably picking up some confusing framework, I don't have any of the straightforward ways to reason about performance at the language level, etc.
Maybe once day we can use wasm or whatever and I can write fast code for the frontend but not today, and it's a bit unsurprising that others face similar issues.
Also, if I'm building a CLI, maybe I think that 1ms matters. But someone browsing my webpage one time ever? That might matter a lot less to me, you're not "browsing in a hot loop".
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!
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).
* 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?)
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.
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.
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.
If you want native binaries from typescript, check my project: https://tsonic.org/
Currently it uses .Net and NativeAOT, but adding support for the Rust backend/ecosystem over the next couple of months. TypeScript for GPU kernels, soon. :)
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.
Too slow. Different people implemented linter, bundler, ts compiler in JS. That means three different parsers and ASTs, which is inefficient. These guys want a grand unified compiler to rule them all.
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.
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.
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
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?
owickstrom|8 days ago
pier25|8 days ago
rk06|8 days ago
shawn_w|8 days ago
hiuioejfjkf|8 days ago
[deleted]
Grom_PE|8 days ago
Let this be a warning: running oxfmt without any arguments recursively scans directory tree from the current directory for all *.js and *.ts files and silently reformats them.
Thanks to that, I got a few of my Allman-formatted JavaScript files I care about messed up with no option to format them back from K&R style.
tomashubelbauer|8 days ago
I've got to say this is what I would have expected and wanted to happen. I'd say it is wise to not run tools designed to edit files on files you don't have a backup for (like Git) without doing a dry-run or a small scope experiment first.
nindalf|8 days ago
Try git reset --hard, that should work.
jagged-chisel|8 days ago
Sammi|8 days ago
monster_truck|8 days ago
ctmnt|7 days ago
So maybe we should call it JavaScript style? Modern JS style? Do we have a good name for it?
Also, does anyone know when and why “K&R style” [5] started being used to refer to Java style? Meaning K&R statement block style (“Egyptian braces” [6]) being used for all braces and single statement blocks getting treated the same as multi-statement blocks. Setting aside the eternal indentation question.
1: https://en.wikipedia.org/wiki/Indentation_style#Java
2: https://www.oracle.com/java/technologies/javase/codeconventi...
3: https://www.oracle.com/java/technologies/javase/codeconventi...
4: https://prettier.io/docs/options#tab-width
5: https://ia903407.us.archive.org/35/items/the-ansi-c-programm...
6: https://en.wikipedia.org/wiki/Indentation_style#Egyptian_bra...
ljm|7 days ago
[0] https://github.com/microsoft/vscode/issues/32405
ramon156|8 days ago
phplovesong|8 days ago
root_axis|8 days ago
grabshot_dev|8 days ago
We switched a CI pipeline from babel to SWC last year and got roughly 8x improvement. Tried oxc's transformer more recently on the same codebase and it shaved off another 30-40% on top of SWC. The wins compound when you have thousands of files and the GC pressure from all those AST nodes starts to matter.
ameliaquining|8 days ago
snowhale|8 days ago
[deleted]
philippta|8 days ago
Not to discredit OP's work of course.
wiseowise|8 days ago
staticassertion|8 days ago
Maybe once day we can use wasm or whatever and I can write fast code for the frontend but not today, and it's a bit unsurprising that others face similar issues.
Also, if I'm building a CLI, maybe I think that 1ms matters. But someone browsing my webpage one time ever? That might matter a lot less to me, you're not "browsing in a hot loop".
TheAlexLichter|8 days ago
But to be fair, besides the usual patterns like tree-shaking and DCE, "runtime performance" is really tricky to measure or optimize for
pjmlp|7 days ago
apatheticonion|8 days ago
It's blisteringly fast
iberator|8 days ago
sankalpmukim|8 days ago
WD-42|8 days ago
chrysoprace|8 days ago
TheAlexLichter|8 days ago
* 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?)
throw567643u8|8 days ago
nullsanity|8 days ago
galaxyLogic|8 days ago
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.
xixixao|8 days ago
vivzkestrel|7 days ago
- how does it compare to biome?
- also biome does all 3 , linting, formatting and sorting, why do you want 3 libraries to do the job biome does alone?
latchkey|8 days ago
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.
AbuAssar|8 days ago
wiseowise|8 days ago
silverwind|8 days ago
hu3|8 days ago
But I guess it wouldn't be an apples to apples com parison because Bun can also run typescript directly.
Jarred|8 days ago
In text form:
Bundling 10,000 React components (Linux x64, Hetzner)
zdw|8 days ago
ameliaquining|8 days ago
3836293648|8 days ago
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.
jeswin|8 days ago
Currently it uses .Net and NativeAOT, but adding support for the Rust backend/ecosystem over the next couple of months. TypeScript for GPU kernels, soon. :)
nine_k|8 days ago
sneak|8 days ago
swiftcoder|8 days ago
lerp-io|8 days ago
throw567643u8|8 days ago
RealityVoid|8 days ago
hiuioejfjkf|8 days ago
[deleted]
wangzhongwang|8 days ago
[deleted]
VPenkov|8 days ago
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.
chronicom|8 days ago
silverwind|8 days ago
Ecko123|8 days ago
[deleted]
zenon_paradox|8 days ago
[deleted]
robofanatic|8 days ago
nine_k|8 days ago
ayhanfuat|8 days ago