Today I have felt on an interesting article about Javascript promises and the new functionality of async/.

Recently I have received a course on Angular 2 and Ecmascript 6 and I have decided to have a look on it.

The original article is there.

Here is a summary of that article.

Node  now supports async/await out of the box since version 7.6. This is quite cool to build cheap and effective backends offering REST apis.

Node 7.6 is offering several new features. With Node’s release strategy, odd-numbered releases like the 7.x line are short-lived but feature cutting-edge capabilities

Notable Changes :

  • deps
  • update V8 to 5.5 (Michaël Zasso) #11029
  • upgrade libuv to 1.11.0 (cjihrig) #11094
  • add node-inspect 1.10.4 (Jan Krems) #10187
  • upgrade zlib to 1.2.11 (Sam Roberts) #10980
  • lib: build node inspect into node (Anna Henningsen) #10187
  • crypto: Remove expired certs from CNNIC whitelist (Shigeki Ohtsu) #9469
  • inspector: add –inspect-brk (Josh Gavant) #11149
  • fs: allow WHATWG URL objects as paths (James M Snell) #10739
  • src: support UTF-8 in compiled-in JS files (Ben Noordhuis) #11129
  • url: extend url.format to support WHATWG URL (James M Snell) #10857

(From the article) For those who have never heard of this topic before, here’s a quick intro

Presentation of Async / Await

  • Async/await is a new way to write asynchronous code. Previous options for asynchronous code are callbacks and promises.
  • Async/await is actually built on of promises. It cannot be used with plain callbacks or node callbacks.
  • Async/await is, like promises, non blocking.
  • Async/await makes asynchronous code look and behave a little more like synchronous code. This is where all its power lies.

Here is an example of code using promises :

const makeRequest = () =>
    .then( => {
      return "done"


Here is the equivalent using the new instructions :

const makeRequest = async () => {
  console.log(await getJSON())
  return "done"


According the author, his opinion about this new feature is :

  • Concise and clean: the instruction is removing a lot of boilerplate code. I rather agree on that analysis. This instruction is easier to understand for sequential programmers (Java ugh). We are invocating an asynchronous request, grab the result and returns it like a variable. However I am not a fond of the syntaxic sugar await () that looks like a dirty hack.
  • Error handling: the asynchronous and synchronous exceptions are all treated by a simple try...catch construct. That’s currently less painful than the current system that is also present in RxJS.
  • Conditionals: the instruction decreases the need of braces and composition. Everything is written almost like a trivious sequential code. It’s indeed a clear progress for the maintainability.
  • Intermediate values : the current system of Promises tends to create over-engineered code to use intermediate values between callbacks. The await instruction is clearly the winner for such patterns.
  • Error stacks: Error stacks are cleaner and does not print the whole sequence that has produced the value.
  • Debugging: Code will be easier to debug with smaller stacktraces and you can breakpoint on the await instructions.

I would agree that it makes the asynchronous code less obvious.

However one the big reproach I have done on is that it forces the developer to think in terms of asynchronous programming whenever your code may have a sequential part. How many times, I had to deal with asynchronous constructions without any real benefits in terms of performance or maintenability ? Most of our daily algorithms are not expressed with an asynchronous programming. Some Users are still deadling the parsing of a XML document with a DOM and not a SAX one. Why ? It’s simpler to use and to manipulate.

Related Posts