s3th

The police officers responsible for the murders of countless innocent Black people.

If early error is deferred then it's no longer early... that's all I meant by skipped. It still is a semantic change that's unrelated to a binary AST.

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.

[0]: https://github.com/syg/ecmascript-binary-ast/#-2-early-error...

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].

Disclaimer: I work on the V8 team.

[0]: https://twitter.com/bmeurer/status/834677090381348865

Would appreciate a bug report if you have a repo: https://bugs.chromium.org/p/v8/issues/entry?template=WASM%20...

Here's how to interact with browser APIs and import/export functions via the WebAssembly JS API: http://webassembly.org/getting-started/js-api/

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.

[0]: http://webassembly.org/docs/future-features/#source-maps-int...

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).

The more detailed post is here: https://news.ycombinator.com/item?id=11598245

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.

See my comment below: https://news.ycombinator.com/item?id=11564354

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].

(Disclaimer: I'm a PM on the V8 team.)

[0]: https://twitter.com/addyosmani/status/699976753255751681 [1]: https://groups.google.com/forum/#!topic/strengthen-js/ojj3TD...

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.

(Disclaimer: I'm a PM on the V8 team.)

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.

[0]: https://github.com/WebAssembly/design/blob/master/Web.md#web... [1]: https://github.com/WebAssembly/design/blob/master/NonWeb.md

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.

[0]: https://groups.google.com/a/chromium.org/forum/#!topic/blink...

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].

[0]: https://www.w3.org/community/webassembly/

[1]: https://github.com/WebAssembly/design/blob/master/TextFormat...

[2]: https://github.com/WebAssembly/design/blob/master/Tooling.md

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

Something related to debugging? Perhaps you came across this thread? https://github.com/nodejs/node/issues/2546#issuecomment-1893...

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.

[0]: https://github.com/kripken/emscripten/wiki/WebAssembly

[1]: https://github.com/webassembly/binaryen

Yes! It's the compatibility of more than one implementation, each running the same WebAssembly binary that makes me so excited about this milestone.

It's not too late! The wasm binary encoding is open to change up until the browsers ship a stable MVP implementation (then the plan is to freeze the encoding indefinitely at version 1).

The primary advantage of LEB128 is (as you mentioned) that it's a relatively common encoding. PrefixVarint is not an open source encoding IIUC.

We'll do some experiments in terms of speed. If the gains are significant we may be able to adopt something similar (this [0] looks like a related idea).

Thanks for the suggestion.

[0]: http://www.dlugosz.com/ZIP2/VLI.html

The web is an amazing content delivery vehicle, I totally agree! There's a whole class of content I want to be able to just `wget` and be done with it.

The goal of WebAssembly is to open up the reach and easy user experience of the web browser to new types of applications that just aren't possible to build efficiently with current tech.

We're also making sure that wasm is a first-class citizen of the open web: see, for example, our thoughts around ES6 module interop, GC + DOM integration, and view-source to see the textual encoding of wasm [0][1].

[0]: https://github.com/WebAssembly/design/blob/master/Web.md

[1]: https://github.com/WebAssembly/design/blob/master/TextFormat...

(Disclaimer: I work on V8.)

As we get closer to having a WebAssembly demo ready in multiple browsers, the group has added a small little website on GitHub [0] that should provide a better overview of the project than browsing the disparate repos (design, spec, etc.).

Since the last time WebAssembly hit HN, we've made a lot of progress designing the binary encoding [1] for WebAssembly.

(Disclaimer: I'm on the V8 team.)

[0]: http://webassembly.github.io/ [1]: https://github.com/WebAssembly/design/blob/master/BinaryEnco...

A big difference between ES5 and ES6/7 is that the former passes through our old, highly-tuned optimizing engine Crankshaft [0] and the latter passes through our new optimizing engine TurboFan [1]. The team's expertise optimizing Crankshaft can certainly be leveraged in TurboFan, but it's not an apples-to-apples comparison. In the future, TurboFan will handle ES5 code as well.

tl;dr we're changing engines mid-flight and that has as much to do with performance differences as the ES6 features themselves.

[0]: http://blog.chromium.org/2010/12/new-crankshaft-for-v8.html [1]: http://v8project.blogspot.com/2015/07/digging-into-turbofan-...

There's definitely a lot of room for improvement. The V8 team has been working on finishing baseline implementations for all of ES6 before spending significant time optimizing particular features. But improvements are coming quickly! In the last few weeks, for example, ES6 rest parameters got 8-10x faster and Object.assign() is now as fast as _.assign() [0].

In general, we will focus on improving the performance of the most-used features first. Arrow functions, generators, etc. are high on the list.

[0]: https://twitter.com/addyosmani/status/699976753255751681

(Disclaimer: I'm a PM on the V8 team)

We're working on updating Kangax, but V8 now has 92% ES6 coverage in Chrome Canary (on track for shipping in Chrome M49)!

Disclaimer: I work on V8

If you want to test out ES2015 features (incl. proxies) coming soon in V8, you can download Chrome Canary and turn on the Experimental JavaScript flag (under chrome://flags). With the flag enabled, Chrome reaches 91% percent on the Kangax table [0]. We're working hard to turn these features on by default as soon as possible.

[0]: https://kangax.github.io/compat-table/es6/

(Disclaimer: I'm a PM on the V8 team)

Agreed. In addition I hope they provide a blog post about best practices w.r.t. vendoring in order to explain the problem and solution in more depth to a wider audience than the initial design doc.

Check out the last paragraph of "Is WebAssembly only for C/C++ Programmers?" in the FAQ [0]. The tl;dr is that you'll be able to port a Python interpreter (that is itself written in C) to WebAssembly from day 1, but a more robust solution that relies on WebAssembly GC will have to wait until after the MVP.

[0]: https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...