6 ms·

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

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?

ledriveby 9y ago
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.
- masswerk 9y ago
  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); }; }
  - masswerk 9y ago
    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.) :-)
- marcosdumay 9y ago
  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.
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
  - rmrfrmrf 9y ago
    Do you, as a user, want web pages to spawn multiple threads on your machine?
    - marcosdumay 9y ago
      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?
ckocagil 9y ago
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 http://tinyclouds.org/jsconf.pdf

ledriveby 9y ago

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.

masswerk 9y ago
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); }; }
- masswerk 9y ago
  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.) :-)
marcosdumay 9y ago
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.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- rmrfrmrf 9y ago
  Do you, as a user, want web pages to spawn multiple threads on your machine?
  - marcosdumay 9y ago
    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?

ckocagil 9y ago

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 http://tinyclouds.org/jsconf.pdf