Things I’ve Misunderstood About Promises

Since I’ve been mucking about with JavaScript more, I’ve discovered that for some reason the Promise pattern is a profoundly unintuitive one to me. In my quest to accurately model their semantics in my mind, I’ve read through the A+ spec and written a couple of partial Promise implementations of my own. I still don’t feel like I’ve completely nailed it down.

Here is an incomplete list of my misunderstandings (so far) about Promises.

1. Promises are not boxes that values appear in.
2. Promises are not really about values at all.
3. Promises are also not about the work.
4. Or about managing work.
5. They are a signaling mechanism off to the side of the work.
6. Promises aren’t about giving you something to wait on.
7. You don’t know when a Promise will be fulfilled; you only get to say what should happen if and when it’s fulfilled.
8. A Promise is not a pure data structure. A complete implementation requires a deferral mechanism (e.g. a way to kick TODOs into a global reactor next-tick queue).
9. Promises are not about pulling. They are about pushing.
10. Promises will not make your async code visualizable as a nice clean dataflow diagram (look to actors and channels for that).
11. Promises are terribly named. They give no assurance about anything. (Cynical readers might argue that this makes them exactly like real-world promises).
12. Promises do not manage or perform work. A chain of promises:
    1. Signals when new work can be started.
    2. Channels results from one operation to the next.
13. Of the two, only the signaling part is essential. The channeling part can be and is often unused.
14. .then() is not an operation on a Promise. .then() is a specialized constructor of new Promises.
15. Promises are causality insertions.