[bapak]

I seriously dislike this kind of comparisons.

We're faster! (please disregard the fact that we're barely more than a demo)

Everyone knows about 80:20, the slowdowns will come after you start doing everything your competition does.

Look at Biome. We're 15x as fast as ESLint (but disregard the fact that we don't do typeaware linting). Then comes typeaware linting and suddenly they have huge performance issues that kill the project (I'm unable to use Biome 2)

This happens over and over and over. The exceptions are very, very few (Bun is one example)

[eliseumds]

Idk, I'm having a good experience with Biome 2 in a large codebase. 4s to do a full-check including floating promises, undeclared and cyclic dependencies, and sorting imports. Our ESLint setup used to take almost a minute. The Biome team has been fixing bugs on a daily basis. Version 2.2.0 (released 3 days) ago addressed a common high-CPU-usage bug, try it out.

Edit: it's not 4s anymore, I just measured with the latest version and it takes ~900ms. Insane.

[no_wizard]

Are simply running eslint from the root of the project? And is this a monorepo?

I have used eslint in very large projects (far more than 3000 files) and running multiple instances via a task runner makes it a breeze to keep it under 30s or less, especially if you use the cache

[bapak]

I did try and it just stalls, taking down my CPU with it. I had moved onto other tasks and found it later still killing a few cores. It's in a monorepo with maybe 3000 files. I have no trust in the project.

[eliseumds]

Yeah I understand the frustration, I had issues setting up ESLint/Prettier years ago and spent a few hours getting the Biome configuration right. Also a monorepo with ~4000 TS/TSX files. If you ever feel like trying it again, make sure that you have "files.maxSize" and "files.ignoreUnknown" set. And be very careful with the "files.includes" list.

[no_wizard]

It sure would have been nice if biome used a better include syntax. I dislike the new way of doing it in biome 2, because it creates ambiguity and works differently than damn nearly every other tool I use

[austin-cheney]

I really find it annoying when JavaScript people complain about performance. If you think something is slow then make it faster and open a pull request.

It’s great when those PRs do come, but most of the time there is just empty whining while a developer contributes nothing. This is because most JavaScript developers are deathly afraid to write original software, as that would be reinventing a wheel.

Most JavaScript developers are absolutely incapable of measuring things, so they have no idea when something else is actually faster until else runs the numbers for them. Let’s take your Bun example. Bun is great but Bun is also written in Zig which is faster than C++. Bun claims to be 3x faster at WebSockets than Nodes popular WS package, because Bun can achieve a send rate of 700,000 messages per second (numbers from 5 years ago). Bun is good at measuring things. What they don’t say is that WS is just slow. I wrote my own WebSocket library for Node in TypeScript about 5 years ago that can achieve a send rate of just under 500,000 messages per second. What they also don’t tell you is that WebSockets are 11x faster to send than to receive due to frame header interpretation. I say not to disparage Bun but to show your empty worship is misplaced if you aren’t part of the solution.

[bapak]

I'm not complaining about performance, I'm complaining that people say they put out something faster and smaller only to find out they're not remotely comparable.

Did you know that moment.js used to be a microlibrary? It came out replacing "the huge Date.js library."

If you've been in the field long enough, you've seen this cycle repeat over and over.

[austin-cheney]

You were complaining about performance. If you, as in yourself the actual person, are not measuring things its just whining.

moment is a library discontinued years ago. They had a couple of commits in 2023 and a couple in 2022, but work stopped on the library almost 5 years ago. It is an abstraction over the big scary native Date object.

Up until 2 years ago I was writing JS full time for 15 years. I just saw a lot of people bitch and cry about inventing wheels and whining at performance targets they just guessed at. Its because most of these people could not write code. During this time there were some amazing things being written in JavaScript, and later TypeScript, but these awesome things were almost exclusively personal hobby projects the regular employed JS developer either bitched about or relied upon for career survival, because bitching and crying is what you do when you can't otherwise contribute in a meaningful way.

[antonvs]

> If you think something is slow then make it faster and open a pull request.

But I want someone else to make it faster without me having to do anything.

[damieng]

In my experience the type of developer using JS for their Web apps rarely overlaps with someone comfortable doing high performance C++ runtime work.

[wiseowise]

In my experience, the type of developer complaining about someone using JS is most of the time is some native C++/C/Rust (neck|grey)-beard. Most of the time they deflect it with "I don't support Chromium/Google" (they never elaborate why they don't contribute to Mozilla).