Slowly but surely, promises have spread throughout the JavaScript ecosystem, standardized by ES 2015 and embraced by the web platform. But the world of asynchronous programming contains more patterns than the simple single-valued async function call that promises represent. What about things like streams, observables, async iterators—or even just cancelable promises? How do they fit, both in the conceptual landscape and in your day-to-day programming? For the last year, I've been working to bring an implementation of I/O streams to the browser. Meanwhile, designs for a cancelable promise type (sometimes called "tasks") are starting to form, driven by the needs of web platform APIs. And TC39 has several proposals floating around for more general asynchronous iteration. We'll learn about these efforts and more, as I guide you through the frontiers of popular libraries, language design, and web standards.

1. ASYNC FRONTIERS

2. HI, I’M DOMENIC

3. STANDARDS AS PROTOCOLS

4. A PROMISE-RETURNING PLATFORM
▪ fetch(…)
▪ navigator.mediaDevices.getUserMedia(…)
▪ fontFace.load()
▪ httpResponseBody.text()
▪ navigator.requestMIDIAccess()
▪ serviceWorkerClient.openWindow(…)
▪ crypto.subtle.encrypt(…)
▪ animation.finished
▪ …

5. THERE’S MORE TO LIFE THAN PROMISES

6. singular plural
sync values iterators
async promises ???

7. singular plural
sync values iterators
async promises ???

8. THE REAL WORLD IS MORE COMPLICATED

9. TWO AXES OF INTERESTINGNESS
▪Asynchronicity
▪Pluralness

10. THE ASYNCHRONOUS FRONTIER

11. SINGULAR/ASYNC
Quadrant 2

12. TAMING COMPLEXITY VIA OPINIONS
▪ Promises are eager, not lazy
▪ Continuables a.k.a. “thunks” are a lazy alternative
▪ Instead, we use functions returning promises for laziness
▪ Promises enforce async-flattening
▪ No promises for promises
▪ Troublesome for type systems, but convenient for developers
▪ Promise bake in exception semantics
▪ Could delegate that to another type, e.g. Either<value, error>
▪ But promise semantics integrate well with JS (see async/await)

13. RESULT, NOT ACTION
Promises represent the eventual result
of an async action; they are not a
representation of the action itself

14. PROMISES ARE MULTI-CONSUMER
// In one part of your code
awesomeFonts.ready.then(() => {
revealAwesomeContent();
scrollToAwesomeContent();
});
// In another part of your code
awesomeFonts.ready.then(() => {
preloadMoreFonts();
loadAds();
});

15. CANCELABLE PROMISES (“TASKS”)
▪ Showing up first in the Fetch API
▪ A promise subclass
▪ Consumers can request cancelation
▪ Multi-consumer branching still allowed; ref-counting tracks cancelation
requests

16. CANCELABLE PROMISES IN ACTION
const fp = fetch(url);
fp.cancel(); // cancel the fetch
const fp2 = fetch(url);
const jp = fp2.then(res => res.json());
jp.cancel(); // cancel either the fetch or the JSON body parsing
const fp3 = fetch(url);
const jp = fp3.then(res => res.json());
const hp = fp3.then(res => res.headers);
jp.cancel(); // nothing happens yet
hp.cancel(); // *now* the fetch could be canceled

17. CANCELABLE PROMISES IN ACTION
// Every promise gets finally
anyPromise.finally(() => {
doSomeCleanup();
console.log("all done, one way or another!");
});
// Canceled promises *only* get finally triggered
canceled
.then(() => console.log("never happens"))
.catch(e => console.log("never happens"))
.finally(() => console.log("always happens"));

18. CANCELABLE PROMISES IN ACTION
// All together now:
startSpinner();
const p = fetch(url)
.then(r => r.json())
.then(data => fetch(data.otherUrl))
.then(r => r.text())
.then(text => updateUI(text))
.catch(err => showUIError())
.finally(stopSpinner);
cancelButton.onclick = () => p.cancel();

19. DESIGN DECISIONS FOR TASKS
▪ Ref-counting, instead of disallowing branching
▪ Cancelation (= third state), instead of abortion (= rejected promise)
▪ Subclass, instead of baking it in to the base Promise class
▪ Evolve promises, instead of creating something incompatible

20. TASKS ARE IN PROGRESS,
BUT I AM HOPEFUL

21. PLURAL/SYNC
Quadrant 3

22. READ-ONLY VS. MUTABLE
▪ Iterator interface
▪ next() → { value, done }
▪ Generator interface
▪ next(v) → { value, done }
▪ throw(e)
▪ return(v)

23. ITERATORS ARE SINGLE-CONSUMER
▪ Once you next() an iterator, that value is gone forever
▪ If you want a reusable source of iterators, have a function that returns
fresh iterators
▪ Iterables have [Symbol.iterator]() methods that do exactly that
▪ (… except sometimes they don’t)
▪ Is the iterator or the iterable fundamental?
▪ Is the sequence repeatable?

24. WHERE DO WE ADD METHODS?
▪ myArray.map(…).filter(…).reduce(…) is nice
▪ Can we have that for iterators? Iterables?
▪ Iterators conventionally share a common prototype (but not always)
▪ Iterables do not—could we retrofit one? Probably not…
▪ If we add them to iterators, is it OK that mapping “consumes” the
sequence?
▪ If we add them to iterables, how do we choose between
keys/entries/values?

25. REVERSE ITERATORS?
▪ You can’t in general iterate backward through an iterator
▪ The iterator may be infinite, or generated from a generator function, …
▪ You can reduce, but not reduceRight
▪ https://github.com/leebyron/ecmascript-reverse-iterable

26. ITERATORS WORK,
BUT HAVE ROOM TO GROW

27. PLURAL/ASYNC
Quadrant 4!

28. WHAT NEEDS ASYNC PLURAL, ANYWAY?
▪ I/O streams
▪ Directory listings
▪ Sensor readings
▪ Events in general
▪ …

29. AN ITERATOR OF PROMISES? NO
iop.next() // { value: a promise, done: ??? }
iop.next() // { value: a promise, done: ??? }
iop.next() // { value: a promise, done: ??? }
iop.next() // { value: a promise, done: ??? }

30. ASYNC ITERATORS
https://github.com/zenparsing/async-iteration/
ai.next() // promise for { value, done }
ai.next() // promise for { value, done }
ai.next() // promise for { value, done }

31. ASYNC ITERATORS
https://github.com/zenparsing/async-iteration/
async for (const x of ai) {
console.log(x);
}

32. ASYNC ITERATORS
https://github.com/zenparsing/async-iteration/
async function* directoryEntries(path) {
const dir = await opendir(path);
try {
let entry;
while ((entry = await readdir(dir)) !== null) {
yield entry;
}
} finally {
yield closedir(dir);
}
}

33. THE ASYNC ITERATOR DESIGN
▪ The natural composition of sync iterators and promises; fits well with JS
▪ async for-of
▪ async generators
▪ Single-consumer async iterator, plus async iterables = async iterator
factories (just like for sync)
▪ Consumer-controlled rate of data flow
▪ Request queue of next() calls
▪ Automatic backpressure
▪ Implicit buffering allows late subscription

34. A SPECIAL CASE OF ASYNC ITERATORS:
I/O STREAMS

35. READABLE STREAMS
const reader = readableStream.getReader();
reader.read().then(
({ value, done }) => {
if (done) {
console.log("The stream is closed!");
} else {
console.log(value);
}
},
e => console.error("The stream is errored!", e)
);
https://streams.spec.whatwg.org/

36. READABLE STREAMS
async for (const chunk of readableStream) {
console.log(chunk);
}
https://streams.spec.whatwg.org/

37. READABLE STREAMS
https://streams.spec.whatwg.org/
readableStream
.pipeThrough(transformStream1)
.pipeThrough(transformStream2)
.pipeTo(writableStream)
.then(() => console.log("All data successfully written!"))
.catch(e => console.error("Something went wrong!", e));

38. THE READABLE STREAM DESIGN
▪ Focused on wrapping I/O sources into a stream interface
▪ Specifically designed to be easy to construct around raw APIs like kernel read(2)
▪ A variant, ReadableByteStream, with support for zero-copy reads from kernel
memory into an ArrayBuffer.
▪ Exclusive reader construct, for off-main-thread piping
▪ Integrate with writable streams and transform streams to represent the
rest of the I/O ecosystem
▪ Readable streams are to async iterators as arrays are to sync iterators

39. READABLE STREAMS IN ACTION

40. ASYNC ITERATORS ARE “PULL”

41. WHAT ABOUT “PUSH”?

42. REMEMBER OUR SCENARIOS
▪ I/O streams
▪ Directory listings
▪ Sensor readings
▪ Events in general
▪ …

43. OBSERVABLES
const subscription = listenFor("click").subscribe({
next(value) { console.log("Clicked button", value) },
throw(error) { console.log("Error listening for clicks", e); },
return() { console.log("No more clicks"); }
});
cancelButton.onclick = () => subscription.unsubscribe();
https://github.com/zenparsing/es-observable

44. THE OBSERVABLE DESIGN
▪ An observable is basically a function taking { next, return, throw }
▪ The contract is that the function calls next zero or more times, then one of either
return or throw.
▪ You wrap this function in an object so that it can have methods like map/filter/etc.
▪ Observables are to async iterators as continuables are to promises
▪ You can unsubscribe, which will trigger a specific action
▪ Push instead of pull; thus not suited for I/O
▪ No backpressure
▪ No buffering

45. OBSERVABLE DESIGN CONFUSIONS
▪ Has a return value, but unclear how to propagate that when doing
map/filter/etc.
▪ Tacks on cancelation functionality, but unclear how it integrates with
return/throw, or really anything
▪ Sometimes is async, but sometimes is sync (for “performance”)

46. PULL TO PUSH IS EASY
try {
async for (const v of ai) {
observer.next(v);
}
} catch (e) {
observer.throw(e);
} finally {
observer.return();
}

47. PUSH TO PULL IS HARD
Too much code for a slide, but:
▪ Buffer each value, return, or throw from the pusher
▪ Record each next() call from the puller
▪ Correlated them with each other:
▪ If there is a next() call outstanding and a new value/return/throw comes in, use it
to fulfill/reject that next() promise
▪ If there are extra value/return/throws in the buffer and a new next() call comes in,
immediately fulfill/reject and shift off the buffer
▪ If both are empty, wait for something to disturb equilibrium in either direction

48. IT’S UNCLEAR WHETHER OBSERVABLES
PULL THEIR OWN WEIGHT

49. BEHAVIORS
const gamepads = navigator.getGamepads();
const sensor = new sensors.AmbientLight({ frequency: 100 });
const bluetooth = doABunchOfWebBluetoothStuff();
requestAnimationFrame(function frame() {
console.log(gamepads[0].axes[0], gamepads[0].axes[1]);
console.log(gamepads[0].buttons[0].pressed);
console.log(sensor.value);
console.log(bluetooth.value);
requestAnimationFrame(frame);
});

50. BEHAVIOR DESIGN SPACE
▪ Continuous, not discrete (in theory)
▪ Polling, not pulling or pushing
▪ The sequence is not the interesting part, unlike other async plurals
▪ Operators like map/filter/etc. are thus not applicable
▪ Maybe plus, minus, other arithmetic?
▪ min(…behaviors), max(…behaviors), …?
▪ What does a uniform API for these even look like?
▪ Could such an API apply to discrete value changes as well?

51. THINK ABOUT BEHAVIORS MORE

52. WRAPPING UP

53. singular plural
sync
async
values
Either
exceptions
primitives iterators
iterables
generators
reverse iterators
arrays
continuables
promises
tasks
async iterators
streams
observables
behaviors
event emitters

54. THINGS TO THINK ABOUT
▪ Representing the action vs. representing the result
▪ Lazy vs. eager
▪ Push vs. pull vs. poll
▪ Mutable by consumers vs. immutable like a value
▪ Allow late subscription or not
▪ Multi-consumer vs. single-consumer
▪ Automatic backpressure vs. manual pause/resume
▪ Micro-performance vs. macro-performance

55. CHECK OUT GTOR
https://github.com/kriskowal/gtor/

56. SHOULD YOU EVEN CARE?

57. NONE OF THIS IS URGENT,
EXCEPT WHEN IT IS

58. THIS IS THE
ASYNC FRONTIER,
AND YOU ARE THE
PIONEERS
Thank you!
@domenic