Thank you for your comment. You are correct, sometimes async operations need to be done in a given order. The point I am looking to make in the article is to use catch blocks when the behavior of Promise.all rejecting immediately upon any of the input promises rejecting is not desired.
I think you're still making incorrect claims about parallelism.
Now the entire loop will be as slow as its slowest operation, in our case this is ~1 second, 5.5x faster!
No, the entire loop will be at least as slow as the sum of all of its operations.
It's just that in this particularly contrived example, the operations don't do any work -- they just sit around doing nothing for a while -- so this is all dead-time.
The dead-time can be 'parallelized' because no work occurs, but the over-all story you're making in the article seems very misleading to me.
Some people disable this rule, not because they need to run operations in order, but because they don't know how to disable the fail fast behavior of Promise.all as explained at the end of this page: developer.mozilla.org/en-US/docs/W... under "Promise.all fail-fast behaviour".
Apparently I am not doing a good job at explaining it, thanks for the feedback, I've made some tweaks based on your observations.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you for your comment. You are correct, sometimes async operations need to be done in a given order. The point I am looking to make in the article is to use catch blocks when the behavior of Promise.all rejecting immediately upon any of the input promises rejecting is not desired.
I think you're still making incorrect claims about parallelism.
No, the entire loop will be at least as slow as the sum of all of its operations.
It's just that in this particularly contrived example, the operations don't do any work -- they just sit around doing nothing for a while -- so this is all dead-time.
The dead-time can be 'parallelized' because no work occurs, but the over-all story you're making in the article seems very misleading to me.
The 'contrived example' is to illustrate the purpose of this lint rule: eslint.org/docs/rules/no-await-in-...
Some people disable this rule, not because they need to run operations in order, but because they don't know how to disable the fail fast behavior of Promise.all as explained at the end of this page: developer.mozilla.org/en-US/docs/W... under "Promise.all fail-fast behaviour".
Apparently I am not doing a good job at explaining it, thanks for the feedback, I've made some tweaks based on your observations.