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

Goodbye PNaCl, Hello WebAssembly

blog.chromium.org

Post reply on HN
Print view View original

181–190 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#181

Post by jhpriestley »

roca wrote: post #177
jhpriestley wrote: post #105

From the asm.js FAQ: Q. Why not NaCl or PNaCl instead? Are you just being stubborn about JavaScript? A. The principal benefit of asm.js over whole new technologies like NaCl and PNaCl is that it works today asm.js however wasn't good enough to actually be useful, as evidenced by the lack of adoption and the move to wasm. So now we have wasm which is not backward compatible. We would be further along now if Mozilla/Ei…

PNaCl had two big problems Google never attempted to solve: * No spec, just import some particular version of LLVM and it does what it does * Dependence on Pepper for its platform API --- just a big pile of Chromium code that does what it does and duplicates all the standard Web APIs

I don't have any insider knowledge, but my sense is that Google never tried to solve these sorts of issues because Mozilla made it very clear that they wouldn't support it. Now they're backtracking and building a non-js asm system too. Do you think wasm apps will always use slow JavaScript ffi to call opengl say? We'll get a new pepper in like another decade.

Re: Goodbye PNaCl, Hello WebAssembly

#182

Post by roca »

bitmapbrother wrote: post #116
withjive wrote: post #13

Looks like Mozilla won this fight. When Mozilla didn't accept PNaCl and Pepper API proposed by Google, Mozilla went down the ASM path which now led us to Web Assembly being the general way forward.

How exactly did Mozilla win this fight? WebAssembly was inspired by Mozilla's asm.js and Google's PNaCl. Also, the team working on WebAssembly are from Mozilla, Microsoft, Google and Apple. The real winner here are users because we now have a standard among all major browsers.

Google developed NaCl and PNaCl and put the latter out on the Web with no spec --- just "pull this version of LLVM and ship it". Also, apps written in PNaCl used the Pepper API for all platform features, a giant pile of Chromium code also with no spec. All an absolute nightmare for anyone who cares about Web standards and browser bloat. These efforts required big Google teams working for many years ... efforts which are now going by the wayside.

Mozilla put together a small team and did asm.js to show that you could port C/C++ apps to the Web and get good performance while reusing the JS engine and all the existing Web platform APIs.

Now we have WebAssembly, which uses existing Web platform APIs and which browser vendors are implementing by reusing the guts of their JS engines. It's obvious who won.

In a way it doesn't matter "who won" because as you say Web developers are the ultimate winners. But it does underscore how much the Web continues to owe to Mozilla.

(It's also an illustration of how powerful companies can commit massive blunders and get away scot-free in the marketplace and in PR.)

Re: Goodbye PNaCl, Hello WebAssembly

#183

Post by Sanddancer »

mikekchar wrote: post #114
wcummings wrote: post #64

Earlier quoted context omitted.

I wouldn't call it a "Linux Desktop" if you can't run a standard SSH client. Chrome OS is it's own beast.

I've got this crazy idea. Since "Linux Desktops" are generally running GNU under the hood for providing user land services, why don't we call those systems... I don't know... "GNU/Linux"? That way we can distinguish them from systems that use the Linux kernel, but have a completely different user land infrastructure. I know, I know. It's crazy talk....

How many of them actually intimately use the GNU userland as opposed to Xorg and whatever libc's installed? GNU's an increasingly irrelevant portion of unix and unixlike systems -- most of the actually important userland portions are python, ruby, the aforementioned Xorg, etc.

Re: Goodbye PNaCl, Hello WebAssembly

#184

Post by roca »

jhpriestley wrote: post #181
roca wrote: post #177

Earlier quoted context omitted.

PNaCl had two big problems Google never attempted to solve: * No spec, just import some particular version of LLVM and it does what it does * Dependence on Pepper for its platform API --- just a big pile of Chromium code that does what it does and duplicates all the standard Web APIs

I don't have any insider knowledge, but my sense is that Google never tried to solve these sorts of issues because Mozilla made it very clear that they wouldn't support it. Now they're backtracking and building a non-js asm system too. Do you think wasm apps will always use slow JavaScript ffi to call opengl say? We'll get a new pepper in like another decade.

I personally told Google people that the Pepper platform API situation was unacceptable to Mozilla years before PNaCl even appeared. That didn't stop them pushing ahead. So if your theory is correct then Mozilla opposition was not strong enough to stop PNaCl development, and not strong enough to stop them exposing it to the public Web, but strong enough to stop them trying to turn it into a proper Web standard.

Wasm is only superficially non-JS. AFAIK every browser vendor is implementing Wasm by reusing the optimizing compilers in their JS engines.

I think we might see some extensions to WebIDL and Web platform APIs to improve Wasm app performance. We're sort of already seeing that with [AllowShared]. But there's no need to develop entirely new platform APIs, because fundamentally there's no reason calls from Wasm through JS API glue to the browser should be slow; JS API glue can be inlined into the Wasm code, for example.

Re: Goodbye PNaCl, Hello WebAssembly

#185

Post by zurn »

ehsankia wrote: post #120
itp wrote: post #42

Earlier quoted context omitted.

One way it affects it is to reduce the overall market for Chrome apps, reducing the incentive to make an app in the first place.

Exactly. I doubt most of the ChromeApps that exist today were made for ChromeOS. They were made because it was an easy and straight forward way of making a webapp on the desktop. Now, as OP mentions, everyone is moving to Electron and NWJS, neither of which works directly on ChromeOS. The only upside I can see is that CrOS is soon going to support running Android Apps which may save it, but even then... Maybe they'll…

This might also motivate better support for running ChromeOS apps under standard Linux.

Re: Goodbye PNaCl, Hello WebAssembly

#186

Post by dragonwriter »

roca wrote: post #182
bitmapbrother wrote: post #116

Earlier quoted context omitted.

How exactly did Mozilla win this fight? WebAssembly was inspired by Mozilla's asm.js and Google's PNaCl. Also, the team working on WebAssembly are from Mozilla, Microsoft, Google and Apple. The real winner here are users because we now have a standard among all major browsers.

Google developed NaCl and PNaCl and put the latter out on the Web with no spec --- just "pull this version of LLVM and ship it". Also, apps written in PNaCl used the Pepper API for all platform features, a giant pile of Chromium code also with no spec. All an absolute nightmare for anyone who cares about Web standards and browser bloat. These efforts required big Google teams working for many years ... efforts which…

There's no blunder: Google had a goal, threw out something, stimulated competition over the precise implementation, and now there is a universally (among browser vendors) accepted solution moving the web in the direction Google wanted.

That's a strategic victory for Google.

Re: Goodbye PNaCl, Hello WebAssembly

#187

Post by ehnto »

bas wrote: post #170
ehnto wrote: post #166

Earlier quoted context omitted.

I doubt a regular user would notice 100% CPU usage and even less certain that they would know what to do about it or what was causing it. Most OSes operate chrome just fine when another process is asking for 100% as well.

Their fans running at max (or a very warm device) would let them know. This has been the experience among the non/less-technical users in my company.

Right, they might notice it, but why would they care? They don't know that they should care, it is just a computer being a computer and it probably spins up the fans for other tasks too. They would be right to not care unless told otherwise, sys ops isn't their job.

I think it would be smart to educate people as part of a regular security briefing for non technical staff though. But if it's something that high of concern to your company maybe an automated CPU usage monitor could alert the team to anomalies.

Re: Goodbye PNaCl, Hello WebAssembly

#190

Post by roca »

dragonwriter wrote: post #186
roca wrote: post #182

Earlier quoted context omitted.

Google developed NaCl and PNaCl and put the latter out on the Web with no spec --- just "pull this version of LLVM and ship it". Also, apps written in PNaCl used the Pepper API for all platform features, a giant pile of Chromium code also with no spec. All an absolute nightmare for anyone who cares about Web standards and browser bloat. These efforts required big Google teams working for many years ... efforts which…

There's no blunder: Google had a goal, threw out something, stimulated competition over the precise implementation, and now there is a universally (among browser vendors) accepted solution moving the web in the direction Google wanted. That's a strategic victory for Google.

Google wasted huge resources on an approach which it was obvious from the beginning would never lead to a Web standard. Mozilla people, including me, told Google people even before PNaCl appeared that introducing the whole new non-standard Pepper API was unacceptable.
Post reply on HN