davidbgk
/
larlet-fr-david-cache


			
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678
							<!doctype html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang=fr>
<!-- Has to be within the first 1024 bytes, hence before the <title>
  See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset=utf-8>
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
  See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name=viewport content="width=device-width,minimum-scale=1,initial-scale=1,shrink-to-fit=no">
<!-- Required to make a valid HTML5 document. -->
<title>Why I’m Not Waiting On ‘await’ (part 2) (archive) — David Larlet</title>
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon" sizes="180x180" href="/static/david/icons/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/static/david/icons/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/static/david/icons/favicon-16x16.png">
<link rel="manifest" href="/manifest.json">
<link rel="mask-icon" href="/static/david/icons/safari-pinned-tab.svg" color="#5bbad5">
<link rel="shortcut icon" href="/static/david/icons/favicon.ico">
<meta name="apple-mobile-web-app-title" content="David Larlet">
<meta name="application-name" content="David Larlet">
<meta name="msapplication-TileColor" content="#da532c">
<meta name="msapplication-config" content="/static/david/icons/browserconfig.xml">
<meta name="theme-color" content="#f0f0ea">
<!-- That good ol' feed, subscribe :p. -->
<link rel=alternate type="application/atom+xml" title=Feed href="/david/log/">

  <meta name="robots" content="noindex, nofollow">
  <meta content="origin-when-cross-origin" name="referrer">
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://blog.getify.com/not-awaiting-2">

<style>
/* http://meyerweb.com/eric/tools/css/reset/ */
html, body, div, span,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, address, big, cite, code,
del, dfn, em, img, ins,
small, strike, strong, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
  margin: 0;
  padding: 0;
  border: 0;
  font-size: 100%;
  font: inherit;
  vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section { display: block; }
body { line-height: 1; }
blockquote, q { quotes: none; }
blockquote:before, blockquote:after,
q:before, q:after {
  content: '';
  content: none;
}
table {
  border-collapse: collapse;
  border-spacing: 0;
}

/* http://practicaltypography.com/equity.html */
/* https://calendar.perfplanet.com/2016/no-font-face-bulletproof-syntax/ */
/* https://www.filamentgroup.com/lab/js-web-fonts.html */
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Regular-webfont.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Italic-webfont.woff') format('woff');
  font-weight: 300;
  font-style: italic;
  font-display: swap;
}
@font-face {
  font-family: 'EquityTextB';
  src: url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff2') format('woff2'),
       url('/static/david/css/fonts/Equity-Text-B-Bold-webfont.woff') format('woff');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: 'ConcourseT3';
  src: url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff2') format('woff2'),
       url('/static/david/css/fonts/concourse_t3_regular-webfont-20190806.woff') format('woff');
  font-weight: 300;
  font-style: normal;
  font-display: swap;
}


/* http://practice.typekit.com/lesson/caring-about-opentype-features/ */
body {
  /* http://www.cssfontstack.com/ Palatino 99% Win 86% Mac */
  font-family: "EquityTextB", Palatino, serif;
  background-color: #f0f0ea;
  color: #07486c;
  font-kerning: normal;
  -moz-osx-font-smoothing: grayscale;
  -webkit-font-smoothing: subpixel-antialiased;
  text-rendering: optimizeLegibility;
  font-variant-ligatures: common-ligatures contextual;
  font-feature-settings: "kern", "liga", "clig", "calt";
}
pre, code, kbd, samp, var, tt {
  font-family: 'TriplicateT4c', monospace;
}
em {
  font-style: italic;
  color: #323a45;
}
strong {
  font-weight: bold;
  color: black;
}
nav {
  background-color: #323a45;
  color: #f0f0ea;
  display: flex;
  justify-content: space-around;
  padding: 1rem .5rem;
}
  nav:last-child {
    border-bottom: 1vh solid #2d7474;
  }
  nav a {
    color: #f0f0ea;
  }
  nav abbr {
    border-bottom: 1px dotted white;
  }

h1 {
  border-top: 1vh solid #2d7474;
  border-bottom: .2vh dotted #2d7474;
  background-color: #e3e1e1;
  color: #323a45;
  text-align: center;
  padding: 5rem 0 4rem 0;
  width: 100%;
  font-family: 'ConcourseT3';
  display: flex;
  flex-direction: column;
}
  h1.single {
    padding-bottom: 10rem;
  }
  h1 span {
    position: absolute;
    top: 1vh;
    left: 20%;
    line-height: 0;
  }
    h1 span a {
      line-height: 1.7;
      padding: 1rem 1.2rem .6rem 1.2rem;
      border-radius: 0 0 6% 6%;
      background: #2d7474;
      font-size: 1.3rem;
      color: white;
      text-decoration: none;
    }
h2 {
  margin: 4rem 0 1rem;
  border-top: .2vh solid #2d7474;
  padding-top: 1vh;
}
h3 {
  text-align: center;
  margin: 3rem 0 .75em;
}
hr {
  height: .4rem;
  width: .4rem;
  border-radius: .4rem;
  background: #07486c;
  margin: 2.5rem auto;
}
time {
  display: bloc;
  margin-left: 0 !important;
}
ul, ol {
  margin: 2rem;
}
ul {
  list-style-type: square;
}
a {
  text-decoration-skip-ink: auto;
  text-decoration-thickness: 0.05em;
  text-underline-offset: 0.09em;
}
article {
  max-width: 50rem;
  display: flex;
  flex-direction: column;
  margin: 2rem auto;
}
  article.single {
    border-top: .2vh dotted #2d7474;
    margin: -6rem auto 1rem auto;
    background: #f0f0ea;
    padding: 2rem;
  }
  article p:last-child {
    margin-bottom: 1rem;
  }
p {
  padding: 0 .5rem;
  margin-left: 3rem;
}
  p + p,
  figure + p {
    margin-top: 2rem;
  }

blockquote {
  background-color: #e3e1e1;
  border-left: .5vw solid #2d7474;
  display: flex;
  flex-direction: column;
  align-items: center;
  padding: 1rem;
  margin: 1.5rem;
}
  blockquote cite {
    font-style: italic;
  }
  blockquote p {
    margin-left: 0;
  }

figure {
  border-top: .2vh solid #2d7474;
  background-color: #e3e1e1;
  text-align: center;
  padding: 1.5rem 0;
  margin: 1rem 0 0;
  font-size: 1.5rem;
  width: 100%;
}
  figure img {
    max-width: 250px;
    max-height: 250px;
    border: .5vw solid #323a45;
    padding: 1px;
  }
figcaption {
  padding: 1rem;
  line-height: 1.4;
}
aside {
  display: flex;
  flex-direction: column;
  background-color: #e3e1e1;
  padding: 1rem 0;
  border-bottom: .2vh solid #07486c;
}
  aside p {
    max-width: 50rem;
    margin: 0 auto;
  }

/* https://fvsch.com/code/css-locks/ */
p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
  font-size: 1rem;
  line-height: calc( 1.5em + 0.2 * 1rem );
}
h1 {
  font-size: 1.9rem;
  line-height: calc( 1.2em + 0.2 * 1rem );
}
h2 {
  font-size: 1.6rem;
  line-height: calc( 1.3em + 0.2 * 1rem );
}
h3 {
  font-size: 1.35rem;
  line-height: calc( 1.4em + 0.2 * 1rem );
}
@media (min-width: 20em) {
  /* The (100vw - 20rem) / (50 - 20) part
     resolves to 0-1rem, depending on the
     viewport width (between 20em and 50em). */
  p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
    font-size: calc( 1rem + .6 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.5em + 0.2 * (100vw - 50rem) / (20 - 50) );
    margin-left: 0;
  }
  h1 {
    font-size: calc( 1.9rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.2em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
  h2 {
    font-size: calc( 1.5rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.3em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
  h3 {
    font-size: calc( 1.35rem + 1.5 * (100vw - 20rem) / (50 - 20) );
    line-height: calc( 1.4em + 0.2 * (100vw - 50rem) / (20 - 50) );
  }
}
@media (min-width: 50em) {
  /* The right part of the addition *must* be a
     rem value. In this example we *could* change
     the whole declaration to font-size:2.5rem,
     but if our baseline value was not expressed
     in rem we would have to use calc. */
  p, li, pre, code, kbd, samp, var, tt, time, details, figcaption {
    font-size: calc( 1rem + .6 * 1rem );
    line-height: 1.5em;
  }
  p, li, pre, details {
    margin-left: 3rem;
  }
  h1 {
    font-size: calc( 1.9rem + 1.5 * 1rem );
    line-height: 1.2em;
  }
  h2 {
    font-size: calc( 1.5rem + 1.5 * 1rem );
    line-height: 1.3em;
  }
  h3 {
    font-size: calc( 1.35rem + 1.5 * 1rem );
    line-height: 1.4em;
  }
  figure img {
    max-width: 500px;
    max-height: 500px;
  }
}

figure.unsquared {
  margin-bottom: 1.5rem;
}
  figure.unsquared img {
    height: inherit;
  }


@media print {
  body { font-size: 100%; }
  a:after { content: " (" attr(href) ")"; }
  a, a:link, a:visited, a:after {
    text-decoration: underline;
    text-shadow: none !important;
    background-image: none !important;
    background: white;
    color: black;
  }
  abbr[title] { border-bottom: 0; }
  abbr[title]:after { content: " (" attr(title) ")"; }
  img { page-break-inside: avoid; }
  @page { margin: 2cm .5cm; }
  h1, h2, h3 { page-break-after: avoid; }
  p3 { orphans: 3; widows: 3; }
  img {
    max-width: 250px !important;
    max-height: 250px !important;
  }
  nav, aside { display: none; }
}

ul.with_columns {
  column-count: 1;
}
@media (min-width: 20em) {
  ul.with_columns {
    column-count: 2;
  }
}
@media (min-width: 50em) {
  ul.with_columns {
    column-count: 3;
  }
}
ul.with_two_columns {
  column-count: 1;
}
@media (min-width: 20em) {
  ul.with_two_columns {
    column-count: 1;
  }
}
@media (min-width: 50em) {
  ul.with_two_columns {
    column-count: 2;
  }
}

.gallery {
  display: flex;
  flex-wrap: wrap;
  justify-content: space-around;
}
  .gallery figure img {
    margin-left: 1rem;
    margin-right: 1rem;
  }
  .gallery figure figcaption {
    font-family: 'ConcourseT3'
  }

footer {
  font-family: 'ConcourseT3';
  display: flex;
  flex-direction: column;
  border-top: 3px solid white;
  padding: 4rem 0;
  background-color: #07486c;
  color: white;
}
  footer > * {
    max-width: 50rem;
    margin: 0 auto;
  }
  footer a {
    color: #f1c40f;
  }
  footer .avatar {
    width: 200px;
    height: 200px;
    border-radius: 50%;
    float: left;
    -webkit-shape-outside: circle();
    shape-outside: circle();
    margin-right: 2rem;
    padding: 2px 5px 5px 2px;
    background: white;
    border-left: 1px solid #f1c40f;
    border-top: 1px solid #f1c40f;
    border-right: 5px solid #f1c40f;
    border-bottom: 5px solid #f1c40f;
  }
</style>

<h1>
  <span><a id="jumper" href="#jumpto" title="Un peu perdu ?">?</a></span>
  Why I’m Not Waiting On ‘await’ (part 2) (archive)
  <time>Pour la pérennité des contenus liés. Non-indexé, retrait sur simple email.</time>
</h1>
<section>
  <article>
    <h3><a href="https://blog.getify.com/not-awaiting-2">Source originale du contenu</a></h3>
    <div>
<p>Two-part series on the highs and lows of the coming <code>async..await</code> in JS:</p>
<ul>
<li><a href="https://blog.getify.com/not-awaiting-1">Part 1</a>: what <code>async..await</code> is and why it’s awesome</li>
<li><a href="https://blog.getify.com/not-awaiting-2">Part 2</a>: why <code>async..await</code> falls short compared to generators+promises</li>
</ul>
</div>

<p><hr/>
<hr/>
<p>In <a href="https://blog.getify.com/not-awaiting-1/">part one</a>, I covered why <code>async..await</code> has built up such momentum on the hype train. The promise of sync-looking async is powerfully attractive.</p>
<p>Now I’ll cover why I think we should slow that train down. A bunch.</p>
<p>I’m going to make a case for sticking with generators+promises by exploring some shortcomings of <code>async..await</code>. As I’ve already shown, the syntax of generators+promises isn’t that much worse. But they’re more powerful.</p>
<h3 id="missing-direct-delegation">Missing Direct Delegation</h3>
<p><a href="https://blog.getify.com/not-awaiting-1/#a-rose-by-any-other-name">Remember in part one</a> where I asserted that <code>yield</code> is more about control transfer than value semantics? That’s more obvious once we look at <code>yield *</code>.</p>
<p>In a generator, a <code>yield</code> transfers control back to the calling code. But what if we want to delegate to another piece of code, while still preserving the pause/resume async semantics.</p>
<p>We can instead do a <code>yield *</code> delegation to another generator, like this:</p>
<pre class="code">
function *foo() {
  var x = yield getX();
  var y = yield * bar( x );
  console.log( x, y );
}</p>
<p>function *bar(x) {
  var y = yield getY( x );
  var z = yield getZ( y );
  return y + z;
}</p>
<p>run( foo() );
</pre>
<p>You'll notice that the <code>yield * bar(..)</code> lets the <code>bar()</code> generator run. But <strong>how</strong> does it run? We didn't use the <code>run(..)</code> utility on that call.</p>
<p>We don't have to, because <code>yield *</code> actually <em>delegates control</em>, so the original <code>run(..)</code> from the last line of the snippet is now transparently controlling (pausing/resuming) the <code>bar()</code> generator as it proceeds, without even knowing it. Once <code>bar()</code> completes, its return value (if any) finally resumes the <code>yield *</code> with that value, returning execution to the <code>foo()</code> generator.</p>
<p>The <code>yield *</code> can even be used to create a sort of generator recursion, where a generator instance delegates to another instance of itself.</p>
<p>Because <code>async function</code>s are not about control transfer, there's no equivalent to <code>yield *</code> like <code>await *</code>. There <em>was</em> talk about appropriating the <code>await *</code> syntax to mean something like <code>await Promise.all(..)</code>, but that was eventually rejected.</p>
<p>The <code>async function</code> equivalent would be:</p>
<pre class="code">
async function foo() {
  var x = await getX();
  var y = await bar( x );
  console.log( x, y );
}</p>
<p>async function bar(x) {
  var y = await getY( x );
  var z = await getZ( y );
  return y + z;
}</p>
<p>foo();
</pre>
<p>We don't need a <code>yield *</code>-type construct here because <code>bar()</code> creates a promise we can <code>await</code>.</p>
<p>That may seem that it's basically just, again, nicer syntax sugar removing the need for the <code>*</code>. But it's subtly different. With the <code>yield *</code>, we're not creating a wrapper promise but rather just passing control directly through.</p>
<p>What if <code>bar()</code> has some case where it can provide its result right away, such as pulling from a cache/memoization?</p>
<pre class="code">
function *bar(x) {
  if (x in cache) {
    return cache[x];
  }</p>
<p>var y = yield getY( x );
  var z = yield getZ( y );
  return y + z;
}
</pre>
<p>versus:</p>
<pre class="code">
async function bar(x) {
  if (x in cache) {
    return cache[x];
  }</p>
<p>var y = await getY( x );
  var z = await getZ( y );
  return y + z;
}
</pre>
<p>In both cases, we immediately <code>return cache[x]</code>.</p>
<p>In the <code>yield *</code> case, <code>return</code> immediately terminates the generator instance, so we'd get that result back in <code>foo()</code> right away. But with promises (which is what <code>async function</code>s return), unwrapping is an async step, so we have to wait a tick before we can get that value.</p>
<p>Depending on your situation, <strong>that may slow your program down a little bit</strong>, especially if you're using that pattern a lot.</p>
<h3 id="cant-be-stopped">Can't Be Stopped</h3>
<p>In part one, <a href="https://blog.getify.com/not-awaiting-1/#a-rose-by-any-other-name">I asserted</a> that <code>await</code> is declarative while <code>yield</code> is imperative. Pushing that to a higher level, <code>async function</code>s are declarative and generators are imperative.</p>
<p>An <code>async function</code> is represented by (ie, returns) a promise. This promise represents one of two states: the whole thing finished, or something went wrong and it stopped. In that sense, the <code>async function</code> is an all-or-nothing proposition. But moreover, because it's a promise that's returned, all you can do is observe the outcome, not control it.</p>
<p>By contrast, a generator is represented by (ie, returns) an iterator. The iterator is an external control for each of the steps in the generator. We don't just observe a generator's outcome, we participate in it and control it.</p>
<p>The <code>run(..)</code> function that drives the generator+promise async flow control logic is actually negotiating via the iterator.</p>
<p>The <code>next(..)</code> command on the iterator is how values are sent into the generator, and how values are received from it as it progresses. The iterator also has another method on it called <code>throw(..)</code>, which injects an exception into the generator at its paused position; <code>next(..)</code> and <code>throw(..)</code> pair together to signal (from the outside) success or failure of any given step in the generator.</p>
<p>Of course, there's no requirement that the code controlling a generator's iterator choose to keep it going with <code>next(..)</code> or <code>throw(..)</code>. Merely opting to stop calling either has the effect of indefinitely pausing the generator. The iterator instance could be left in this paused state until the program ends or it's garbage collected.</p>
<p>Even better, a generator's iterator has a third method on it that can be useful: <code>return(..)</code>. This method terminates the generator at its current paused point; you can send an affirmative signal into the generator from the outside telling it to stop right where it sits.</p>
<p>You can even detect and respond to this <code>return(..)</code> signal inside the generator with the <code>finally</code> clause of a <code>try</code> statement; a <code>finally</code> will always be executed, even if the statement inside its associated <code>try</code> was terminated from the outside with an iterator's <code>return(..)</code> method.</p>
<p>A <code>run(..)</code> that was slightly smarter could offer the advantage of allowing a generator to be stopped from the outside.</p>
<p>Imagine a scenario where midway through a generator's steps, you can tell by the values emitted that it's appropriate to stop the progression of the generator -- to cancel any further actions. Maybe the generator makes a series of Ajax calls one after the other, but one of the results signals that none of the others should be made.</p>
<p>Consider a more capable <code>run(..)</code> used like this:</p>
<pre class="code">
run( main(), function shouldTerminate(val){
  if (val == 42) return true;
  return false;
} );
</pre>
<p>Each time a value is ready to be sent in to resume the <code>main()</code> generator, this <code>shouldTerminate(..)</code> function is first called with the value. If <em>it</em> returns <code>true</code>, then the iterator is <code>return(..)</code>d, otherwise the value is sent via <code>next(..)</code>.</p>
<p>A generator provides the power of external cancelation capability whereas an <code>async function</code> can only cancel itself. Of course, the necessary cancelation logic can be baked into the <code>async function</code>, but that's not always appropriate.</p>
<p>It's often much more appropriate to separate the async steps themselves from any logic that will consume or control (or cancel) them as a result. With generators that is possible, but with <code>async function</code>s it's not.</p>
<h3 id="scheduling-is-hidden">Scheduling Is Hidden</h3>
<p>It's tempting to assume that a program should always complete its async steps ASAP. It may be hard to conceive of a situation where you wouldn't want some part of the program to proceed <em>right away</em>.</p>
<p>Let's consider a scenario where we have more than one set of asynchronous logic operating at the same time. For example, we might be making some HTTP requests and we might also be making some database calls. For the sake of this discussion, let's assume that each set of behavior is implemented in its own <code>async function</code>.</p>
<p>Because <code>async function</code>s essentially come with their own <code>run(..)</code> utility built-in, the progression of steps is entirely opaque and advances strictly in ASAP fashion.</p>
<p>But what if you needed to control the scheduling of the resumptions of each task's steps? What if, for the purposes of throttling resource usage, you needed to make sure that no more than one HTTP request/response was handled for each database request?</p>
<p>Another problem could be that one set of async steps might have each step proceed so quickly (essentially immediately) that this task could "starve" the rest of the system by not letting any other tasks have a chance. To understand this possibility, you should read more about <a href="https://github.com/getify/You-Dont-Know-JS/blob/master/async%20&amp;%20performance/ch1.md#jobs">microtasks (aka Jobs)</a>. Basically, if each step in a promise chain resolves immediately, each subsequent step is scheduled "right away", such that no other waiting asynchronous operations get to run.</p>
<p>Or what if you had ten sets of HTTP request/response cycles, but you need to make sure that no more than 3 of them were being processed at any given moment? Or perhaps you needed to not proceed ASAP but rather in a strictly round-robin order through the set of running tasks.</p>
<p>There's probably half a dozen other scenarios where naive scheduling of the progression of async operations is not sufficient. In all those cases, we'd like to have more control.</p>
<p>An <code>async function</code> affords no such control because the promise-resumption step is baked into the engine. But a smarter <code>run(..)</code> utility driving your generators could absolutely selectively decide which ones to resume in which order.</p>
<p>By the way, while I'm being general about such scenarios for brevity sake, this is not purely theoretical. An open area of my research in async programming is <a href="..">CSP</a>, Communicating Sequential Processes, the model for concurrency used in the <em>go</em> language and also in ClojureScript's <code>core.async</code>.</p>
<p>Normally CSP processes are modeled in JS using generators, because you will in general have many of them running at the same time, and usually need fine grained control over which ones resume after others pause. Attempts have been made to model CSP using <code>async function</code>s, but I believe these systems are inherently flawed in that the library is susceptible to all the above limitations because it has no control over the scheduling.</p>
<p>CSP is one very concrete example of why it's important to have scheduling control over async operations. <code>async function</code>s just don't offer what we need, but generators do.</p>
<h3 id="async-functions-vs-generators"><code>async function</code>s vs Generators</h3>
<p>OK, so let's take stock of where we're at.</p>
<p>First we examined how <code>async function</code>s work and what makes them so nice from a syntactic sugar perspective. But now we've seen several places where the tradeoff is that we lose control of potentially very important aspects of our asynchrony.</p>
<p>You may consider these limitations unimportant because you haven't needed to do any of the fine-grained control described here. And that's fine. The <code>async function</code> will serve you just fine.</p>
<p>But... what pain are you <em>really</em> enduring if you stuck with generators? Again, a side-by-side comparison:</p>
<pre class="code">
function *foo(x) {
  try {
    var y = yield getY( x );
    return x + y;
  }
  catch (err) {
    return x;
  }
}</p>
<p>run( foo( 3 ) )
.then( function(result){
  console.log( result );
} );
</pre>
<p>versus:</p>
<pre class="code">
async function foo(x) {
  try {
    var y = await getY( x );
    return x + y;
  }
  catch (err) {
    return x;
  }
}</p>
<p>foo( 3 )
.then( function(result){
  console.log( result );
} );
</pre>
<p>They're almost identical.</p>
<p>In both versions you get localized synchronous semantics (including pause/resume and error handling), and you get a promise that represents the completion of the <code>foo(..)</code> task.</p>
<p>For generators, you <em>do</em> need the simple <code>run(..)</code> library utility, whereas with <code>async function</code>s, you don't. But as we discussed, such a utility is only about a dozen lines of code in its simplest form. So is it actually that burdensome?</p>
<p>For the extra control we get, I think <code>run(..)</code> is an easy price to justify.</p>
<h3 id="finally"><code>finally { .. }</code></h3>
<p>For the majority of my async code, I believe generators+promises is a better, more flexible, more powerful option, at only a minimal expense.</p>
<p>I'd rather not start with <code>async function</code>s and then later realize that there are places where I need more control, and have to refactor back to generators. That's especially true considering the <a href="https://blog.getify.com/not-awaiting-1/#just-use-both">complications of mixing the two forms</a> that I addressed in part one.</p>
<p><code>async..await</code> seems like a great feature. But it's too simplistic, IMO. The small syntactic benefits are not worth the loss of control.</p></p>
  </article>
</section>


<nav id="jumpto">
  <p>
    <a href="/david/blog/">Accueil du blog</a> |
    <a href="https://blog.getify.com/not-awaiting-2">Source originale</a> |
    <a href="/david/stream/2019/">Accueil du flux</a>
  </p>
</nav>

<footer>
  <div>
    <img src="/static/david/david-larlet-avatar.jpg" loading="lazy" class="avatar" width="200" height="200">
    <p>
      Bonjour/Hi!
      Je suis <a href="/david/" title="Profil public">David&nbsp;Larlet</a>, je vis actuellement à Montréal et j’alimente cet espace depuis 15 ans. <br>
      Si tu as apprécié cette lecture, n’hésite pas à poursuivre ton exploration. Par exemple via les <a href="/david/blog/" title="Expériences bienveillantes">réflexions bimestrielles</a>, la <a href="/david/stream/2019/" title="Pensées (dés)articulées">veille hebdomadaire</a> ou en t’abonnant au <a href="/david/log/" title="S’abonner aux publications via RSS">flux RSS</a> (<a href="/david/blog/2019/flux-rss/" title="Tiens c’est quoi un flux RSS ?">so 2005</a>).
    </p>
    <p>
      Je m’intéresse à la place que je peux avoir dans ce monde. En tant qu’humain, en tant que membre d’une famille et en tant qu’associé d’une coopérative. De temps en temps, je fais aussi des <a href="https://github.com/davidbgk" title="Principalement sur Github mais aussi ailleurs">trucs techniques</a>. Et encore plus rarement, <a href="/david/talks/" title="En ce moment je laisse plutôt la place aux autres">j’en parle</a>.
    </p>
    
    <p>
      Voici quelques articles choisis :
      <a href="/david/blog/2019/faire-equipe/" title="Accéder à l’article complet">Faire équipe</a>,
      <a href="/david/blog/2018/bivouac-automnal/" title="Accéder à l’article complet">Bivouac automnal</a>,
      <a href="/david/blog/2018/commodite-effondrement/" title="Accéder à l’article complet">Commodité et effondrement</a>,
      <a href="/david/blog/2017/donnees-communs/" title="Accéder à l’article complet">Des données aux communs</a>,
      <a href="/david/blog/2016/accompagner-enfant/" title="Accéder à l’article complet">Accompagner un enfant</a>,
      <a href="/david/blog/2016/senior-developer/" title="Accéder à l’article complet">Senior developer</a>,
      <a href="/david/blog/2016/illusion-sociale/" title="Accéder à l’article complet">L’illusion sociale</a>,
      <a href="/david/blog/2016/instantane-scopyleft/" title="Accéder à l’article complet">Instantané Scopyleft</a>,
      <a href="/david/blog/2016/enseigner-web/" title="Accéder à l’article complet">Enseigner le Web</a>,
      <a href="/david/blog/2016/simplicite-defaut/" title="Accéder à l’article complet">Simplicité par défaut</a>,
      <a href="/david/blog/2016/minimalisme-esthetique/" title="Accéder à l’article complet">Minimalisme et esthétique</a>,
      <a href="/david/blog/2014/un-web-omni-present/" title="Accéder à l’article complet">Un web omni-présent</a>,
      <a href="/david/blog/2014/manifeste-developpeur/" title="Accéder à l’article complet">Manifeste de développeur</a>,
      <a href="/david/blog/2013/confort-convivialite/" title="Accéder à l’article complet">Confort et convivialité</a>,
      <a href="/david/blog/2013/testament-numerique/" title="Accéder à l’article complet">Testament numérique</a>,
      et <a href="/david/blog/" title="Accéder aux archives">bien d’autres…</a>
    </p>
    <p>
      On peut <a href="mailto:david%40larlet.fr" title="Envoyer un courriel">échanger par courriel</a>. Si éventuellement tu souhaites que l’on travaille ensemble, tu devrais commencer par consulter le <a href="http://larlet.com">profil dédié à mon activité professionnelle</a> et/ou contacter directement <a href="http://scopyleft.fr/">scopyleft</a>, la <abbr title="Société coopérative et participative">SCOP</abbr> dont je fais partie depuis six ans. Je recommande au préalable de lire <a href="/david/blog/2018/cout-site/" title="Attention ce qui va suivre peut vous choquer">combien coûte un site</a> et pourquoi je suis plutôt favorable à une <a href="/david/pro/devis/" title="Discutons-en !">non-demande de devis</a>.
    </p>
    <p>
      Je ne traque pas ta navigation mais mon
      <abbr title="Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33.184162340">hébergeur</abbr>
      conserve des logs d’accès.
    </p>
  </div>
</footer>
<script type="text/javascript">
  ;(_ => {
    const jumper = document.getElementById('jumper')
    jumper.addEventListener('click', e => {
      e.preventDefault()
      const anchor = e.target.getAttribute('href')
      const targetEl = document.getElementById(anchor.substring(1))
      targetEl.scrollIntoView({behavior: 'smooth'})
    })
  })()
</script>