Why couldn't popular JavaScript runtimes handle synchronous-looking asynchronous script?

Question

As cowboy says down in the comments here, we all want to \"write [non-blocking JavaScript] asynchronous code in a style similar to this:

 try 
 {
    var foo         


        

Answer 1

Because Javascript interpreters are single-threaded, event driven. This is how the initial language was developed.

You can't do "use noblock" because no other work can occur during that phase. This means your UI will not update. You cannot respond to mouse or other input event from the user. You cannot redraw the screen. Nothing.

So you want to know why? Because javascript can cause the display to change. If you were able to do both simultaneously you'd have all these horrible race conditions with your code and the display. You might think you've moved something on the screen, but it hasn't drawn, or it drew and you moved it after it drew and now it's gotta draw again, etc. This asynchronous nature allows, for any given event in the execution stack to have a known good state -- nothing is going to modify the data that is being used while this is being executed.

That is not to say what you want doesn't exist, in some form.

The async library allows you to do things like your parallel idea (amongst others).

Generators/async/wait will allow you to write code that LOOKS like what you want (although it'll be asynchronous by nature).

Although you are making a false claim here -- humans are NOT bad at writing asynchronous code.