Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Evolution of Asynchronous Javascript - Alessandro Cinelli - Codemotion Milan 2016

562 views

Published on

One of JavaScript’s strengths is how it handles asynchronous code. Async is one of the most important and often misunderstood part of Javascript or any other language. Async is hard because we, as human beings, can’t do two conscious actions at once and think about both of them at the same moment. In this talk we will see how asynchronous JavaScript evolved over the years. It all started with callbacks… and it landed on generators.

Published in: Technology
  • Be the first to comment

The Evolution of Asynchronous Javascript - Alessandro Cinelli - Codemotion Milan 2016

  1. 1. THE EVOLUTION OF ASYNCHRONOUS JAVASCRIPT @cirpo
  2. 2. @cirpo Dev lead at
  3. 3. now & later ASYNCRONY
  4. 4. the core of asynchronous programming is the relationship between the now and later parts of your program ASYNCRONY
  5. 5. how to express, manage and manipulate program behaviours over a period of time?
  6. 6. CONCURRENCY MODEL AND EVENT LOOP
  7. 7. stack queue heap
  8. 8. A JS runtime contains a message queue, which is a list of messages to be processed. QUEUE
  9. 9. A JS runtime contains a message queue, which is a list of messages to be processed. To each message is associated a function. QUEUE
  10. 10. 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
  11. 11. EVENT LOOP
  12. 12. events eventloop net filesystem … event queue thread pool
  13. 13. JS IS NON BLOCKING
  14. 14. 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
  15. 15. 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
  16. 16. Up until recently (ES2015), JS itself has actually never had any direct notion of asynchrony built into it
  17. 17. JS runs inside a hosting environment (the browser/nodejs) The event loop is handled by it
  18. 18. most devs new to JS have issues with the fact that later doesn’t happen strictly and immediately after now ASYNCRONY
  19. 19. ASYNCRONY
  20. 20. ASYNC IS GREAT
  21. 21. BUT CAN BE HARD
  22. 22. SEQUENTIAL BRAIN
  23. 23. SEQUENTIAL BRAIN put aside involuntary, subconscious, automatic brain functions we are not multitasker
  24. 24. can we do that?
  25. 25. yes… but we are blocking
  26. 26. WHAT IF WAITING WERE JUST AS EASY AS BLOCKING?
  27. 27. BLOCK
  28. 28. BLOCK =
  29. 29. BLOCK PULL =
  30. 30. WHEN YOU BLOCK, YOU “PULL” A VALUE
  31. 31. BLOCK PULL =
  32. 32. CALLBACK
  33. 33. PIRAMID OF DOOM!
  34. 34. CALLBACK HELL!
  35. 35. BULLSHIT
  36. 36. HOW TO AVOID POD
  37. 37. HOW TO AVOID POD
  38. 38. ASYNC CALLBACK
  39. 39. ASYNC CALLBACK =
  40. 40. ASYNC CALLBACK PUSH =
  41. 41. ASYNC CALLBACK PUSH =
  42. 42. LOSS OF CONTROL FLOW
  43. 43. LOSS OF ERROR HANDLING
  44. 44. INVERSION OF CONTROL
  45. 45. “Don't call us, we'll call you”
  46. 46. INVERSION OF CONTROL
  47. 47. INVERSION OF CONTROL what if it’s a third party call not under our control?
  48. 48. INVERSION OF CONTROL
  49. 49. INVERSION OF CONTROL what if it’s never called?
  50. 50. INVERSION OF CONTROL what if it’s never called? what if it’s called too early?
  51. 51. INVERSION OF CONTROL what if it’s never called? what if it’s called too early? what if it’s called too late?
  52. 52. meh.
  53. 53. HOW CAN YOU TELL IF IT’S AN ASYNC CALL?
  54. 54. meh.
  55. 55. Callbacks are the fundamental unit of asynchrony in JS. I <3 callbacks
  56. 56. 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
  57. 57. WHAT IF WAITING WERE JUST AS EASY AS BLOCKING?
  58. 58. PROMISES
  59. 59. PROMISES A promise represents a proxy for a value not necessarily known when the promise is created.
  60. 60. 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.
  61. 61. 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.
  62. 62. PROMISES always async
  63. 63. PROMISES http://ecma-international.org/ecma-262/6.0/#sec-jobs-and-job-queues
  64. 64. PROMISES always async handled once
  65. 65. PROMISES pending: initial state, not fulfilled or rejected fulfilled: the operation completed successfully rejected: meaning that the operation failed settled: has fulfilled or rejected
  66. 66. PROMISES always async handled once thenable
  67. 67. PROMISES A promise must provide a then method to access its current or eventual value .then()
  68. 68. PROMISES .then(function( onFulfilled, onRejected) )
  69. 69. PROMISES always async handled once thenable returns a promise
  70. 70. PROMISES can return a promise .then()
  71. 71. PROMISES .then() .then() .then()
  72. 72. PROMISES .catch()
  73. 73. Talk is cheap, show me the code
  74. 74. PROMISES
  75. 75. PROMISES
  76. 76. PROMISES control flow
  77. 77. PROMISES control flow
  78. 78. PROMISES inversion of control control flow
  79. 79. PROMISES inversion of control control flow
  80. 80. PROMISES inversion of control error handling control flow
  81. 81. PROMISES inversion of control error handling control flow
  82. 82. PROMISES inversion of control async or sync? error handling control flow
  83. 83. PROMISES inversion of control async or sync? error handling control flow
  84. 84. WIN!
  85. 85. BUT …
  86. 86. PROMISE HELL!
  87. 87. AVOID PROMISE HELL!
  88. 88. AVOID PROMISE HELL!
  89. 89. DON’T USE PROMISES FOR CONTROL FLOW
  90. 90. YOUR CODEBASE THEN BECOMES PROMISE DEPENDANT
  91. 91. USING PROMISES EVERYWHERE IMPACTS ON THE DESIGN
  92. 92. TO PROMISE OR TO CALLBACK?
  93. 93. IF YOU HAVE A LIBRARY, SUPPORT BOTH
  94. 94. SINGLE VALUE
  95. 95. SINGLE RESOLUTION BAD FOR STREAMS
  96. 96. SINGLE RESOLUTION
  97. 97. PERFORMANCES?
  98. 98. PERFORMANCES Promises are slower compared to callbacks You don’t get rid of callbacks, they just orchestrate callbacks in a trustable way
  99. 99. 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
  100. 100. PERFORMANCES
  101. 101. PROMISES
  102. 102. WHAT IF WAITING WERE JUST AS EASY AS BLOCKING?
  103. 103. GENERATORS
  104. 104. GENERATORS A new type of function that does’t not behave with the run-to-completion behaviour
  105. 105. GENERATORS
  106. 106. GENERATORS 1 constructing the iterator, not executing 2 starts the iterator
  107. 107. GENERATORS 1 constructing the iterator, not executing 2 starts the iterator
  108. 108. GENERATORS 1 constructing the iterator, not executing 2 starts the iterator 4 resume the iterator 3 pause the iterator
  109. 109. GENERATORS 1 constructing the iterator, not executing 2 starts the iterator 4 resume the iterator 3 pause the iterator
  110. 110. GENERATORS with the yield where are pausing
  111. 111. GENERATORS A.K.A “BLOCKING”! with the yield where are pausing
  112. 112. GENERATORS
  113. 113. GENERATORS iterator is just one side…
  114. 114. GENERATORS the other side is an ”observable”
  115. 115. GENERATORS
  116. 116. GENERATORS
  117. 117. GENERATORS
  118. 118. GENERATORS
  119. 119. GENERATORS
  120. 120. GENERATORS
  121. 121. we can block we can pull values we can push values GENERATORS
  122. 122. GENERATORS + PROMISES
  123. 123. 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
  124. 124. GENERATORS + PROMISES
  125. 125. GENERATORS + PROMISES npm install co
  126. 126. GENERATORS + PROMISES co(getTotal)
  127. 127. BUT…
  128. 128. ES2017 to the rescue!
  129. 129. async/await
  130. 130. async/await
  131. 131. 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
  132. 132. STREAMS
  133. 133. CHOOSE YOUR CONCURRENCY MODEL
  134. 134. callbacks async/await
  135. 135. A BIG THANKS TO Kyle Simpson (@getify) github.com/getify/You-Dont-Know-JS
  136. 136. THANK YOU!

×