From the author
Teaching programming, there's always a dilemma between explaining how it is and how it should be.
There's rarely a place and time to cover both. This dilemma is especially painful when it comes to
Should we follow a bad specification or teach you some better async patterns inevitable departing
from a widespread standard? To give you an example, promises A+ introduce state and fate concepts:
Promises have two possible mutually exclusive fates: resolved, and unresolved.
- A promise is resolved if trying to resolve or reject it has no effect, i.e. the promise has been "locked in" to either follow another promise, or has been fulfilled or rejected.
- A promise is unresolved if it is not resolved, i.e. if trying to resolve or reject it will have an impact on the promise.
A promise whose fate is resolved can be in any of the three states:
- Fulfilled, if it has been resolved to a non-promise value, or resolved to a thenable which will call any passed fulfillment handler back as soon as possible, or resolved to another promise that is fulfilled.
- Rejected, if it has been rejected directly, or resolved to a thenable which will call any passed rejection handler back as soon as possible, or resolved to another promise that is rejected.
- Pending, if it has been resolved to a thenable which will call neither handler back as soon as possible, or resolved to another promise that is pending.
WTF? It can take you years to realize that all this mess really comes from the auto-flattening
mechanics of A+ promises. Remove it and get 3 predictable states: "pending", "resolved", and "rejected" with
absolutely no need for "fates", "settlements" and extra terms like that.
It's not a hindsight, many people were vocal about the design issues of A+. For example, you can check
this historical thread. Judge for yourself.
In the upcoming Expert tutorial we'll redesign promises from scratch, so we'll have an opportunity
to look at the sources and discuss engineering flaws of A+ in details. Meanwhile, we just ask you to follow
the first part and judge for yourself. It's really a challenging goal to skim over controversial moments,
to keep explanations simple, and to actually teach something useful and portable at the same time.
Yet we believe the goal is achieved in this tutorial.
Bad or Not – sometimes you won't have a choice to decide. And Promises, as a topic, are too important
to just skim over them. To re-emphasize our approach: this is not a tutorial on Promises A+ exclusively.
people who like to enrage about "something's incorrect on the internet".
In this tutorial we deliberately decided to avoid "real" APIs like Node's FS or Browser's
Fetch in favor of "abstract"
setTimeout / setInterval-based code.
There are three decisive reasons for this.
1. The best learning model is to learn "one thing at a time". Learning an API and learning
its underlying concepts are two different tasks. Learning how to combine those concepts together
and apply them to solve a real-world problem is a third task.
2. Real APIs are almost always saturated with extra "noise". For example,
fetch will require you to
always apply two promise calls in a row, so you may take it as a norm (which it isn't).
FS.readFile will require you to learn buffers, to think about filesystem specifics. Again, basically,
you have to switch from the original intent of "learning some async" to learning stuff that slows
you down and may even be irrelevant (assuming so many possible JS application fields).
3. Timeouts and intervals aren't only extremely important on themselves, they are perfect as stubs
for actual file, db, network, whatever "real" APIs. You'll also find them absolutely indispensable in
tests, library code and many other key places. You can't overpractise them.
To summarize, we believe that solid knowledge of async patterns should be built upon abstractions
(i.e. ideas) rather than copy-paste driven "realistic" snippets. You'll have zero problems with