Away/async vs Promises

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

Recently I have received a course on Angular 2 and ECMAScript 6 and I have decided to have a look at 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 technology 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 is short-lived but feature cutting-edge capabilities

Notable Changes :

• 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 top 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 = () =>
  getJSON()
    .then(data => {
      console.log(data)
      return "done"
    })

makeRequest()

Here is the equivalent using the new instructions :

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

makeRequest()

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

• Concise and clean: the instruction is removing a lot of boilerplate code. I rather agree with that analysis. This instruction is easier to understand for sequential programmers (Java ugh). We are invocating an asynchronous request, grab the result, and return it like a variable. However, I am not fond of the syntactic 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 for braces and composition. Everything is written almost like a trivial sequential code. It’s indeed clear progress for 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 do not print the whole event sequence that has produced the value.
• Debugging: Code will be easier to debug with smaller stack traces and you can breakpoint on the await instructions.

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

However, one of the big reproaches I have done on Node.JS 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 maintainability? Most of our daily algorithms are not expressed with asynchronous programming. Some Users are still dealing with the parsing of an XML document with a DOM parser and not a SAX one. Why? It’s simpler to use and to manipulate.