s3th
Joined 13 years ago
Karma
325
Submissions
51
Member since
Mar 25
http://seththompson.org
View on Hacker NewsRecent submissions
Comment · 5 years ago
The police officers responsible for the murders of countless innocent Black people.
Comment · 9 years ago
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.
Comment · 9 years ago
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...
Comment · 9 years ago
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.
Comment · 10 years ago
Would appreciate a bug report if you have a repo: https://bugs.chromium.org/p/v8/issues/entry?template=WASM%20...
Comment · 10 years ago
Here's how to interact with browser APIs and import/export functions via the WebAssembly JS API: http://webassembly.org/getting-started/js-api/
Comment · 10 years ago
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...
Comment · 10 years ago
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).
Comment · 10 years ago
The more detailed post is here: https://news.ycombinator.com/item?id=11598245
Comment · 10 years ago
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.