It didn’t address major language problems - the lack of unambiguous specification for the existing “specified” language, it failed to document the existing shipping language features that weren’t in the es3 spec. Basically it left a whole bunch of the spec ambiguous with differing engine behaviours.
On top of that, the spec was massive, included a lot of kitchen sink style accumulation of language features - I can’t recall which feature it was, but I do remember when some language showed a new feature it was almost immediately shoehorned into ES4.
And while a lot of the work was on static typing, more time was consumed by academic features of little real world value - object capabilities were a huge drain on committee time and complexity of many features.
The end result was that ES4 as a spec was far too large to implement, didn’t solve The very obvious major problems with the existing spec, and didn’t actually provide much in the way of features that people were asking for.
Incidentally the reason we have for(of) in javascript is because that would be ambiguous with the type syntax designed in ES4. The reason I couldn’t use for each was because of the other spec this article talks about: E4X.
Both of these were language specifications pushed by Mozilla and a few academic PLT folk with little-to-no interest in other implementer feedback.
At this point even ECMA has retired E4X (it’s been withdrawn, or whatever language ECMA uses for a spec that no longer exists)
> On top of that, the spec was massive, included a lot of kitchen sink style accumulation of language features - I can’t recall which feature it was, but I do remember when some language showed a new feature it was almost immediately shoehorned into ES4.
And in very many cases, too much was added too fast: the spec was _miles_ ahead of any implementation. You really don't want the spec getting too far ahead, as so many issues only become obvious during implementation, and you don't want to be building indefinitely on top of that potentially unsound base.
It didn’t address major language problems - the lack of unambiguous specification for the existing “specified” language, it failed to document the existing shipping language features that weren’t in the es3 spec. Basically it left a whole bunch of the spec ambiguous with differing engine behaviours.
On top of that, the spec was massive, included a lot of kitchen sink style accumulation of language features - I can’t recall which feature it was, but I do remember when some language showed a new feature it was almost immediately shoehorned into ES4.
And while a lot of the work was on static typing, more time was consumed by academic features of little real world value - object capabilities were a huge drain on committee time and complexity of many features.
The end result was that ES4 as a spec was far too large to implement, didn’t solve The very obvious major problems with the existing spec, and didn’t actually provide much in the way of features that people were asking for.
Incidentally the reason we have for(of) in javascript is because that would be ambiguous with the type syntax designed in ES4. The reason I couldn’t use for each was because of the other spec this article talks about: E4X.
Both of these were language specifications pushed by Mozilla and a few academic PLT folk with little-to-no interest in other implementer feedback.
At this point even ECMA has retired E4X (it’s been withdrawn, or whatever language ECMA uses for a spec that no longer exists)