Hacker News new | ask | show | jobs
by g947o 164 days ago
> Their only argument for not supporting eg. "for-of" is because of "legacy" browsers not supporting it.

Not really, their rational is written in the document I linked --

    Why? This enforces our immutable rule. Dealing with pure functions that return values is easier to reason about than side effects.

    // bad
    let sum = 0;
    for (let num of numbers) {
      sum += num;
    }
    sum === 15;

    // good
    let sum = 0;
    numbers.forEach((num) => {
      sum += num;
    });
    sum === 15;
Which is... ridiculous. None of this is actually immutable, as "sum" is constantly being modified. A real FP purist would be using "reduce" in the "good" example. Otherwise, forEach is not better than for-of in terms of readability or maintainability in any way.

In addition, I think an issue is that for a long time, when you use ESLint CLI to create a new config file, airbnb is the default option, which ends up making it used very widely, even after the config itself is in maintenance mode. They were only removed in 2024: https://github.com/eslint/create-config/pull/108
2 comments
mattacular 163 days ago
Their rationale is written here, May 21 2021 final comment on the closed issue from the creator themself. Even in 2021 this was a dubious argument to make given the browser landscape, and they are clearly just frustrated to be challenged on this topic. They think legacy browsers are forever and furthermore readability of .forEach() is better anyway:

> in the latest version of all browsers. Despite marketing, no browsers are "evergreen" according to the google analytics of major websites I've been able to review over the last couple years. (Nothing but safari will likely ever support PTC - which is not an optimization - so that's not really relevant to discuss) Performance isn't important, readability is.

ref: https://github.com/airbnb/javascript/issues/1122#issuecommen...

link
tracker1 163 days ago
In the specific example, both have side effects... if you really wanted to avoid them, you'd use .reduce, and even then, depends on the amount of data. More often than not, if you're doing these kinds of things in JS on in-memory data, you're probably doing something wrong and have bigger concerns imo.

I say this as someone who loves JS since before The Good Parts book.

link