The reason ES4 was killed was that there was no consensus between the stakeholders. It would have been a breaking change, making conforming engines incompatible with all existing JavaScript code.
How well major breaking changes like that work out on the web can be seen by the massive success (cough) of XHTML -- I dare you find me one notable site correctly using XHTML with the appropriate MIME type (rather than just sending XHTML as HTML tagsoup using `text/html`).
Web Assembly works because it is not a breaking change to JavaScript. It's actually defined in a way that is mostly orthogonal to JavaScript -- it shares some of the APIs but most likely there will be (low-level) APIs only Web Assembly code can use and some (high-level) APIs that only exist for JS.
I'm not advocating for breaking changes, in fact static type checking in ES4 was optional, the language remained just as dynamic if you wanted to use it that way.
Re:ECMAScript 2017 Language Specification
by shinypotatoe on Wednesday July 12, 2017 @01:02AM
(#14750220)
Checkout TypeScript. It's great.
I know, but it's not JavaScript.
For the most part it is JavaScript. JavaScript is valid Typescript, because Typescript is a superset. Typescript just gets you type annotations and "future" JavaScript features, none of which you're forced to use.
Yes I know, but again, it's not JavaScript and there will always be headaches here and there.
For example: https://vuejs.org/v2/guide/typescript.html
Re:ECMAScript 2017 Language Specification
by roboguy12 on Wednesday July 12, 2017 @04:29PM
(#14756348)
And, when you compile it to JavaScript, you can choose the target language level. So, you could write Typescript and have it compile such that in essence, all it does is strip out the type annotations.
I'd like to see TC39 tackling the big problems of JS like the lack of static type checking. I'm tired of looking at a method and having to figure out if it is expecting a string, or an object.
We had EcmaScript4 about 10 years ago with plenty of great features but TC39 killed it. And yeah, it probably made sense since the browser vendor landscape was very different back then. Today it would be possible to implement significant changes to the language much like the WebAssembly initiative.