Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JavaScript Oxidation Compiler

oxc.rs

Post reply on HN
Print view View original

31–40 of 147 posts

Re: The JavaScript Oxidation Compiler

#32

Post by ido »

iberator wrote: post #27
apatheticonion wrote: post #14

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?

I’m assuming they meant 100kloc rather than 100,000 files of arbitrary size (how could we even tell how impressive that is without knowing how big the files are?)

Re: The JavaScript Oxidation Compiler

#33

Post by Jarred »

hu3 wrote: post #25

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.

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

Re: The JavaScript Oxidation Compiler

#35

Post by xixixao »

galaxyLogic wrote: post #30

Does oxc-parser make it easy to remove comments from JavaScript? 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.

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

Re: The JavaScript Oxidation Compiler

#36

Post by leptons »

silverwind wrote: post #34
wangzhongwang wrote: post #18

[dead]

Depends on how conservative their minifier is. The more aggressive, the more likely bugs are. esbuild still hits minifier bugs regularily.

Over-minifying is kind of pointless, just do a basic minify and then gzip and call it a day.

Re: The JavaScript Oxidation Compiler

#37

Post by lioeters »

3836293648 wrote: post #12
zdw wrote: post #8

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 prog…

I'm going to call it: a Rust implementation of JavaScript runtime (and TypeScript compiler) will eventually overtake the official TypeScript compiler now being rewritten in Go.

Re: The JavaScript Oxidation Compiler

#40

Post by AbuAssar »

latchkey wrote: post #19

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…

oxc formatter is still alpha, give it some time
Post reply on HN