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

21–30 of 164 posts

Re: WebAssembly: a binary format for the web

#21

Post by pcwalton »

corysama wrote: post #19
bobajeff wrote: post #16

Earlier quoted context omitted.

I think the main issue was it's reliance on the Pepper Plugin API. Which several people have said was mapped closely to Chrome's software architecture. Technically it was a plugin for Pepper and the only difference between it and Flash was that it was open source and only available to Chrome.

In discussions of objections, Pepper comes up a lot. I don't understand the situation well enough, but that always seemed to me like throwing the baby out with the bathwater. The secure, native, binary executable is the big deal. The fact that people who are currently writing secure native binary executables are using an unpopular API seemed incidental and eminently fixable. Not "flip a switch" fixable, but "Let's wo…

> The fact that people who are currently writing secure native binary executables are using an unpopular API seemed incidental and eminently fixable

Agreed. Web Assembly is the solution :)

Re: WebAssembly: a binary format for the web

#22

Post by derefr »

josteink wrote: post #5
denniskane wrote: post #3

"Why should WebAssembly succeed where previous attempts (such as Adobe Flash and Google Portable Native Client) have failed?" Failed???? Excuse me, I haven't even BEGUN to scratch the surface of the awesomeness that is pnacl in my own project!

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.

Re: WebAssembly: a binary format for the web

#24

Post by RussianCow »

rasz_pl wrote: post #23

can you go back to source code from WebAssembly binary? I dont want a web that serves me obfuscated binary blobs.

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.

Re: WebAssembly: a binary format for the web

#25

Post by mstade »

corysama wrote: post #2

A good talk from a week ago on WebAssembly: https://www.youtube.com/watch?v=NhAPPQqKCi8

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 statements like that offensive, and detrimental to getting good conversations going. I've not finished watching that presentation on these grounds, and I'm not sure I will. It's not out of principle either, but simply because I get too annoyed to continue.

For the record, I identify myself as a software engineer. These days I mostly do front end development, but I have written code in many languages and contexts (asm, javascript, c, python, vb, whatever fits) and been well remunerated for it. I find the front/back/native/whatever splits to be silly, probably fueled by trying to make more efficient job listings. Fine that HR folks do this, but as engineers we should know better.

Re: WebAssembly: a binary format for the web

#26

Post by nickpsecurity »

Animats wrote: post #12

From Java applets to Java applets in twenty years.

Smaller than JS, faster, uses Abstract Syntax Trees... sounds like the Juice project. Oh, how much better web apps could've been.

https://web.archive.org/web/20000830093908/http://caesar.ics...

Re: WebAssembly: a binary format for the web

#27

Post by opinali »

denniskane wrote: post #3

"Why should WebAssembly succeed where previous attempts (such as Adobe Flash and Google Portable Native Client) have failed?" Failed???? Excuse me, I haven't even BEGUN to scratch the surface of the awesomeness that is pnacl in my own project!

And we used to think x86 was a bad design of native code.

Re: WebAssembly: a binary format for the web

#29

Post by jgalt212 »

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 are not forced too, I do not think most will.

Re: WebAssembly: a binary format for the web

#30

Post by denniskane »

corysama wrote: post #19
bobajeff wrote: post #16

Earlier quoted context omitted.

I think the main issue was it's reliance on the Pepper Plugin API. Which several people have said was mapped closely to Chrome's software architecture. Technically it was a plugin for Pepper and the only difference between it and Flash was that it was open source and only available to Chrome.

In discussions of objections, Pepper comes up a lot. I don't understand the situation well enough, but that always seemed to me like throwing the baby out with the bathwater. The secure, native, binary executable is the big deal. The fact that people who are currently writing secure native binary executables are using an unpopular API seemed incidental and eminently fixable. Not "flip a switch" fixable, but "Let's wo…

Portable Native Client is a really huge project that takes a lot of PhD-level talent to implement correctly, and it requires a very specific type of organization that has the requisite "will" and "way" to make it happen.

Even if Mozilla had the will, they really don't have any way to contribute very significantly to the development effort, because it sort of requires a lot of very talented people getting paid large sums of money for long periods of time... which is obviously something that Google can afford to do.

I think everyone has always known that NPAPI was eventually going to have to be completely overhauled or even replaced. For anyone to constantly harp on the idea that "all that matters is the open web" when they come from the very same organization -- although going by a different name -- for which the original binary plugin architecture was named (Netscape Plugin API) is just patently absurd.

There is so much quality, freely available C/C++ code in this world that it is pretty mind boggling, and the purely technical achievement of allowing this code to be efficiently used by end users through the web platform is, again, a fairly mind boggling idea.

I'm not saying that this web assembly concept won't have any use cases whatsoever in the future, but I am saying that the proven PNaCl technology that exists right now is way, way too powerful for any web-based applications developer worth his or her soul to pass up very easily.

Post reply on HN