Live data from Hacker News

WebAssembly: Mozilla Won

robert.ocallahan.org

11–20 of 375 posts

Re: WebAssembly: Mozilla Won

#11
post #3

I think this is a good thing. It probably prevented a new DirectX style dark age of the web. Probably! I don't pretend to be able predict what path companies would have went in the next few years. It's really good to see that there is a will to agree and that there is more than one player. Could always be more, also for keeping standards sane. (WebSQL officially failed because there isn't more variety)

> It probably prevented a new DirectX style dark age of the web.

Do you mean ActiveX rather than DirectX? As in the OLE and COM technology for embedding user interface components on Windows?

Re: WebAssembly: Mozilla Won

#12
post #5

This article in few lines lists key differences between PNaCl and WebAssembly: --- WebAssembly defines no new platform APIs other than some APIs for loading and linking WebAssembly code, relying on standards-based Web APIs for everything else. WebAssembly differs from asm.js by defining a bytecode format with some new operations JS doesn't have, so some spec work was required (and has been done!). Like asm.js, WebAss…

I don't really understand what "the compiler is trusted" means. What could an evil compiler really do? Maybe add a spinning loop to waste CPU cycles, but that can be done in JS too.

Add extraneous code?

Re: WebAssembly: Mozilla Won

#13
post #5

This article in few lines lists key differences between PNaCl and WebAssembly: --- WebAssembly defines no new platform APIs other than some APIs for loading and linking WebAssembly code, relying on standards-based Web APIs for everything else. WebAssembly differs from asm.js by defining a bytecode format with some new operations JS doesn't have, so some spec work was required (and has been done!). Like asm.js, WebAss…

I don't really understand what "the compiler is trusted" means. What could an evil compiler really do? Maybe add a spinning loop to waste CPU cycles, but that can be done in JS too.

Both PNaCl and WebAssembly need a compiler to a get the machine code run by CPU, but the output of PNaCl is checked via NaCl verifier while nothing checks that the output of WebAssembly is safe machine code.

As the verifier for NaCl is likely to be an order magnitude smaller than a component in WebAssembly implementation that verifies and compiles the bytecode to the native code, PNaCl attack surface is much smaller.

Re: WebAssembly: Mozilla Won

#14
post #10

Earlier quoted context omitted.

> but it is interesting to see a counter-argument to the Mozilla/Firefox just apes Chrome story I think looking at Quantum ( https://wiki.mozilla.org/Quantum ) and Phonton ( https://www.ghacks.net/2017/03/31/firefox-photon-new-design-... ) this becomes even more clear.

I agree that Quantum is exciting, but if there's anything interesting about Photon the article you linked really didn't bring it out. What aspects were you thinking of?

I think it's just used here as an example of Moz://a not aping Chrome, by moving their UI even further away.

Re: WebAssembly: Mozilla Won

#15
post #5

This article in few lines lists key differences between PNaCl and WebAssembly: --- WebAssembly defines no new platform APIs other than some APIs for loading and linking WebAssembly code, relying on standards-based Web APIs for everything else. WebAssembly differs from asm.js by defining a bytecode format with some new operations JS doesn't have, so some spec work was required (and has been done!). Like asm.js, WebAss…

I don't really understand what "the compiler is trusted" means. What could an evil compiler really do? Maybe add a spinning loop to waste CPU cycles, but that can be done in JS too.

The security model for nacl is afaik that you run almost arbitrary native code. It was compiled by someone else, your input is basically machine code that you don't know anything about except for some please-dont-break-my-sandbox checks.

With asm.js, your input is javascript code which can't do all the weird things that native code can do, and you're in charge of generating the native code that ultimately gets executed (much like the traditional JIT setup), so assuming you didn't fuck up the translation, you get to assume it can't do anything that javascript code couldn't have done to begin with, relaxing your sandboxing requirements around, like, arbitrary memory accesses or syscalls.

Re: WebAssembly: Mozilla Won

#17
I don't really like the headline. I don't want Mozilla to "win", and I don't think Mozilla wants to either; I want the open web to flourish.

That said, the article is very informative, and well-balanced. It was really good of Google and the other browsers to join the wasm bandwagon. And yes, although as the author himself points out, "proclaiming a "winner" is unimportant or even counterproductive", Mozilla does deserve a lot of credit here.

Re: WebAssembly: Mozilla Won

#18
post #17

I don't really like the headline. I don't want Mozilla to "win", and I don't think Mozilla wants to either; I want the open web to flourish. That said, the article is very informative, and well-balanced. It was really good of Google and the other browsers to join the wasm bandwagon. And yes, although as the author himself points out, "proclaiming a "winner" is unimportant or even counterproductive", Mozilla does dese…

It is joke - we had 'Chrome won' the other day. There is a hidden point being made which you would probably agree with.

Re: WebAssembly: Mozilla Won

#19
post #17

I don't really like the headline. I don't want Mozilla to "win", and I don't think Mozilla wants to either; I want the open web to flourish. That said, the article is very informative, and well-balanced. It was really good of Google and the other browsers to join the wasm bandwagon. And yes, although as the author himself points out, "proclaiming a "winner" is unimportant or even counterproductive", Mozilla does dese…

Potentially the article title is a reference to a story that was posted a few days ago called, Chrome Won.

Re: WebAssembly: Mozilla Won

#20

Is there anywhere a "hello world" or simple DOM modification program which I can implement with WebAssembly?

I made this factorial compile-and-run example in NodeJS:

https://gist.github.com/Recmo/e0b6911992897c5f51c38fda822537...

To run it you need at least Node 8.0.0 and the `--expose-wasm` flag.

Sorry for using modern JS, you will need to use babel-node to run it. Or you can port it to old fashioned JS.

Post reply on HN