Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript async/await implemented in V8

chromium.googlesource.com

Post reply on HN
Print view View original

211–220 of 227 posts

Re: JavaScript async/await implemented in V8

#211

Post by ben_jones »

esailija wrote: post #108
ben_jones wrote: post #73

Earlier quoted context omitted.

Just to put it out there, an ES6 implementation using async.js would look like async.parallel({ facebook: done => request("https://api.github.com/orgs/facebook", done), twitter: done => request("https://api.github.com/orgs/twitter", done) }, (err, responses) => console.log(err, responses); ); And output something like: null, { facebook: { // facebook data }, twitter: { // twitter data } } Sure it suffers from a third…

This is not the same at all. Any error in any of the callbacks is not catchable with one catch statement (you need separate try catch statement in every one of your callbacks). With async/await and promises, you only need one catch statement or one .catch method in one place because of proper error propagation and composition.

How common are dozens/hundreds of try-catch blocks in javascript code? Developers have long ago stopped caring about uncaught errors because it doesn't matter in the code they are writing, they catch every error they need to and leave the chips to fall where they may.

In the same vein async.js will be catching all errors passed to done(err, response) and in the case of async.series() and similar calls, will stop the execution of concurrent actions as at the first error that is caught.

Therefore I think its completely valid, because even though our examples are different, to most developers it doesn't even matter.

I think you have a completely valid point, and it's probably a better world where we have proper error propagation and composition, just the reality of the situation is what it is.

Re: JavaScript async/await implemented in V8

#213

Post by AgentME »

BinaryIdiot wrote: post #86
AgentME wrote: post #39

Earlier quoted context omitted.

Async/await is just syntax-sugar around Promises. No busy loops involved. (Those generally don't work in Javascript anyway.)

This overlooks Promises needing to be polyfilled. Though that's certainly not using busy loops either (though most of what I've seen overlooks more performant setTimeout(fn, 0) alternatives which is unfortunate).

Async/await already needs to be transpiled in for most browsers, so Promises needing to be polyfilled seems like the least of your problems.

Re: JavaScript async/await implemented in V8

#214

Post by WorldMaker »

z3t4 wrote: post #210
WorldMaker wrote: post #200

Earlier quoted context omitted.

async/await ends up being the less complex thing, my "simple" example is an extreme that sometimes but rarely happens. When was the last time you saw that in synchronous code? It happens, certainly but the synchronous default is to only handle what you can handle and then pass everything else back up the chain. The asynchronous default with async/await is the same, and you can rely on default error propagation in the…

Don't forget that for every await - you or preferably someone else has to write the Promise boilerplate!

promise-ring [1] is all you need for Node style callbacks. (Bluebird and a few other Promise augmenting libraries also have similar tools, but promise-ring is really all you need.)

Eventually, too, Node and Electron and Cordova and everything else will catch up to the fact that Promises are native in ES2015 and the APIs will eventually migrate.

But the thing about it is toi, async functions also return promises, so not every await require "Promise boilerplate", as you will presumably be using other async functions that produce their own promises.

[1] https://github.com/DavidAnson/promise-ring

Re: JavaScript async/await implemented in V8

#215

Post by z3t4 »

brandonbloom wrote: post #26
andrewstuart2 wrote: post #15

I have yet to see a convincing argument that this feature is necessary or even helpful beyond one-liners. The Q promises API, to me, is the right way to reason about asynchrony. Once you understand closures and first class functions, so much about complex asynchronous flows (e.g. multiple concurrent calls via Q.all, multiple "returns" via callback arguments) become so simple. The "tons of libraries" argument doesn't…

Allow me to make both a theoretical and practical argument. It's been said that "callbacks are imperative; promises are functional". It's true. Furthermore, callbacks structure control flow and promises structure data flow. Instruction scheduling is an explicit sequence with callbacks (well, assuming the API calls you back precisely once), but scheduling is an implicit topological sort of the directed acyclic depende…

99.9% of all JavaScript is handling state and events in a user interface (web page). Ex: You have two buttons, and when both of them has been pressed, a image of a cat is displayed.

>> functional event-driven code with contextual closures

This paradigm works very well on the server side too. Ex: A HTTP requests makes a query to a database server, then returns the result to the browser

This gives parallelism without the complexity of threads.

Re: JavaScript async/await implemented in V8

#216

Post by BinaryIdiot »

coldtea wrote: post #149
BinaryIdiot wrote: post #88

Earlier quoted context omitted.

That seems like a mistake to me. That would mean code that runs perfectly under, say, 6.5 would not run on 6.1. It should most certainly be a 7.x release.

For stability one should be using the LTS release. And why would one downgrade from 6.5 to 6.1? If they code for 6.1 and want to not use LTS and to keep 6.1 installations around, then they should not use 6.5 features.

It was simply a hypothetical but surely you can imagine a scenario where you either have to downgrade (perhaps a regression happens) or you simply have to target multiple versions. I've run into both situations multiple times in my career.

Regardless yes you should use LTS but that's no excuse for going against semantic versioning. It should be labeled an alpha or beta if they don't want to change major versions for breaking feature additions.

Re: JavaScript async/await implemented in V8

#217

Post by msoad »

WorldMaker wrote: post #196
msoad wrote: post #116

Earlier quoted context omitted.

Exactly! When you count for nested try/catchs you see no significant improvement

Why would you nest try/catches? At worst you get try/catch parades: try { await thing1() } catch (e) { console.log(e) } try { await thing2() } catch (e) { console.log(e) } // ... and so forth ... That's still nothing like the pyramids you get in callback world.

That won't work because if thing1() throws you usually don't want to process to thing2

Take this for example:

     const response = await fetch('./api.json');
        try {
            const json = await response.json();
            console.log('YAY! JSON!', json);
        } catch (jsonParseError) {
            alert('damn it!');
        }
     } catch(fetchError) {
        console.warn('this is not cool');
     }

Re: JavaScript async/await implemented in V8

#218

Post by esailija »

ben_jones wrote: post #211
esailija wrote: post #108

Earlier quoted context omitted.

This is not the same at all. Any error in any of the callbacks is not catchable with one catch statement (you need separate try catch statement in every one of your callbacks). With async/await and promises, you only need one catch statement or one .catch method in one place because of proper error propagation and composition.

How common are dozens/hundreds of try-catch blocks in javascript code? Developers have long ago stopped caring about uncaught errors because it doesn't matter in the code they are writing, they catch every error they need to and leave the chips to fall where they may. In the same vein async.js will be catching all errors passed to done(err, response) and in the case of async.series() and similar calls, will stop the…

> How common are dozens/hundreds of try-catch blocks in javascript code

Nobody who realized the fragility of async/callbacks and understanding what it takes with them to make at least a passably robust program would stay with async, they would quickly switch to promises/fibers/equivalent or stop using node. Although I have seen projects on github that use try-catch blocks properly with callbacks/async and I have to wonder what made them think that there isn't a better way.

And again, async does not catch any errors, it only forwards error callbacks based on some very loose convention which isn't even honored in core node apis. Just because most node (or rather callback/async) users are clueless about error handling doesn't make the examples equivalent.

Re: JavaScript async/await implemented in V8

#220

Post by coldtea »

BinaryIdiot wrote: post #216
coldtea wrote: post #149

Earlier quoted context omitted.

For stability one should be using the LTS release. And why would one downgrade from 6.5 to 6.1? If they code for 6.1 and want to not use LTS and to keep 6.1 installations around, then they should not use 6.5 features.

It was simply a hypothetical but surely you can imagine a scenario where you either have to downgrade (perhaps a regression happens) or you simply have to target multiple versions. I've run into both situations multiple times in my career. Regardless yes you should use LTS but that's no excuse for going against semantic versioning. It should be labeled an alpha or beta if they don't want to change major versions for…

>It was simply a hypothetical but surely you can imagine a scenario where you either have to downgrade (perhaps a regression happens)

Sure, but if you might have to downgrade, then simply don't write code that depends on 6.5 features. 6.5 can still run 6.1 code (feature wise), so you'll be alright.

The only problem would be for people wanting to a) run 6.5, b) take advantage of newer, 6.5-only features, and THEN c) downgrade to 6.1

Post reply on HN