You can just wait for the network request to finish before continuing. Many actions require it anyway.
Asynchronous code should be intentional and deliberate in my opinion, but in modern JS/Node it is the default which leads to all kinds of crazy workarounds, callback hell and race conditions. Node has the same issue PHP had now, where green devs will crank out code without realising they need to be watching out for these things.
Is it cool that a .forEach loop could be async? Heck yeah, should it be the default? The shit people write around .forEach loops suggests, maybe not!
He still has a point. Go code and similar languages hide the concurrency. You write synchronous looking code most of the time, but underneath, libraries and runtimes ensure you’re running concurrently.
Most libraries are async and some standard lib stuff is unexpectedly async as well, so you are often handling async concerns even if what you're writing is better syncronous.
My team and I don't write callback hell, it's just a very common pitfall and you still see it all the time. You can't bubble wrap everything I suppose.
Everything in JS started with callbacks, then promises came on to the scene with libraries like Bluebird, then the async/await syntax was added to the spec. The language was always able to handle concurrency but it was a long road to the current state.
Asynchronous code should be intentional and deliberate in my opinion, but in modern JS/Node it is the default which leads to all kinds of crazy workarounds, callback hell and race conditions. Node has the same issue PHP had now, where green devs will crank out code without realising they need to be watching out for these things.
Is it cool that a .forEach loop could be async? Heck yeah, should it be the default? The shit people write around .forEach loops suggests, maybe not!