I know what you're saying, but when it comes time to do "real work", a grand majority of things rely on reading or persisting something before being able to continue on. It's an extremely rare circumstance where taking advantage of having a long running process do it's thing in a separate parallel whiel executing a bunch of other things that don't require it.
Yes, sending an email, you don't need to wait for a response for that. Cool. What else? It's one of the very few "fire and forget" things you can do like collecting analytical data.
One example I can think of, is generating a series of graphs for a page that shows off analytical data. You could spin off the collection of each graphs data into separate threads, and eventually come down to either a Promise.all to tie it all together, or just let each thread independently update the data on the shared main thread state.
But generally speaking? Things are pretty damn sequential. If it werent, we wouldn't have had "callback hell" at all in the first place. Longer running routines are usually doing data manipulation, and usually you can't do anything else until the data is ready to be read.
There's a reason "blocking languages" like PHP had been king for so damn long, it's really good at understanding how on the server side things work.
Client side is a very different beast where many different things can be happening all over the place in parallel. But the server of the web has only one real understanding: a tcp socket has been opened that sends a stateless Request to the server to be parsed, and a Response to send back out through the socket, and close it.
The only time this is different, is if we're taking advantage of manual WebSockets to deal with very different kinds of work, but even still, you're probably going to be waiting to take in the payload, parse the final payload, and basically just execute whatever subroutine you need like any HTTP request, wait for it to complete and then send it back out the socket.
The async / await stuff doesn't need to be on everything, agreed, but with it here, it sure makes this whole process 99% less painful to pick up a project again after months of not seeing it.
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.
I know what you're saying, but when it comes time to do "real work", a grand majority of things rely on reading or persisting something before being able to continue on. It's an extremely rare circumstance where taking advantage of having a long running process do it's thing in a separate parallel whiel executing a bunch of other things that don't require it.
Yes, sending an email, you don't need to wait for a response for that. Cool. What else? It's one of the very few "fire and forget" things you can do like collecting analytical data.
One example I can think of, is generating a series of graphs for a page that shows off analytical data. You could spin off the collection of each graphs data into separate threads, and eventually come down to either a Promise.all to tie it all together, or just let each thread independently update the data on the shared main thread state.
But generally speaking? Things are pretty damn sequential. If it werent, we wouldn't have had "callback hell" at all in the first place. Longer running routines are usually doing data manipulation, and usually you can't do anything else until the data is ready to be read.
There's a reason "blocking languages" like PHP had been king for so damn long, it's really good at understanding how on the server side things work.
Client side is a very different beast where many different things can be happening all over the place in parallel. But the server of the web has only one real understanding: a tcp socket has been opened that sends a stateless Request to the server to be parsed, and a Response to send back out through the socket, and close it.
The only time this is different, is if we're taking advantage of manual WebSockets to deal with very different kinds of work, but even still, you're probably going to be waiting to take in the payload, parse the final payload, and basically just execute whatever subroutine you need like any HTTP request, wait for it to complete and then send it back out the socket.
The async / await stuff doesn't need to be on everything, agreed, but with it here, it sure makes this whole process 99% less painful to pick up a project again after months of not seeing it.