THE EVOLUTION OF
ASYNCHRONOUS
JAVASCRIPT
@cirpo

now & later
ASYNCRONY

the core of asynchronous programming
is the relationship between
the now and later parts of your program
ASYNCRONY

how to express, manage and
manipulate
program behaviours
over a period of time?

CONCURRENCY

CONCURRENCY
a way to structure a program
by breaking it into pieces
that can be executed independently

IS JS CONCURRENT?

A JS runtime contains a message queue, which
is a list of messages to be processed.
To each message is associated a function.
When the stack is empty, a message is taken
out of the queue and processed.
QUEUE

function f(b){
var a = 12;
return a+b+35;
}
function g(x){
var m = 4;
return f(m*x);
}
g(21);
STACK

function f(b){
var a = 12;
return a+b+35;
}
function g(x){
var m = 4;
return f(m*x);
}
g(21);
1 foo gets called
STACK

function f(b){
var a = 12;
return a+b+35;
}
function g(x){
var m = 4;
return f(m*x);
}
g(21);
2 first frame is created containing foo
and local variable
1 foo gets called
STACK

function f(b){
var a = 12;
return a+b+35;
}
function g(x){
var m = 4;
return f(m*x);
}
g(21);
2 first frame is created containing foo
and local variable
1 foo gets called
3 when foo calls bar, a second frame
is push on top of foo, containing bar
arguments and local variables
STACK

function f(b){
var a = 12;
return a+b+35;
}
function g(x){
var m = 4;
return f(m*x);
}
g(21);
4 when bar returns, the top frame
element is popped out of the stack
(leaving only foo call frame)
STACK

function f(b){
var a = 12;
return a+b+35;
}
function g(x){
var m = 4;
return f(m*x);
}
g(21);
5 When foo returns, the stack is empty
4 when bar returns, the top frame
element is popped out of the stack
(leaving only foo call frame)
STACK

EVENT LOOP

JS IS NON BLOCKING

events
eventloop
net
filesystem
…
event queue thread pool

JS unlike a lot of other languages, never blocks
Handling I/O is typically performed via events and callbacks
When the application is waiting for an IndexedDB query to return
or an XHR request to return, it can still process other things like
user input
JS IS NON BLOCKING

Node.js is great for Input/Output processing
but not optimised for CPU-bound work like
performing a large amount of calculations.
JS IS NON BLOCKING

Up until recently (ES6), JS itself has actually
never had any direct notion of asynchrony
built into it

JS runs inside a hosting environment (the
browser/nodejs)
The event loop is handled by it

IS JS CONCURRENT?

goroutinesprocesses

IS JS CONCURRENT?

JS IS SINGLE THREAD

SORT OF …

BUT THE HOSTING
ENVIRONMENT CAN USE
MULTI THREAD
FOR I/O OPERATIONS

most devs new to JS have issues with the fact
that later doesn’t happen strictly and
immediately after now
ASYNCRONY

tasks that cannot complete now are, by definition,
going to complete asynchronously
and thus no blocking behaviour as it might intuitively
expect or want.
ASYNCRONY

ASYNCRONY

ASYNC IS GREAT

BUT CAN BE HARD

SEQUENTIAL BRAIN

SEQUENTIAL BRAIN
put aside involuntary, subconscious, automatic
brain functions
we are not multitasker

SEQUENTIAL BRAIN
As soon as we introduce a single continuation
in the form of a callback function, we have
allowed a divergence to form between how our
brains work and the way the code will operate

can we do that?

yes… but we are blocking

WHEN YOU BLOCK,
YOU “PULL” A VALUE

CALLBACK

PIRAMID OF DOOM!

CALLBACK HELL!

BULLSHIT

HOW TO AVOID POD

HOW TO AVOID POD

ASYNC CALLBACK

ASYNC CALLBACK
=

ASYNC CALLBACK
PUSH
=

LOSS OF CONTROL
FLOW

LOSS OF ERROR
HANDLING

INVERSION
OF
CONTROL

“Don't call us, we'll call you”

INVERSION OF CONTROL

INVERSION OF CONTROL
what if it’s a third party call
not under our control?

INVERSION OF CONTROL

INVERSION OF CONTROL
what if it’s never called?

INVERSION OF CONTROL
what if it’s never called?
what if it’s called too early?

INVERSION OF CONTROL
what if it’s never called?
what if it’s called too early?
what if it’s called too late?

meh.

HOW CAN YOU TELL IF
IT’S AN
ASYNC CALL?

meh.

Callbacks are the fundamental unit of
asynchrony in JS.
But they’re not enough for the evolving
landscape of async programming as JS
matures.
I <3 callbacks

PROMISES

PROMISES
It allows you to associate handlers to an
asynchronous action's eventual success value or
failure reason.
This lets asynchronous methods return values like
synchronous methods: instead of the final value,
the asynchronous method returns a promise.
A promise represents a proxy for a value not
necessarily known when the promise is created.

PROMISES
http://ecma-international.org/ecma-262/6.0/#sec-jobs-and-job-queues

PROMISES
Promises are now the official way to provide async
return values in both JavaScript and the DOM.
All future async DOM APIs will use them, and
many already do, so be prepared!

PROMISES
pending: initial state, not fulfilled or rejected
fulfilled: the operation completed successfully
rejected: meaning that the operation failed.

PROMISES
always async
returns a promise
handled once
thenable

PROMISES
A promise must provide a then method to
access its current or eventual value or rejection
reason
.then()

PROMISES
.then(onFulfilled,
onRejected)

PROMISES
can return a promise
.then()

PROMISES
.then()
.then()
.then()

PROMISES
.catch()

Talk is cheap,
show me the code

PROMISES

PROMISES

PROMISES
inversion of control
async or sync?
error handling
control flow

WIN!

BUT …

PROMISE HELL!

AVOID PROMISE HELL!

AVOID PROMISE HELL!

DON’T USE PROMISES
FOR CONTROL FLOW

YOUR CODEBASE THEN
BECOMES
PROMISE DEPENDANT

USING PROMISES
EVERYWHERE
IMPACTS ON THE
DESIGN

TO PROMISE OR TO
CALLBACK?

IF YOU HAVE A
LIBRARY, SUPPORT BOTH

SINGLE VALUE

SINGLE RESOLUTION
BAD FOR STREAMS

SINGLE RESOLUTION

PERFORMANCES

PERFORMANCES
Promises are slower compared to callbacks
You don’t get rid of callbacks, they just orchestrate callbacks
in a trustable way

PERFORMANCES
Promises are slower compared to callbacks
You don’t get rid of callbacks, they just orchestrate callbacks
in a trustable way99.9% of the time you
won’t feel it

PROMISES

WHAT IF WAITING WERE
JUST AS EASY AS
BLOCKING?

GENERATORS

GENERATORS
A new type of function that does’t not behave with
the run-to-completion behaviour

GENERATORS

GENERATORS
1 constructing the iterator, not executing

GENERATORS
1 constructing the iterator, not executing
2 starts the iterator

GENERATORS
1 constructing the iterator, not executing
2 starts the iterator
3 pause the iterator

GENERATORS
1 constructing the iterator, not executing
2 starts the iterator
4 resume the iterator
3 pause the iterator

GENERATORS
1 constructing the iterator, not executing
2 starts the iterator
4 resume the iterator
3 pause the iterator

GENERATORS
with the yield where are pausing

GENERATORS
A.K.A
BLOCKING!
with the yield where are pausing

GENERATORS

GENERATORS
iterator is just one side…

GENERATORS
the other side is an observable

GENERATORS

GENERATORS

GENERATORS

GENERATORS

GENERATORS

we can block!
we can pull values
we can push values
GENERATORS

GENERATORS
+
PROMISES

the iterator should listen for the promise to
resolve
then either resume the generator with the
fulfilment message (or throw an error into the
generator with the rejection reason)
GENERATORS + PROMISES

GENERATORS + PROMISES

GENERATORS + PROMISES

GENERATORS + PROMISES

GENERATORS + PROMISES
npm install co

BUT…

ES7
ES2016
to the rescue!

async/await

async/await

npm install -g babel-cli
babel a.es6 -o a.js
node a.js
//add it either to .babelrc or package.json
{
"plugins": ["transform-async-to-generator"]
}
npm install babel-plugin-transform-async-to-generator

STREAMS

callbacks
async/await

CHOOSE YOUR
CONCURRENCY MODEL

A big thanks to
Kyle Simpson (@getify)
github.com/getify/You-Dont-Know-JS

@federicogalassi
@unlucio
… and my mentors
slideshare.net/fgalassi
slideshare.net/unlucio

@loige
@mariocasciaro
youtube.com/watch?v=lil4YCCXRYc

@cirpo
Dev lead at
github.com/cirpo
http://sainsburys.jobs

THANK YOU!