4 ms·

First, the definition of JS has nothing to do with W3C. (Also for HTML, nobody really cares what W3C thinks anyway) Second, the rules of how JS is standardised

First, the definition of JS has nothing to do with W3C. (Also for HTML, nobody really cares what W3C thinks anyway) Second, the rules of how JS is standardised is that changes are actually not allowed to go into the final spec until at least two major players implement support. So this is _exactly_ how it's meant to be done. A substantial amount of discussion and consideration has already happened prior to this point, as well as implementations into transpilers (eg Babel) which people have been using for some time. This comment explains a bit further: https://news.ycombinator.com/item?id=18676717 https://news.ycombinator.com/item?id=18676717

danShumway 8y ago
Implementing support is not the same thing as turning a feature on by default. The TC39 process states that limited spec changes may still occur after a stage 3 proposal. Until a proposal reaches stage 4, it should be hidden behind a settings flag. This helps us prevent situations like flexbox, where users code against a specification and find out later that their code has broken in subtle ways. > as well as implementations into trans pourers (eg Babel) Which is meaningless. Babel is not a part of the standards process, they're free to ship anything they want. Encouraged, in fact, because that provides more in-the-wild usage data.
- BillinghamJ 8y ago
  Fixed the autocorrect error. It is super meaningful - it helps identify potential issues in real world use-cases and it creates effectively a "market" of people already using the feature who want to be able to use it without transpiling. It's also pretty rare that the implementation changes meaningfully after implementation into Babel from around stage 2.
  - danShumway 8y ago
    I should have used a more descriptive term than meaningless. Transpiler implementations do not count as hard restrictions on whether or not a proposal can change in the future. They're allowed to do whatever they want -- the fact that they create demand is very useful, but should not be seen as a restriction on whether or not the standard can evolve past that point. "It's also pretty rare" is exactly the problem. They can change. When browsers ship a non-standardized behavior that's on by default, they are effectively cementing it. It is very hard to correct a broken implementation that is live, in the wild, on normal sites. The fact that these changes are rare doesn't make it less important to follow the established process. Stage 3 is one last safety check before the feature gets turned on for everyone. What is the point of having a stage 3, if browser makers treat it as equivalent to stage 4?

danShumway 8y ago

Implementing support is not the same thing as turning a feature on by default. The TC39 process states that limited spec changes may still occur after a stage 3 proposal. Until a proposal reaches stage 4, it should be hidden behind a settings flag. This helps us prevent situations like flexbox, where users code against a specification and find out later that their code has broken in subtle ways. > as well as implementations into trans pourers (eg Babel) Which is meaningless. Babel is not a part of the standards process, they're free to ship anything they want. Encouraged, in fact, because that provides more in-the-wild usage data.

BillinghamJ 8y ago
Fixed the autocorrect error. It is super meaningful - it helps identify potential issues in real world use-cases and it creates effectively a "market" of people already using the feature who want to be able to use it without transpiling. It's also pretty rare that the implementation changes meaningfully after implementation into Babel from around stage 2.
- danShumway 8y ago
  I should have used a more descriptive term than meaningless. Transpiler implementations do not count as hard restrictions on whether or not a proposal can change in the future. They're allowed to do whatever they want -- the fact that they create demand is very useful, but should not be seen as a restriction on whether or not the standard can evolve past that point. "It's also pretty rare" is exactly the problem. They can change. When browsers ship a non-standardized behavior that's on by default, they are effectively cementing it. It is very hard to correct a broken implementation that is live, in the wild, on normal sites. The fact that these changes are rare doesn't make it less important to follow the established process. Stage 3 is one last safety check before the feature gets turned on for everyone. What is the point of having a stage 3, if browser makers treat it as equivalent to stage 4?