Yeah, but not how their implementation techniques differ from SWC's to produce those results.
I wrote a simple multi threaded transpiler to transpile TypeScript to JavaScript using oxc in Rust. It could transpile 100k files in 3 seconds.
It's blisteringly fast
sounds impossible to even index and classify files so fast.
What hardware?
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.
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
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).
Because Rust makes developers excited in a way that C/C++ just doesn't.
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.
This compiles to native binaries, as opposed to deno which is also in rust but is more an interpreter for sandboxed environments?
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.
Deno uses V8, which is from Chrome. Bun uses JavaScriptCore.
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.
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.
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.
[dead]
[dead]
Thought this was something related to Oxide Computer - they might want to be careful with that branding.
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?
Oxidation of iron produces rust. Rust is the language of implementation of that compiler, and of the entire Oxc suite.
All the Void Zero projects are super cool although I still wonder how they’re going to monetize all this.
they are going to use vite plus for monetization
I expected a coparison to `bun build` in the transformer TS -> JS part.
But I guess it wouldn't be an apples to apples com parison because Bun can also run typescript directly.
I'm surprised to see it's that much faster than SWC. Does anyone have any general details on how that performance is achieved?
They wrote a post (https://oxc.rs/docs/learn/performance) but it doesn't include direct comparisons to SWC.
Their main page says 3x fast than SWC
Yeah, but not how their implementation techniques differ from SWC's to produce those results.
I wrote a simple multi threaded transpiler to transpile TypeScript to JavaScript using oxc in Rust. It could transpile 100k files in 3 seconds.
It's blisteringly fast
sounds impossible to even index and classify files so fast. What hardware?
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.
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
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).
Because Rust makes developers excited in a way that C/C++ just doesn't.
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.
This compiles to native binaries, as opposed to deno which is also in rust but is more an interpreter for sandboxed environments?
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.
Deno uses V8, which is from Chrome. Bun uses JavaScriptCore.
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.
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.
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.
[dead]
[dead]
Thought this was something related to Oxide Computer - they might want to be careful with that branding.
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?
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…