Hacker News Reader

Comment by throw401 | Hacker News Reader

The problem with async await is that it is build upon promises, which sucked already from the start.

For all those Promises proponents out there ready to burn me down, this is how you do it in C:

  delay(1000);

And here the amazing Promises with await:

  var wait = ms => new Promise((r, j)=> setTimeout(r, ms));
  await wait(1000);

Is it really that difficult to at least abstract this wait function away in the Javascript language?

View on HN

Yes it is. Synchronous calls monopolize the event loop so everything - including page interactions - freeze until the control flow finishes busy-waiting. Yay, single threading.

On the other hand, well-known constructs as used for translating FORTRAN labels to switch statements have been around for ages. E.g.,

  function main(entrypoint) {
    switch (entrypoint) {
      default:
      case 0:
        // do some (...)
        // now drop the thread and wait for input (external)
        myInputFunc(function(result) { main(1, result); });
        break;
      case 1:
        // return to here from input
        var value = arguments[1];
        // now do something with it ...
        break;
    }
  }
  
  function myInputFunc(callback) {
    // in actuality this might be servicing a more complex UI
    document.querySelector('#inputField').oninput =
      function() { callback(this.value); };
  }

This way we were porting former terminal services to web applications back in the last century ...

(Maybe requesting additional server data by what would be called padded JSON nowadays via a hidden frame, because no AJAX. And, maybe, we would have rather used global vars for control than anonymous functions, but this another story.)

:-)

Everybody solves that by having multiple threads (either at the OS or runtime level), so you can run in parallel the stuff that don't conflict with each other.

Do you, as a user, want web pages to spawn multiple threads on your machine?

Well, first, you are completely ignoring the possibility of runtime threads.

Also, why not? Do you see any problem with that? As long as their numbers are limited, I don't see any problem?

Promises do not suck at all. They save us from the callback hell. Never treat JavaScript as if it's C, they have fundamental differences.

The biggest difference is that JS is designed to run in an event loop inside a single thread. If you perform a 10 second blocking I/O your thread will freeze. You don't want your browser/tab to be unresponsive. Or in the case of a web server you want to accept incoming TCP connections as fast as you can.

You can achieve parallelism with threads but it's very tricky to scale. If you want a simpler, threaded, blocking programming model I suggest you take a look at Go.

Edit: Definitely read the original slides from Ryan Dahl's JSConf 2009 presentation, they perfectly explain the point of using JS: http://tinyclouds.org/jsconf.pdf

Reply on news.ycombinator.com