Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly: a binary format for the web

2ality.com

Post reply on HN
Print view View original

61–70 of 164 posts

Re: WebAssembly: a binary format for the web

#61

Post by roel_v »

ZenoArrow wrote: post #41
mstade wrote: post #25

Earlier quoted context omitted.

Merits of the contents aside, the guy presenting has a very judgmental and condescending tone making it difficult to appreciate what he's actually saying. Saying things like "this doesn't look anything like a programming language, especially if you're coming from the javascript world" or "I will explain shared memory multi-threading in a bit, especially for the front end developers" really doesn't help. I find statem…

So you're a full stack developer. Some coders are only familiar with their domain. For example, most of my coding experience has been backend database scripting stuff, I have very little familiarity with the front end. I don't see why you would get offended, he was talking to the specialists, not the generalists. You have to understand there's no shame in not knowing something outside your domain. For example, if you…

A good communicator is careful in his phrasing and keeps 'the human factor' in mind. It's not something that engineers are usually willing to admit or cater to, of course, but doesn't make it less true.

As a corollary, this is the same point that people asking 'why aren't engineers paid better' are really asking about, but can't or won't see...

Re: WebAssembly: a binary format for the web

#62

Post by roel_v »

mrec wrote: post #49
jgalt212 wrote: post #29

If the new way forward allows everyone distribute unreadable binary instead of readable, or de-obfuscatable, JavaScript, I think this definitely bad for open source and bad for innovation which depends upon stuff like: "oh, now I see how that did that. I think I can apply that technique to something else". Of course, people can release their js, python, java, et al that compiles down to WebAssembly, but because you a…

How is this any worse than minified Javascript? Without meaningful names or comments you're not much better off than you would be with WASM+disassembler.

It's the difference between a 'java decompiler' and a 'c++ decompiler'. Which is significant enough for there to be a market for commercial 'java obfuscators', but not for 'c++ obfuscators'.

Re: WebAssembly: a binary format for the web

#63

Post by denniskane »

Okay, seriously.

The only possible benefit that this technology could have for the planet is to give Brendan Eich a reason to run yet another one of those video-game-inside-of-a-video-game demos at another one of those JS conferences that frontend devs go so nuts about.

Except this time, there will be yet another video game inside of that inner video game!

Re: WebAssembly: a binary format for the web

#64

Post by elcritch »

spo81rty wrote: post #51

So could someone theoretically make flash or silverlight work via this?

Theoretically you can make those work in JavaScript. The performance might even be ok, but the limitations would still be the huge effort in reverse engineering flash or silver light code and features and secondly the browser sandbox policies which AFAIK aren't changed for WASM.

Re: WebAssembly: a binary format for the web

#65

Post by mintplant »

derefr wrote: post #22
josteink wrote: post #5

Earlier quoted context omitted.

PNaCl is cancer to the web and requires Google Spyware. No thanks.

PNaCl is no more a Google-proprietary feature than XMLHttpRequest is a Microsoft-proprietary feature. Anyone else is free to implement it, and then Google would have no more control over the "spec" of PNaCl than Microsoft has control over the evolution of AJAX.

Last I looked into this, the (P)NaCl codebase was heavily enmeshed with Chromium. Documentation on how any of it fit together was spread out across a multitude of wiki sites and mailing list archives, with conflicting descriptions of the exposed interfaces in varying states of obsolescence. The "spec" was, effectively, this big tangled ball of code in the Chromium tree.

The one method of running NaCl programs on their own relied on thousands of lines of Python code spread across a nested hierarchy of frameworks just to generate command line arguments to pass to the main runner binary -- and this used completely different interfaces into NaCl from Chromium's implementation. And all of this, being tightly integrated into the Chromium codebase, was subject to change at any point with no guarantee of API stability.

Maybe things have changed since then, but at the point when (P)NaCl was receiving the most attention I found it entirely impenetrable. Though the code may have been open source, the knowledge needed to integrate it with a new system was entirely proprietary. And anyone doing so would have ended up with an implementation bound to the evolution of the Chromium internals.

Re: WebAssembly: a binary format for the web

#66

Post by pcwalton »

hannob wrote: post #55

I haven't looked at WebAssembly in Detail, but my feeling and worry is that this is a can of worms for security issues. Javascript wasn't designed with security in mind and it has taken us decades to understand what implications that had (and we haven't really fixed them yet). The security implications for WebAssembly will be different, but I'm almost certain there will be a lot. (pnacl already introduced some quite…

> The security implications for WebAssembly will be different, but I'm almost certain there will be a lot.

What can you do today in Web Assembly that you can't already do in asm.js?

Re: WebAssembly: a binary format for the web

#67

Post by pcwalton »

userbinator wrote: post #43
RussianCow wrote: post #24

Earlier quoted context omitted.

No, but one of the goals of WebAssembly is to have a textual representation, so in theory you could still View Source. Not sure how that'll work out in practice, though.

In practice, I think most browsers won't include a "disassembler", under the justification that most users won't need it; I can see "View Source" unfortunately going that way too. What's wrong with that argument is the fact that although most users don't need it, it's an excellent way for those interested to explore into and find out how things work, and essentially get into web development with nearly no effort. If…

> In practice, I think most browsers won't include a "disassembler", under the justification that most users won't need it; I can see "View Source" unfortunately going that way too.

Thankfully for the openness of the Web, developer tools have been a source of intense competition among browsers. I see no reason why this will not continue to be true for introspection of Web Assembly.

Re: WebAssembly: a binary format for the web

#68

Post by derefr »

mintplant wrote: post #65
derefr wrote: post #22

Earlier quoted context omitted.

PNaCl is no more a Google-proprietary feature than XMLHttpRequest is a Microsoft-proprietary feature. Anyone else is free to implement it, and then Google would have no more control over the "spec" of PNaCl than Microsoft has control over the evolution of AJAX.

Last I looked into this, the (P)NaCl codebase was heavily enmeshed with Chromium. Documentation on how any of it fit together was spread out across a multitude of wiki sites and mailing list archives, with conflicting descriptions of the exposed interfaces in varying states of obsolescence. The "spec" was, effectively, this big tangled ball of code in the Chromium tree. The one method of running NaCl programs on thei…

Note that I'm not talking about integrating "Google's PNaCl" into another browser (that code is Google-proprietary, for your listed too-much-of-a-mess reasons if nothing else.) Mozilla et al wouldn't use Google's NaCl engine in Firefox any more than they would use Google's Javascript engine, or any more than they would have integrated ActiveX into Firefox just to call XMLHttpRequest.

I'm instead talking about implementing one's own LLVM-bitcode-compiling zero-install plugin architecture with safety guarantees derived from static analysis (i.e. what you get by implementing the whitepaper[1]), providing a similar API to plugins to NaCl's PPAPI.

The result would just be an ecosystem of "Native-binary Sandbox engines" and an API working group that is to {portable LLVM IR ISA, PPAPI} as the ECMA is to {Javascript, the browser DOM}.

[1] http://static.googleusercontent.com/media/research.google.co...

Re: WebAssembly: a binary format for the web

#69

Post by Spivak »

coldtea wrote: post #54
jgalt212 wrote: post #29

If the new way forward allows everyone distribute unreadable binary instead of readable, or de-obfuscatable, JavaScript, I think this definitely bad for open source and bad for innovation which depends upon stuff like: "oh, now I see how that did that. I think I can apply that technique to something else". Of course, people can release their js, python, java, et al that compiles down to WebAssembly, but because you a…

> If the new way forward allows everyone distribute unreadable binary instead of readable, or de-obfuscatable, JavaScript, I think this definitely bad for open source What "open source"? Open Source is dead in web services, because everybody can just hide the source behind the server. Even with SPAs, you could have 90% of the actual functionality on the server side, behind REST APIs and the like.

Sure, but you at least you have the ability to inspect the code which is running on your machine. A FOSS client to a proprietary service is still meaningful.

Re: WebAssembly: a binary format for the web

#70

Post by wbillingsley »

haberman wrote: post #40
Animats wrote: post #12

From Java applets to Java applets in twenty years.

Java applets were slow to load because fast loading was never made a priority. WebAssembly is prioritizing small size and fast loading. Java Applets were completely isolated from the surrounding web page, and vice-versa. I tried writing XEyes as a Java Applet back in the day, but the eyeballs could only follow the cursor while the cursor was directly on top of the applet's rectangle. WebAssembly operates on the singl…

There was a JavaScript to Java bridge in most browsers -- you could simply write a JS event handler that called a public API in your applet.

Before XMLHttpRequest became reliable across browsers, a fairly common trick was to use a 1 pixel Java applet to do the asynchronous calls to the server, and then call back out to JavaScript to manipulate the DOM.

Java only "behaved differently" if you wanted your applet to paint a square of the screen. Which was more about the problem that browsers also didn't support SVG, so if you wanted an interactive diagram you had to isolate yourself from HTML.

Post reply on HN