WebAssembly: A New Compiler Target for the Web [video] | Hacker News Reader

WebAssembly: A New Compiler Target for the Web [video]

youtube.com

62 pointsjandem13 comments

I wish webassembly was already here. I honestly can't wait for more language choice for targeting the browser DOM.

I believe this will bring a revolution in client side apps on the browser. Ultimately fulfilling the goal Java aimed for, but never succeeded at reaching.

WebAssembly doesn't really add any more language choices for the DOM directly. At least not yet:

https://github.com/WebAssembly/design/blob/master/GC.md

You're right that it's not part of the MVP, but it's pretty clear that it's a feature that is planned and will probably follow very quickly.

I don't think WebAssembly's main target is the DOM (although there seems to be planned support for accessing it).

A VM + Canvas is the primary use case, from what I had gathered.

Somehow, I think we'll regret this. Running low-level programs in the browser hasn't gone well in the past. We got rid of Flash. We got rid of Java applets. Now this. Especially since the use cases are weak. Even WebGL doesn't get used much. Yes, you can do (cool thing) in the browser. But that will be rare.

Has the first WebAssembly exploit come out yet?

There were definitely major problems with Flash and Java. WebAssembly has learned from those, though:

* WebAssembly is an open standard, unlike Flash

* WebAssembly has multiple compatible open source implementations, unlike Flash (and Java, back in the day)

* WebAssembly is optimized for very fast startup, unlike Java

* WebAssembly is designed to integrate with JavaScript and the web in a proper way, unlike Flash and Java

* WebAssembly is designed to have the same security model as JavaScript and in fact to reuse existing hardened code as much as possible, minimizing the security risk.

Not that WebAssembly is perfect, nothing is, but it's aimed to fix the huge issues that previous related technologies had.

And the use cases are very important: things like games, photo editing, etc., all can benefit from high-speed execution of code on the web. WebAssembly is a response to developer requests.

It certainly isn't integration with JavaScript that held Java back, as Java and JavaScript are about equally old. If I have to believe Wikipedia, both are from May 23, 1995, but I don't trust that date for JavaScript, as Wikipedia also says JavaScript was designed in two weeks in May 1995. Internet time is fast, but not that fast.

JavaScript seems to have shipped as LiveScript in September 1995, but https://en.m.wikipedia.org/wiki/JavaScript#Version_history also has March 1996 as date for the first version. Java seems to have been shown to the world in beta form in May 1995, with the first JDK available on January 23, 1996 (https://en.m.wikipedia.org/wiki/Java_version_history), so Java seems a tad older than JavaScript.

I think a few important 'features of WebAssembly', compared to Java are that WebAssembly is going to come out at a time when:

* machines are cheap and fast enough.

* bandwidth is cheap and plenty enough.

* the world knows you need open standards to conquer the world (or, cynically, that getting hold of data is the primary objective nowadays)

JS was indeed developed in just 10 days[1]. It was a way for netscape to differentiate itself. It is also why it has so many... quirks.

1. https://www.w3.org/community/webed/wiki/A_Short_History_of_J...

For me that is the believable part; it's easy to hack together something JavaScript-like using lex and yacc and also probably not too hard to bolt it onto your own browser. It would be reasonably bug-free, too, as there was no standard to test it against.

I do find it hard to believe that Netscape managed to decide this was a (minimal) viable product, produce a press release, and present it to the world in the remaining (at most 21, including Memorial Day, but according to Wikipedia at most 13) days in May.

On the other hand, Netscape may have heard rumors about Sun announcing Java (quite possible if Sun wanted to have a Netscape plugin to demo at launch) and decided they had to have something on the same day. I can't find that on the web, though.

EDIT: http://www2.ldc.lu.se/temadag95/javascript.txt and http://www.phase3.net/sun-announces-java-at-sunworld/ seem to show that the May 23 date in Wikipedia is correct for Java, but incorrect for JavaScript. That date should be December 4, 1995.

As far as I understand this has the exact same security model as Javascript, and it can do exactly as much as Javascript.

Is there any security sense in which this is lower level than javascript (asm.js)?

I think you're right that being "high"/"low" level is basically irrelevant for theoretical security; only the primitive IO instructions matter, and if some combination of those instructions is a security risk, then it doesn't really matter how that combination comes about (via functional programming and monads, via OO service architectures, via actors, via bit-twiddling and gotos, etc.).

On the other hand, I can imagine "low level" (i.e. low abstraction) programs having a harder time implementing their own security models; e.g. trying to segregate third-party code, etc. simply because it's harder to reason at a level so much removed from your application domain. Having security-conscious higher level languages compile into WA would alleviate this though.

The security issues with things like Flash and Java is that they increase the attack surface drastically. Furthermore, they come from different companies from the web browser, and often with their own updating mechanisms.

Even if your browser developers are professional and strict about security and update rollouts, the plugin developers of plugin X might be pretty lax and slow to roll out a fix when there is an exploit dropped. Even if you shame them into getting better, the problem can start over with plugin Y instead, and so on.

It's entirely possible that WebAssembly will also increase the attack surface, but I seriously doubt it will be at the same scope as the third party plugin providers. It will be developed by the same developers who developed the JavaScript engine of the browser.

Are you uncomfortable with asm.js because webasm is heavily based on being a compact evolution of whats already there.

Reply on news.ycombinator.com