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 personally met a lot of folks who care about both quite a bit.

But to be fair, besides the usual patterns like tree-shaking and DCE, "runtime performance" is really tricky to measure or optimize for

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.

they are going to use vite plus for monetization

Why should it be monetized?

attention is money

> 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.

> with no option to format them back

Try git reset --hard, that should work.

These files are under version control, right? Or backed up. Right?

This is user error. oxfmt did what you asked it to do.

You couldn't waterboard this outta me

Do you not use a VCS?

Git undo?

sounds impossible to even index and classify files so fast. What hardware?

arena allocation is a big part of it, but also oxc benefits from not having to support the same breadth of legacy transforms that swc accumulated over time. swc has a lot of surface area from being the go-to babel replacement -- oxc could design the AST shape from scratch with allocation patterns in mind. the self-hosting trap (writing js tooling in js) set a performance ceiling for so long that when you finally drop down to Rust and rethink the data layout, the gains feel almost unfair

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.

They wrote a post (https://oxc.rs/docs/learn/performance) but it doesn't include direct comparisons to SWC.

Because Rust makes developers excited in a way that C/C++ just doesn't.

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).

For a couple of reasons:

* 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?)

Fractured ecosystem. Low barrier to entry, so loads of tooling.

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.

Should be easy with any standard parser. See astexplorer.net

No, that would probably be pnpm, even thought it's not nearly as fast because it's written in JS.

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).

In text form:

Bundling 10,000 React components (Linux x64, Hetzner)

  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.

There are like 50 rust projects named by oxidation puns. This is hardly the first

oxc formatter is still alpha, give it some time

what next, stop using py prefix?

Oxidation of iron produces rust. Rust is the language of implementation of that compiler, and of the entire Oxc suite.

It is written in Rust…