I think the motivations here are noble, but what troubles me is that this is trying to fix two problems with one big risky hammer. The problems are 1. JS has v

I think the motivations here are noble, but what troubles me is that this is trying to fix two problems with one big risky hammer. The problems are 1. JS has various annoying parts, like how comparisons work, or that x.y returns undefined if y isn't a property, etc. 2. JS is sometimes hard to optimize to Java-like speed. I think (1) is already well underway to being solved, through compiling to JS. Things like TypeScript, CoffeeScript, ClojureScript, Elm, Scala.js, GWT, JSIL, Emscripten, etc. Those let you compile whatever language you want, without all the JS oddities. You can use anything from a familiar language like Java or C# or C++ or Scala, to an almost-JS language like TypeScript. People aren't really limited by JavaScript's oddities anymore. It's true these languages sometimes have downsides when compiled, e.g. due to limitations on debugging. But progress is being made there and things are pretty good already. (2) is indeed something also worth solving. But I'm not sure the solution is the same solution, so trying to fix both at once sounds far, far riskier. For example, a lower-risk way to help with the perf issues might be work piece by piece, perhaps starting by proposing a hole-less array type for JavaScript, to avoid the sparse array problem.