So uv for JavaScript? Nice.
No, that would probably be pnpm, even thought it's not nearly as fast because it's written in JS.
I thought it's mainly written in Rust https://github.com/oxc-project/oxc . Which oxc project is written in JS ?
The JavaScript Oxidation Compiler
81–90 of 147 posts
Re: The JavaScript Oxidation Compiler
#82It always comes as a surprise to me how the same group of people who go out of their way to shave off the last milliseconds or microseconds in their tooling care so little about the performance of the code they ship to browsers. Not to discredit OP's work of course.
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.
Sometimes they are the same person.
It just take someone to have poor empathy towards your users to ship slow software that you don't use.
Re: The JavaScript Oxidation Compiler
#83Earlier quoted context omitted.
No, that would probably be pnpm, even thought it's not nearly as fast because it's written in JS.
I thought it's mainly written in Rust https://github.com/oxc-project/oxc . Which oxc project is written in JS ?
They are talking about pnpm (which they said would be the uv equivalent for node, though I disagree given that what pnpm brings on top of npm is way less than the difference between uv and the status quo in Python).
Re: The JavaScript Oxidation Compiler
#84I thought oxfmt would just be a faster drop-in replacement for "biome format"... It wasn't. Let this be a warning: running oxfmt without any arguments recursively scans directory tree from the current directory for all *.js and *.ts files and silently reformats them. Thanks to that, I got a few of my Allman-formatted JavaScript files I care about messed up with no option to format them back from K&R style.
> with no option to format them back
Try git reset --hard, that should work.
Re: The JavaScript Oxidation Compiler
#85I thought oxfmt would just be a faster drop-in replacement for "biome format"... It wasn't. Let this be a warning: running oxfmt without any arguments recursively scans directory tree from the current directory for all *.js and *.ts files and silently reformats them. Thanks to that, I got a few of my Allman-formatted JavaScript files I care about messed up with no option to format them back from K&R style.
This is user error. oxfmt did what you asked it to do.
I don't think so. If someone runs a tool without args, the tool should do equivalent of "tool --help"
It is bad ux.
Re: The JavaScript Oxidation Compiler
#86I'm surprised to see it's that much faster than SWC. Does anyone have any general details on how that performance is achieved?
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.
Re: The JavaScript Oxidation Compiler
#87For the love of god, please stop naming Rust projects with "corrosion" and "oxidation" and the cute word pwns related to Rust because they are currently overplayed.
[dead]
I said nothing about the rs prefix. But making oxide ferrous, Fe203 or whatever your whole shtick tells me nothing about your package and the pwn space is so so so very crowded at this point it just makes for a bad naming scheme.
Re: The JavaScript Oxidation Compiler
#88Earlier quoted context omitted.
they are going to use vite plus for monetization
The vite plus idea is that you'll pay for visual tools. What's odd to me is it makes their paid product kind of a bet against their open product. If their open platform were as powerful as it should be, it would be easy to use it to recreate the kinds of experiences they propose to sell. The paradox gains another layer when you consider that their whole mission is to build tools for the JavaScript ecosystem, yet by m…
> it cannot even host its own tools
You say this like this is the basic requirement for a language. But languages make tradeoffs that make them more appropriate for some domains and not others. There's no shade if a language isn't ideal for developer tools, just like there's no shade if a language isn't perfect for web frontends, web backends, embedded development, safety critical code (think pacemakers), mobile development, neural networks and on and on.
Seriously, go to https://astral.sh and scroll down to "Linting the CPython code base from scratch". It would be easy to look at that and conclude that Python's best days are behind it because it's so slow. In reality Python is an even better language at its core domains now that its developer tools have been rewritten in Rust. It's the same excellent language, but now developers can iterate faster.
It's the same with JavaScript. Just because it's not the best language for linters and formatters doesn't mean it's broken.
Re: The JavaScript Oxidation Compiler
#89Earlier quoted context omitted.
This is user error. oxfmt did what you asked it to do.
I don't think so. If someone runs a tool without args, the tool should do equivalent of "tool --help" It is bad ux.
I expect a file formatter to format the files when I call it. Anything else would be surprising to me.
Re: The JavaScript Oxidation Compiler
#90Earlier quoted context omitted.
> they are betting that JS-the-language is so broken that it cannot even host its own tools. Evan wallace proved it by building esbuild. this is no longer bet. > If their open platform were as powerful as it should be, it would be easy to use it to recreate the kinds of experiences they propose to sell. you would be surprised to know that tech companies may find it cheaper to pay money than developer bandwidth for st…
> esbuild Another example is the TypeScript compiler being rewritten in Go instead of self-hosting. It's an admission that the language is not performant enough, and more, it can never be enough for building its own tooling. It might be that the tooling situation is the problem, not the language itself, though. I do see hopeful signs that JavaScript ecosystem is continuing to evolve, like the recent release of MicroQ…
I don't think that's necessarily a bad thing, though. JavaScript isn't performant enough for its own tooling, but that's just one class of program that can be written. There are plenty of other classes of program where JavaScript is perfectly fast enough, and the ease of e.g. writing plugins or having a fast feedback loop outweighs the benefits of other languages.
I quite like Roc's philosophy here: https://www.roc-lang.org/faq#self-hosted-compiler. The developers of the language want to build a language that has a high performance compiler, but they don't want to build a language that one would use to build a high performance compiler (because that imposes a whole bunch of constraints when it comes to things like handling memory). In my head, JavaScript is very similar. If you need a high performance compiler, maybe look elsewhere? If you need the sort of fast development loop you can get by having a high performance compiler, then JS is just the right thing.