Skip to content

Instantly share code, notes, and snippets.

View stifflerus's full-sized avatar
🖥️
Happily Hacking

Robert Stiffler stifflerus

🖥️
Happily Hacking
View GitHub Profile
@stifflerus
stifflerus / cloudSettings
Last active April 29, 2019 19:52
Visual Studio Code Settings Sync Gist
{"lastUpload":"2019-04-29T19:52:15.905Z","extensionVersion":"v3.2.9"}
@VictorTaelin
VictorTaelin / promise_monad.md
Last active May 10, 2024 04:22
async/await is just the do-notation of the Promise monad

async/await is just the do-notation of the Promise monad

CertSimple just wrote a blog post arguing ES2017's async/await was the best thing to happen with JavaScript. I wholeheartedly agree.

In short, one of the (few?) good things about JavaScript used to be how well it handled asynchronous requests. This was mostly thanks to its Scheme-inherited implementation of functions and closures. That, though, was also one of its worst faults, because it led to the "callback hell", an seemingly unavoidable pattern that made highly asynchronous JS code almost unreadable. Many solutions attempted to solve that, but most failed. Promises almost did it, but failed too. Finally, async/await is here and, combined with Promises, it solves the problem for good. On this post, I'll explain why that is the case and trace a link between promises, async/await, the do-notation and monads.

First, let's illustrate the 3 styles by implementing

/* VT100 terminal reset (<ESC>c) */
console.log('\033c');
/* numbers comparations */
> '2' == 2
true
> '2' === 2