Live data from Hacker News

WebAssembly: a binary format for the web

2ality.com

11–20 of 164 posts

Re: WebAssembly: a binary format for the web

#11
post #7

Earlier quoted context omitted.

Supported by a single browser and based on a single (and the same) vendor's spec, which needlessly duplicates about half a web browser's functionality using a brand new API, and with no support due for other browsers any time soon

False. From the Native Client wikipedia page: As of 13 May 2010, Google's open source browser, Chromium, was the only web browser to utilize the new browser plug-in model.[28] Mozilla has announced that they are "not interested in or working on Pepper at this time."[29] As of 2015, Pepper is supported by Chrome, Chromium and Opera.

All of which are functionally the same Blink-based browser, so you're splitting a really fine hair.

Re: WebAssembly: a binary format for the web

#14

"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!

If Adobe Flash was a failure, I only hope I can fail as well and as strongly in my life...

Either he's mixing narratives here or he's using standard web development practices as the context of it failing.

Today using Ajax is better practice because it integrates better with the browser and it'll work on mobile.

Re: WebAssembly: a binary format for the web

#16

"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!

The failure of pnacl isn't primarily technical, it's political. I think the core tech (verifiable secure native code) is awesome. Many people in high places in non-Google browsers object to pnacl on several fronts. The crux of which seems to be that there is not a smooth transition story from JS->PNaCL. Getting JS and PNaCL to inter-operate, share implementation/memory/APIs is a problem. A bigger problem is the need…

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.

Re: WebAssembly: a binary format for the web

#18
post #11

Earlier quoted context omitted.

False. From the Native Client wikipedia page: As of 13 May 2010, Google's open source browser, Chromium, was the only web browser to utilize the new browser plug-in model.[28] Mozilla has announced that they are "not interested in or working on Pepper at this time."[29] As of 2015, Pepper is supported by Chrome, Chromium and Opera.

All of which are functionally the same Blink-based browser, so you're splitting a really fine hair.

Okay, so let's examine the remaining browsers, shall we?

Safari and IE/Edge automatically don't matter because they are exclusive to their respective [proprietary] host operating systems.

That leaves Firefox.

Does anyone really think there is legitimate competition between Chrome and Firefox anymore?

I mean don't get me wrong, Firefox was a godsend in the bad old days of M$IE domination...

But this is 2015, and Google is basically Skynet, while Firefox is not much more than a warm, fuzzy memory.

Seriously... does anyone really want to turn this into a battle between Google and Mozilla?

Re: WebAssembly: a binary format for the web

#19

Earlier quoted context omitted.

The failure of pnacl isn't primarily technical, it's political. I think the core tech (verifiable secure native code) is awesome. Many people in high places in non-Google browsers object to pnacl on several fronts. The crux of which seems to be that there is not a smooth transition story from JS->PNaCL. Getting JS and PNaCL to inter-operate, share implementation/memory/APIs is a problem. A bigger problem is the need…

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 work together to figure out a better API" fixable. But, the idea that the huge, Chrome-specific API would be required to be incorporated into every other browser as-is and could not have been replaced in the last six years seems to be assumed as a fact of life.

Re: WebAssembly: a binary format for the web

#20
Posted some time ago, a .NET implementation and discussion:

https://github.com/WebAssembly/ilwasm

https://news.ycombinator.com/item?id=10162793

I also have to think about the new image file format posted some time ago: FLIF (http://flif.info/). With WebAssembly you could implement this in the browser by just embedding a lib. No need to wait for the vendors to support it.

Post reply on HN