4 ms·

I did, until I used them enough where I saw where they were useful. The bad examples of arrow functions I saw initially were of: 1. Devs trying to mix them in

I did, until I used them enough where I saw where they were useful. The bad examples of arrow functions I saw initially were of: 1. Devs trying to mix them in with OOP code as a bandaid over OOP headahes (e.g. bind/this) instead of just not using OOP in the first place. 2. Devs trying to stick functional programming everywhere because they had seen a trivial example where a `.map()` made more semantic sense than a for/for-in/for-of loop. Despite the fact that for/for-in/for-of loops were easier to read for anything non-trivial and also had better performance because you had access to the `break`, `continue` and `return` keywords.

mewpmewp2 2y ago
Another benefit of using for instead of array fns is that it is easy to add await keyword should the fn become async. But many teams will have it as a rule to always use array fns.
- jappgar 2y ago
  That gives you have the option of making it serially async but not parallel, which can be achieved easily using Promise.all in either scenario.
  - adregan 2y ago
    As an aside: It’s way less ergonomic, but you likely want `Promise.allSettled` rather than `Promise.all` as the first promise that throws aborts the rest.
    - wruza 2y ago
      It doesn’t really abort the rest, it just prioritizes the selection of a first catch-path as a current continuation. The rest is still thenable, and there’s no “abort promise” operation in general. There are abort signals, but it’s up to an async process to accept a signal and decide when/whether to check it.
      - adregan 2y ago
        Admittedly, I was being a bit hand-wavy and describing a bit more of how it feels rather than the way it is (I'm perpetually annoyed that promises can't be cancelled), but I was thinking of the code I've seen many times across many code bases: let results; try { results = await Promise.all(vals.map(someAsyncOp)) } catch (err) { console.error(err) } While you could pull that promises mapping into a variable and keep it thenable, 99% of the time I see the above instead. Promises have some rough edges because they are stateful, so I think it might be easier to recommend swapping that Promise.all for an Promise.allSettled, and using a shared utility for parsing the promise result. I consider this issue akin to the relationship between `sort`, `reverse`, `splice`, the mutating operation APIs, and their non mutating counterparts `toSorted`, `toReversed`, `toSpliced`. Promise.all is kind of the mutating version of allSettled.
throwaway2037 2y ago
> also had better performance because you had access to the `break`, `continue` and `return` keywords. This is a great point. One more: Debugging `.map()` is also much harder than a for loop.
- medstrom 2y ago
  I feel there are a few ways to invoke .map() in a readable way and many ways that make the code flow needlessly indirect. Should be a judgment call, and the author needs to be used to doing both looping and mapping constructs, so that they are unafraid of the bit of extra typing needed for the loop.

mewpmewp2 2y ago

Another benefit of using for instead of array fns is that it is easy to add await keyword should the fn become async. But many teams will have it as a rule to always use array fns.

jappgar 2y ago
That gives you have the option of making it serially async but not parallel, which can be achieved easily using Promise.all in either scenario.
- adregan 2y ago
  As an aside: It’s way less ergonomic, but you likely want `Promise.allSettled` rather than `Promise.all` as the first promise that throws aborts the rest.
  - wruza 2y ago
    It doesn’t really abort the rest, it just prioritizes the selection of a first catch-path as a current continuation. The rest is still thenable, and there’s no “abort promise” operation in general. There are abort signals, but it’s up to an async process to accept a signal and decide when/whether to check it.
    - adregan 2y ago
      Admittedly, I was being a bit hand-wavy and describing a bit more of how it feels rather than the way it is (I'm perpetually annoyed that promises can't be cancelled), but I was thinking of the code I've seen many times across many code bases: let results; try { results = await Promise.all(vals.map(someAsyncOp)) } catch (err) { console.error(err) } While you could pull that promises mapping into a variable and keep it thenable, 99% of the time I see the above instead. Promises have some rough edges because they are stateful, so I think it might be easier to recommend swapping that Promise.all for an Promise.allSettled, and using a shared utility for parsing the promise result. I consider this issue akin to the relationship between `sort`, `reverse`, `splice`, the mutating operation APIs, and their non mutating counterparts `toSorted`, `toReversed`, `toSpliced`. Promise.all is kind of the mutating version of allSettled.

throwaway2037 2y ago

> also had better performance because you had access to the `break`, `continue` and `return` keywords. This is a great point. One more: Debugging `.map()` is also much harder than a for loop.

medstrom 2y ago
I feel there are a few ways to invoke .map() in a readable way and many ways that make the code flow needlessly indirect. Should be a judgment call, and the author needs to be used to doing both looping and mapping constructs, so that they are unafraid of the bit of extra typing needed for the loop.