The ES6 promises specification proposal that defines the standard JavaScript Promise API for asynchronous operations.
Promises-unwrapping is the original specification proposal that became the ECMAScript 6 Promise standard. It defines the complete API and behavior for Promise objects in JavaScript, providing a standardized way to handle asynchronous operations through states (fulfilled, rejected, pending) and chainable reactions. This proposal solves the problem of inconsistent promise implementations by establishing a unified specification for deferred computations.
JavaScript language implementers, specification authors, and library developers who need to understand or implement the Promise standard correctly. It's also valuable for advanced developers who want deep insight into promise mechanics.
This proposal provides the authoritative reference for Promise behavior, ensuring interoperability across environments. Developers choose it because it defines the exact semantics that all conforming JavaScript engines must follow, eliminating guesswork and implementation divergence.
The ES6 promises spec, as per September 2013 TC39 meeting
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
This is the original proposal that evolved into the ECMAScript 6 Promise standard, providing the definitive reference for all conforming JavaScript implementations.
Explicitly defines the three mutually exclusive states—fulfilled, rejected, and pending—with precise transition rules, eliminating ambiguity in promise behavior as detailed in the Promise Objects section.
Designed to be subclassable with constructor inheritance, evidenced by the NewPromiseCapability abstract operation that works with any constructor following Promise conventions.
Includes all static methods like Promise.all, Promise.race, Promise.resolve, and Promise.reject, ensuring full specification of the promise API with detailed abstract operations.
This is a specification document only, not a library, so it cannot be directly used in code without an actual promise implementation or polyfill.
The README explicitly states it's a staging ground and recommends referencing the official ECMAScript draft spec instead, making it less reliable for current development.
Written in dense specification language with abstract operations like PromiseCapability Records, it's challenging for developers unfamiliar with ECMAScript internals to parse.