Spot on, I was about to write exactly this as a comment ... if you write the code not in a "nested" way but in a "chained" way (and with only one catch block, not two) then the resulting code looks surprisingly similar to ... the async await style code!
The way the code was written in the article mimics more the old "callback hell" style with its deep nesting. The point of promises is exactly that you can get rid of that.
You can argue that async/await is still marginally easier to read than promises but the difference is minor.
Where async/await really gets simpler is if you have loops and conditions. But there you need to watch out - a loop with async calls is not the same as Promises.all(), there are situations where you still may want to use the latter!
In other words, aync/await is great but you should still understand Promises as well (which is the foundation that async/await is built on).
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.
Spot on, I was about to write exactly this as a comment ... if you write the code not in a "nested" way but in a "chained" way (and with only one catch block, not two) then the resulting code looks surprisingly similar to ... the async await style code!
The way the code was written in the article mimics more the old "callback hell" style with its deep nesting. The point of promises is exactly that you can get rid of that.
You can argue that async/await is still marginally easier to read than promises but the difference is minor.
Where async/await really gets simpler is if you have loops and conditions. But there you need to watch out - a loop with async calls is not the same as Promises.all(), there are situations where you still may want to use the latter!
In other words, aync/await is great but you should still understand Promises as well (which is the foundation that async/await is built on).