i'm very skeptical about the benefits of a binary JavaScript AST. The claim is that a binary AST would save on JS parsing costs. however, JS parse time is not just tokenization. For many large apps, the bottleneck in parsing is instead in actually validating that the JS code is well-formed and does not contain early errors. The binary AST format proposes to skip this step [0] which is equivalent to wrapping function bodies with eval… This would be a major semantic change to the language that should be decoupled from anything related to a binary format. So IMO proposal conflates tokenization with changing early error semantics. I’m skeptical the former has any benefits and the later should be considered on its own terms.
Also, there’s immense value in text formats over binary formats in general, especially for open, extendable web standards. Text formats are more easily extendable as the language evolves because they typically have some amount of redundancy built in. The W3C outlines the value here (https://www.w3.org/People/Bos/DesignGuide/implementability.h...). JS text format in general also means engines/interpreters/browsers are simpler to implement and therefore that JS code has better longevity.
Finally, although WebAssembly is a different beast and a different language, it provides an escape hatch for large apps (e.g. Facebook) to go to extreme lengths in the name of speed.
We don’t need complicate JavaScript with such a powerful mechanism already tuned to perfectly complement it.
This architecture switch will have no impact on the V8 API. We're working closely with the Node.js team to make sure that this is a smooth transition and early results look as though there are significant performance benefits [0].
We're very interested in exploring this space. It's possible that this capability is exposed through an extension of sourcemaps [0]. Definitely curious to hear more ideas and feedback in this space.
The main benefit would be shipping a single WebAssembly module to target client and server (e.g. the same benefit of sharing JS between the browser and Node).
As pointed out below, technically "ECMAScript® 2015" is "ECMA-262 6th Edition", so the numbers still exist in some form. It's a really difficult balance between readability, matching most-common usage in the community (e.g. Kangax still uses ES6), and trying not to mix nomenclatures in the process.
The gutters are a little small on my iPhone, but I can see all the text. Want to send a screenshot to seththompson [at] google [dot] com? I'll see how much I can fix.
It's not so simple as (paraphrasing) 'ES6 is sugar and makes ES5 regress in speed.' Generally, "make it work right, then make it work fast" is actually a pretty good strategy for implementing new features.
This is a case of "make it work right; then make it work fast". ES2015 performance will improve with time (we've already made 8-10x improvements on certain features) [0].
Strong mode work was stopped for a variety of nuanced reasons detailed here [1].
You can see comparisons between ES5 and ES2015 feature equivalents, as well as comparisons with older versions at https://kpdecker.github.io/six-speed/.
It's important to remember that implementation of ES2015 is merely the first pass; optimization comes soon after and will rapidly improve performance. General, absolute numbers (e.g. "ES2015 is X% slower than ES5") are usually either nonspecific or soon out-of-date. The best advice is to revise your performance assumptions frequently based on real code.
r.e. ES5 side-effects: ES2015 adds language features and changes semantics of existing features in ways that necessarily change the execution path of code (including ES5 code). When V8 first tried implemented proper (ES2015) RegExp subclassing, for example, it regressed existing (ES5) RegExp performance by ~70%, but a subsequent optimization reduced the regression to ~9%. This is an unfortunate consequence of a rapidly evolving spec, but these cases are exceptional and will get better over time.
WebAssembly is a low-level runtime currently targeting the existing web platform. There are no plans to add wasm-specific web platform APIs [0]. You will not gain existing capabilities other than those already exposed to mobile websites. Non-web embeddings will be possible [1], but are not currently being developed.
We just sent out an intent to ship this week! [0] They're trickier to implement than other ES6 features since they require coordination with the Blink side of Chromium.
WebAssembly is an open source runtime developed under the governance of a W3C Community Group [0]. The binaries that get sent over the wire are simply more efficient ways to pack existing types of code. We will soon have a textual encoding that makes modules easy to introspect [1] and we have a long list of tooling plans to make sure that the web stays open and debuggable [2].
WebAssembly doesn't intend to replace jQuery, D8, or CSS. However, we definitely plan to enable efficient DOM access. Doing so requires supporting some sort of native Garbage Collection, as well as the concept of opaque reference types. See more here: https://github.com/WebAssembly/design/blob/master/GC.md
The Emscripten toolchain can be used to produce both WebAssembly and asm.js from the same codebase [0]. There are also the nascent beginnings of a translation tool from WebAssembly to asm.js here [1] (look for wasm2asm). Ultimately, it should be possible to write a streaming polyfill for WebAssembly, but no one has gotten around to making anything suitable for production yet. You're better off producing a separate fallback asm.js bundle for now.