The JavaScript Oxidation Compiler

Original Article ↗ Hacker News Discussion ↗

Business model and monetization

  • People are impressed by the tools but question how the company will make money, especially given VC backing and eventual pressure to “cash out.”
  • Vite+ is described as the main monetization path:
    • Positioned as an all-in-one JS toolchain and monorepo solution targeting enterprises, competing with Nx/Moonrepo/Turborepo/Rush.
    • Value props: single configuration, shared AST/dependency graph info between tools, better caching and CI performance.
  • Some see a tension: selling visual/enterprise tooling on top of a powerful open core might allow others to re‑implement similar experiences for free.
  • Others argue enterprises prefer to pay money rather than spend developer time, so this is not a real paradox.

Rust vs JavaScript (and others) for tooling

  • One camp says moving to Rust/Go for JS tooling proves JS can’t viably host its own high‑performance tools (esbuild and the TypeScript-in-Go rewrite cited).
  • Another camp pushes back:
    • Languages make domain tradeoffs; not hosting tooling isn’t “failure.”
    • JS is good for fast feedback, UIs, plugins; heavy compilers and linters can live in Rust.
  • Broader sentiment: “not everything needs Rust,” but Rust’s safety and excitement make rewrites more likely now than with C/C++.
  • Many note this is part of a general trend away from JS-based tooling towards native-core tools that still expose JS plugin APIs.

Performance, architecture, and why now

  • Multiple reasons given for “why it took so long”:
    • Need for clean-slate architecture, deep performance knowledge, and real pain from slow tools.
    • Fractured ecosystem and low barrier to entry led to many smaller, slower JS tools.
  • Technical points on oxc performance vs SWC/Babel:
    • Arena-allocated AST designed for multiple passes (lint + transform + codegen) with fewer allocations and less GC pressure.
    • Less legacy transform baggage than SWC; data layout tuned from scratch for speed.
    • Anecdotes: big CI pipelines seeing ~8x vs Babel with SWC, plus an extra 30–40% from oxc; claims of extremely fast TS→JS transpilation at large scale (exact conditions debated).

What oxc actually is (and isn’t)

  • Clarified repeatedly: oxc is a suite of JS/TS build tools (parser, transformer, TS “type stripper,” linter, formatter, traversal utilities).
  • It outputs JavaScript; it is not:
    • A JS/TS runtime (you still need V8/Deno/Bun/browser).
    • A native binary compiler (another project was linked for TS→native via .NET/NativeAOT).

Tooling quality, UX, and overlap with Biome

  • Some users report oxc-based tools (especially the formatter) behaving poorly on half-written code and prefer Biome “today.”
  • Others note oxfmt is still alpha and ask for patience.
  • A complaint: oxfmt with no arguments recursively rewrites all JS/TS files in the current tree. This surprised some:
    • One group says this is expected and documented, and you should always use VCS and/or try tools in a throwaway directory first.
    • Another group calls it bad CLI UX; they expect tool with no args to show --help rather than modify files.
  • Question raised why the ecosystem needs multiple Rust-based formatters/linters when Biome already combines linting, formatting, and import sorting.

Broader ecosystem and naming

  • Some see oxc as part of a “grand unified compiler” approach: one fast Rust core powering linter, bundler, TS compiler, etc., to avoid duplicated parsers/ASTs.
  • Skepticism that Rust-driven tooling speedups coexist with widespread tolerance for slow, bloated browser apps; others argue these are often different people/problems.
  • Naming complaints: oxidation/rust/corrosion puns are viewed by some as overused and uninformative, though others note such naming patterns (like py- in Python) are common.