DEV Community

Discussion on: Refactoring node.js (Part 1)

Collapse
 
avalander profile image
Avalander • Edited

We could discuss all day long the merits of the second article you linked. For instance, I find it interesting that they conclude that async/await outperforms hand-written code promise when the graph right above that sentence shows that async/await runs faster only in one of the two benchmarks, or how relevant it is for real applications that some arbitrary code runs about 5ms faster than some other arbitrary code.

However, I'm not interested in discussing performance because it's not the point you made in the article, it's not the point I was debating, and promises vs async/await is rarely where the performance bottleneck will be in any real world project.

Going back to the topic of readability, I think we should acknowledge that it is a somewhat subjective matter, and some decisions are going to be more a matter of personal style than one option being clearly superior to the other. I think async/await vs promises is one of those instances.

I've written a lot of asynchronous code in many different styles and contexts. Among others, I've written Javascript code with callbacks, promises and async/await; Python both with its async/await and before that was added to the language; and Java 1.7 with its blocking thread execution until asynchronous operations finish. And I don't see Javascript's async/await being a substantial improvement over promises in the same way that promises and async/await are an improvement over callbacks.

As I said, promises fit the declarative functional paradigm quite good. If your mental model is a pipe of transformations through which the data flows from a given input to the desired output, a promise chain matches that model quite well, and you'll find easier to reason about code written in that style.

On the other hand, async/await is better if you are writing imperative code. If your mental model is a series of steps that need to be performed, then it will be easier to reason about steps that need to be awaited than functions that will be executed at an arbitrary point in the future.

Thus, I think async/await is a horizontal evolution over promises that fills an entirely different niche, for which Javascript didn't have any good solution yet.

Thread Thread
 
paulasantamaria profile image
Paula Santamaría • Edited

I agree, we would discuss all day. If you won't even consider an article written by the people behind the javascript engine inside node.js, I don't think I can come up with a better/more reliable resource.

It's true that readability is subjective, and that's why I try to ignore my own biases and follow recommendations from the leaders of the industry that I also take into account when writing my articles.

The idea behind this article is merely to provide the readers with tips and tools that worked for me to write clean and efficient node.js code, and that are based on official documentation and reliable resources.

Like I said, it's perfectly ok if you still prefer promises.

Thread Thread
 
savagepixie profile image
SavagePixie • Edited

If you won't even consider an article written by the people behind the javascript engine inside node.js, I don't think I can come up with a better/more reliable resource.

You do realise that Avalander has considered said article, right? They are saying two things about it: 1) its conclusions are dubious and 2) it doesn't really address your point or their objection to it. If this doesn't show that they've considered it, I don't know what does.

The point Avalander is contesting is this claim:

Isn't it cleaner and easier to read with async/await?

To which I am afraid I must side with Avalander and say that neither you nor your sources have provided good support for it. async/await reads differently than promises. But that's just it. Not cleaner, nor better, just different.

And I am going to discuss the second source you mention. Particularly the sentence you quoted:

With async functions, the code becomes more succinct, and the control and data flow are a lot easier to follow, despite the fact that the execution is still asynchronous.

I can't help but notice that they write that just below an example where they've rewritten promise syntax to async/await using two fewer lines of code (one of which is merely a )};) and making two other lines twice as long. Specifically, while the promise syntax uses 168 characters, the async/await syntax uses 181. That's 13 extra characters for the supposedly more succint code of async/await. Even if it were 5 characters less, that'd be dubious evidence on which to ground the claim that async/await is more succinct, simply because it's only one example with too small a difference to draw any conclusions.

By the way, I'm not saying that promise syntax is better than async/await. All I'm saying is that I find the claim that async/await is better or clearer wanting.

Thread Thread
 
paulasantamaria profile image
Paula Santamaría

We concluded earlier than readability is subjective, so I don't think it makes any sense to keep arguing about what you find best.

My point is simply this: We can all have our opinions and preferences but, in the interest of objectiveness, I believe the best we can do is follow reliable sources. Unless you have the time to explore the matter in depth and write your own article with your own conclusions.

Both links I've shared on this thread I consider to be reliable and present async/await as an improvement to writing asynchronous code in javascript. And there are many other sources that explore this statement in depth and conclude the same thing. This article was not meant to list the pros and cons of async/await but merely to share tools that worked for me and that are supported by documentation written by people far more experienced than me in the subject.

Here's another article from this very platform that explores the subject more in depth.