This document discusses the evolution of asynchronous JavaScript programming. It covers callbacks, promises, generators, and async/await. Callbacks were initially used but led to callback hell. Promises improved the situation by providing a cleaner way to handle asynchronous code but promise hell was still possible. Generators allowed blocking-like code using yield but required promises to handle asynchronous functions. Now async/await in ES2017 allows writing asynchronous code that looks synchronous and resolves many of the past issues. Streams are also mentioned as an alternative concurrency model to callbacks and async code.

1. THE EVOLUTION OF
ASYNCHRONOUS
JAVASCRIPT
@cirpo

2. @cirpo
Dev lead at

6. now & later
ASYNCRONY

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

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

10. CONCURRENCY MODEL
AND
EVENT LOOP

11. stack
queue
heap

12. A JS runtime contains a message queue, which
is a list of messages to be processed.
QUEUE

13. A JS runtime contains a message queue, which
is a list of messages to be processed.
To each message is associated a function.
QUEUE

14. 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

15. EVENT LOOP

16. events
eventloop
net
filesystem
…
event queue thread pool

17. JS IS NON BLOCKING

18. 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

19. 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

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

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

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

24. ASYNCRONY

25. ASYNC IS GREAT

26. BUT CAN BE HARD

27. SEQUENTIAL BRAIN

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

31. can we do that?

32. yes… but we are blocking

33. WHAT IF WAITING WERE
JUST AS EASY AS
BLOCKING?

34. BLOCK

35. BLOCK
=

36. BLOCK
PULL
=

37. WHEN YOU BLOCK,
YOU “PULL” A VALUE

38. BLOCK
PULL
=

39. CALLBACK

44. PIRAMID OF DOOM!

45. CALLBACK HELL!

46. BULLSHIT

47. HOW TO AVOID POD

48. HOW TO AVOID POD

49. ASYNC CALLBACK

50. ASYNC CALLBACK
=

51. ASYNC CALLBACK
PUSH
=

53. ASYNC CALLBACK
PUSH
=

54. LOSS OF CONTROL
FLOW

55. LOSS OF ERROR
HANDLING

57. INVERSION
OF
CONTROL

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

59. INVERSION OF CONTROL

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

61. INVERSION OF CONTROL

62. INVERSION OF CONTROL
what if it’s never called?

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

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

66. meh.

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

70. meh.

71. Callbacks are the fundamental unit of
asynchrony in JS.
I <3 callbacks

72. 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

73. WHAT IF WAITING WERE
JUST AS EASY AS
BLOCKING?

74. PROMISES

75. PROMISES
A promise represents a proxy for a value not
necessarily known when the promise is created.

76. PROMISES
It allows you to associate handlers to an
asynchronous action's eventual success value or
failure reason.
A promise represents a proxy for a value not
necessarily known when the promise is created.

77. 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.

78. PROMISES
always async

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

80. PROMISES
always async
handled once

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

82. PROMISES
always async
handled once
thenable

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

84. PROMISES
.then(function(
onFulfilled,
onRejected)
)

85. PROMISES
always async
handled once
thenable
returns a promise

86. PROMISES
can return a promise
.then()

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

88. PROMISES
.catch()

89. Talk is cheap,
show me the code

90. PROMISES

91. PROMISES

92. PROMISES
control flow

93. PROMISES
control flow

94. PROMISES
inversion of control
control flow

95. PROMISES
inversion of control
control flow

96. PROMISES
inversion of control
error handling
control flow

97. PROMISES
inversion of control
error handling
control flow

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

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

100. WIN!

101. BUT …

102. PROMISE HELL!

103. AVOID PROMISE HELL!

104. AVOID PROMISE HELL!

105. DON’T USE PROMISES
FOR CONTROL FLOW

107. YOUR CODEBASE THEN
BECOMES
PROMISE DEPENDANT

108. USING PROMISES
EVERYWHERE
IMPACTS ON THE
DESIGN

109. TO PROMISE OR TO
CALLBACK?

110. IF YOU HAVE A
LIBRARY, SUPPORT BOTH

112. SINGLE VALUE

113. SINGLE RESOLUTION
BAD FOR STREAMS

114. SINGLE RESOLUTION

115. PERFORMANCES?

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

117. 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

118. PERFORMANCES

119. PROMISES

120. WHAT IF WAITING WERE
JUST AS EASY AS
BLOCKING?

122. GENERATORS

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

124. GENERATORS

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

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

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

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

129. GENERATORS
with the yield where are pausing

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

132. GENERATORS

133. GENERATORS
iterator is just one side…

134. GENERATORS
the other side is an ”observable”

135. GENERATORS

136. GENERATORS

137. GENERATORS

138. GENERATORS

139. GENERATORS

140. GENERATORS

141. we can block
we can pull values
we can push values
GENERATORS

142. GENERATORS
+
PROMISES

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

144. GENERATORS + PROMISES

146. GENERATORS + PROMISES
npm install co

147. GENERATORS + PROMISES
co(getTotal)

148. BUT…

149. ES2017
to the rescue!

150. async/await

151. async/await

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

156. STREAMS

157. CHOOSE YOUR
CONCURRENCY MODEL

158. callbacks
async/await

159. A BIG THANKS TO
Kyle Simpson (@getify)
github.com/getify/You-Dont-Know-JS

160. THANK YOU!