Does Deno consider replacing SWC with OXC

[ofzo]

source :https://github.com/oxc-project/bench-javascript-parser-written-in-rust

Looking at the results, OXC seems to be a lot faster than SWC.

Also, OXC's API looks more convenient to use.

[jhsware]

This is my outsider view of this question, since it is always worth challenging assumptions.

There are a couple of reasons why this wouldn't make sense at this time:

1. swc is already a working integration in deno
2. oxc is under heavy development with breaking changes as late as 3 days ago (more than half a year after the question was posted)
3. VoidZero is a VC-funded project which could cause some surprising pivots

As is, it would probably make more sense to support the swc-project with perf.analysis and optimisations.

Competition is useful, but swapping one set of known issues for a new set of unknown issues may not provide the change one is hoping for.

[nickchomey]

Isn't Deno VC-funded itself?

Like Deno, the pedigree of VoidZero/Oxc seems reputable enough that this wont happen. And even if it does, people would surely fork it.

Though I think it would make more sense to wait for Oxc, and particularly Rolldown, to become a bit more mature so that it can be an all-in-one solution for linting, bundling, minification etc..

[tannal]

oxc-project looks good, if deno can make that happen, I think it can be a change for adoption from more front end developers.

[jhsware]

@nickchomey you are correct! However, the Deno pitch is a managed runtime service. This makes adoption of Deno the driver of potential revenue. VoidZero is literally pitched as a developer toolchain so we don't know what the revenue model will look like.

[jhsware]

Oxc is very much on the radar according to this discussion: oxc and VoidZero

[Thor-x86]

I used OXC previously on a real project. The big drawback is multi-threading not supported. Then I have no choice other than revert to SWC.

[KnorpelSenf]

IMO they should honestly want to replace deno_lint with Oxlint, too

[marvinhagemeister]

Some stuff that is missing in oxlint that makes switching right now difficult:

• No plugin support (they're working on it, but it's not yet released)
• No support for linting the module graph. Whilst not exposed as an API to users, our linter supports checking if a file is allowed to be imported from another file and stuff like that.

So yeah we would love to make the switch, but oxlint is not there just yet.

[KnorpelSenf]

That makes sense. So in other words, as soon as these things are added and oxlint is a strict superset of deno_lint in terms of supported rules, you would consider making the switch?

I've run into denoland/deno_lint#1331 once again which shows some pretty fundamental limitations (maximum nesting of blocks? really?) of the current linter and I still think it would be great to move over as soon as possible.

[KnorpelSenf]

While we're here: how come you chose a bundler written in go by going with eslint, rather than picking OXC for this, too? I'd assume that embedding would be much easier with a rust crate. Is it about maturity once again?

[birkskyum]

Related to

• port to oxc deno_ast#331

[KnorpelSenf]

Finally