Stage 3: Browser Early Adoption— Dave Herman (@littlecalculist) July 31, 2015
Official Description: "Candidate"
At this point, implementations have expressed interest in the feature. In practice, proposals move to them level with at least one browser implementation or a high-fidelity polyfill or transpiler.
Stage 3 requires complete spec text, and requires both the feature's reviewers and the spec editor to sign off on the spec text. The process says that "all semantics, syntax and API are completed described."
Stage 3 proposals do not necessarily make it through to Stage 4, but a Stage 3 proposal will almost always make it to Stage 4 after a period of implementation effort.
SIMD.js is an example of a feature that made it to Stage 3 and has since stalled. That said, SIMD.js may still make it to Stage 4, but the champions are currently focusing their energy on WebAssembly.
Stage 3 features are also fairly unlikely to change in very significant ways, but are still likely to change in minor ways based upon implementation feedback. For example
Function.prototype.toString reform (currently Stage 3) is unlikely to change significantly before Stage 4, but the latest TC39 meeting discussed whether to normalize
\r\n newlines into
\n, which could have a real impact on users.
Using a Stage 3 implementation means you're helping to get the feature over the finish line, and can be quite confident that the feature will eventually make it into the spec.
It still might fail, and might undergo significant changes, but the likelihood is quite low (and almost certainly would come from requests of early adopters like you).
At a high level, the previous stages were about getting consensus to work on the feature and the rough shape of it.
Stage 3 is a commitment to a much more precise description of the feature, and a belief, by the committee, that implementation experience is necessary to move the feature into the spec in Stage 4.
Next up, our series finale, Stage 4!