Javascript isn't bytecode. It's a language that people do actually write and have to deal with on its own terms.

Transpiling to javascript is a hack to make up for percieved deficiencies in the language itself - but as with any other language, javascript can still be improved upon and evolve.

Requiring that anyone who wants to write javascript for the web do so through a Java or C compiler is actually the worst option.

Because many legal constructs in javascript preclude various optimisations that could otherwise deliver near-native performance.

Compiling a more rigid language to JS doesn't help with this, because the runtime and JIT compiler has no way to know what the original constraints were, so it has to remain open to the possibility that this is plain old JS and any of those weird and unoptimisable -- but legal! -- constructs may occur.

Of course, you can write runtimes and JIT compilers with optimistic fast paths, that assume certain constraints apply and bail out to slower paths if they encounter something they can't handle. But this only gets you so far. It adds a lot of complexity to your implementation, and provides no clue to developers that they've violated a particular constraint and their code is running 10x slower than it could do. Furthermore, different runtime implementations from different vendors may have different heuristics and fast path behaviours.

Having a standardised subset of the language, marked by a backwards compatible pseudo-pragma (like 'use strong') lets developers opt in to explicit constraints that enable greater optimisation. These constraints are common across different runtimes, properly documented, and are enforced by fail-early checking. The latter gives clear feedback to developers when they violate a constraint, and means the fast-path code can work without escape hatches, because the code it's running is guaranteed not to violate the constraints.

You can compile to asm.js if you care about performance that much.

They explain that, they are aiming for faster execution and less bugs. Faster execution requires that the VM and the language changes. They tried this with Dart but that hasn't become popular, now they try again with something different and with smaller changes.

Most (all?) of the improvements listed in the document are already present in Dart. You can use them today. Good to see that these may also filter into JS in a few years time.

Google is capable on working on improving JS and Dart simultaneously. You can see Dart as a test ground for features that may make it to JS. Cross-browser improvements made to JS will also benefit the Dart ecosystem, as it is a compile to JS platform.

Don't expect Dart to disappear any time soon. Despite popular rhetoric, Google actually has a good history of supporting its web programming platforms, for example GWT and Closure.

Great idea, the web need more help to fragment more efficilently. TypeScript, Flow and CoffeScript aren't enough. We need moar langages, so you can't find two web developers that use the same !

Fragmentation at this level is even annoying. Heck, I might use ClojureScript in the near future. But there are two facts. 1) At the end of the day everything is literally just JavaScript. 2) If a person is working on X Transpiled Language (XTL) then they could work in JavaScript.