4 ms·

It's lovely how node.js started with callback nesting hell, then to promise chaining, then to async/await, then to "magic" libraries like this. How long since

It's lovely how node.js started with callback nesting hell, then to promise chaining, then to async/await, then to "magic" libraries like this. How long since someone will figure out how to get rid of the (error-prone) await keyword, and go back full circle on plain old synchronous-style syntax?

woah 8y ago
This library has some very minor syntax sugar. Async/await is currently the most ergonomic abstraction for handling single-thread concurrency.
- WorldMaker 8y ago
  Also, the examples here aren't as "unergonomic" as the article suggests with async/await. const lines = await fetch(...).then(res => res.text()).then(res => res.split('\n')) Any use of .then in async/await is a code smell. The obvious single line refactor (as presented in other threads): const lines = (await (await fetch(url)).text()).split('\n') But a clearer refactor is simply multiple lines to make each "step" clear as mud: const response = await fetch(url) const text = await response.text() const lines = text.split('\n') Yes, it's a bit over-verbose than the one liner, but ergonomically it is step-by-step imperative programming just like Grandma C++ used to bake, and few would argue that it isn't readable old-fashioned ergonomics. Promise.all is a tougher thing to get "ergonomics" from, but more often than not, a refactor to a "classic" for loop pattern is often clearer. The semantics change, unfortunately, yet more often than not the clearer "one-thing-at-a-time" of the simpler refactor is easier to debug, less harsh on called services, less pressure on client memory, and simpler to progress report. Instead of: const responses = await Promise.all(urls.map(url => fetch(url)) const texts = await Promise.all(responses.map(response => response.text()) for (let text of texts) { doSomething(text) } Try: for (let url of urls) { const response = await fetch(url) const text = await response.text() doSomething(text) } Again, the semantics change: instead of waiting for all of them to complete as massively parallel it operates a bit more "synchronously" one at a time. But the benefits again are that ergonomically it is much clearer what each individual step is, how much work has been done, roughly how much work is left to do. Additionally, you aren't creating a massive array of the text of every response before operating on each text, which can be a big deal for performance memory pressure. More often than not, I've seen cases where the simpler for (let of)/await pattern here is more performant than all the parallel calls simply because of the drop in this memory pressure. For cases where you do need more of the parallelism, ESNext AsyncIterable is a better plan than Promise.all(), and affords the for-await pattern: for await (let response of responsePromiseIterator) { const text = await response.text() doSomething(text) } Which again, is more ergonomic overall, often easier to get the performance right than Promise.all(), and easy enough to change to different parallel strategies because the code stays the same regardless of the scheduler used to build your async iterator.
scottmf 8y ago
You might find this library interesting https://github.com/scf4/callbaxx https://github.com/scf4/callbaxx

woah 8y ago

This library has some very minor syntax sugar. Async/await is currently the most ergonomic abstraction for handling single-thread concurrency.

WorldMaker 8y ago
Also, the examples here aren't as "unergonomic" as the article suggests with async/await. const lines = await fetch(...).then(res => res.text()).then(res => res.split('\n')) Any use of .then in async/await is a code smell. The obvious single line refactor (as presented in other threads): const lines = (await (await fetch(url)).text()).split('\n') But a clearer refactor is simply multiple lines to make each "step" clear as mud: const response = await fetch(url) const text = await response.text() const lines = text.split('\n') Yes, it's a bit over-verbose than the one liner, but ergonomically it is step-by-step imperative programming just like Grandma C++ used to bake, and few would argue that it isn't readable old-fashioned ergonomics. Promise.all is a tougher thing to get "ergonomics" from, but more often than not, a refactor to a "classic" for loop pattern is often clearer. The semantics change, unfortunately, yet more often than not the clearer "one-thing-at-a-time" of the simpler refactor is easier to debug, less harsh on called services, less pressure on client memory, and simpler to progress report. Instead of: const responses = await Promise.all(urls.map(url => fetch(url)) const texts = await Promise.all(responses.map(response => response.text()) for (let text of texts) { doSomething(text) } Try: for (let url of urls) { const response = await fetch(url) const text = await response.text() doSomething(text) } Again, the semantics change: instead of waiting for all of them to complete as massively parallel it operates a bit more "synchronously" one at a time. But the benefits again are that ergonomically it is much clearer what each individual step is, how much work has been done, roughly how much work is left to do. Additionally, you aren't creating a massive array of the text of every response before operating on each text, which can be a big deal for performance memory pressure. More often than not, I've seen cases where the simpler for (let of)/await pattern here is more performant than all the parallel calls simply because of the drop in this memory pressure. For cases where you do need more of the parallelism, ESNext AsyncIterable is a better plan than Promise.all(), and affords the for-await pattern: for await (let response of responsePromiseIterator) { const text = await response.text() doSomething(text) } Which again, is more ergonomic overall, often easier to get the performance right than Promise.all(), and easy enough to change to different parallel strategies because the code stays the same regardless of the scheduler used to build your async iterator.

scottmf 8y ago

You might find this library interesting https://github.com/scf4/callbaxx https://github.com/scf4/callbaxx