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

131–140 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#131

Post by jlarocco »

eeZi wrote: post #104
jlarocco wrote: post #90

Earlier quoted context omitted.

> It was one of the best things that happened to Linux desktops in a long time and removing it hurts users and makes them less secure. It would be more accurate to say it was the best thing to happen to your use of Linux in a long time, and it looks like even that is only because you're trying to use a bunch of closed source, non-cross-platform stuff. I also disagree that it makes users less secure. The teams working…

Signal Desktop and Cleanflight are open source. And sometimes, you have no choice - there's no FOSS alternative to TeamViewer, and thanks to it running inside Chrome, I no longer have to run a Windows VM. The web based SSH client is published by Google themselves and they use it internally. > The teams working on Debian, Ubuntu, Arch, etc. have much better security track records than some random web developers who've…

> The way things are, right now, Chrome is much better at protecting apps from each other than my Linux desktop is.

I have a hard time believing that. With a ton of stuff all running inside of Chrome, it's much easier for them to access each other's data than if they were standalone apps. Further, since Chrome is such a huge attack surface, I would expect it to be less secure than a smaller, more specific application.

On that note, I can go look at my Linux distro's security and bug tracking systems and see all of the known security issues and bugs affecting almost all of the software on my system. Does anything like that even exist for Chrome Apps?

> If, for example, the Cleanflight or TeamViewer apps were regular apps, a bug in them would fully compromise my account.

Isn't that the case whether it's a Chrome App or not? Chrome has a huge attack surface, so it seems there's an even bigger chance of hitting a bug or being affected by an exploit.

The bigger problem seems to be that you're running apps that you don't trust, while I can trust my Linux distro to have safe software in their repositories. Barring bugs, I generally don't have to worry about installing malicious applications.

I'm not sure Google does any kind of vetting for Chrome Apps, but I'm not sure I'd trust them even if they did. They are the largest ad tracking company in the world after all.

Re: Goodbye PNaCl, Hello WebAssembly

#132

Post by bobajeff »

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…

Actually, the AOT optimization path for asm.js has been supported by Internet Explorer/Edge for quite some time. Chrome also supports AOT asm.js path now through their wasm implementation[1]. Before that Chrome and Safari did optimizations that just happened to make asm.js faster ;)

It's likely that if WebAssembly didn't happen everyone would've implemented AOT optimizations for asm.js and all the new features (shared memory threads, simd, 64bit int etc.) would be targeting that instead.

[1] http://benediktmeurer.de/2016/12/20/v8-behind-the-scenes-dec...

Re: Goodbye PNaCl, Hello WebAssembly

#133

Post by azakai »

__s wrote: post #129
wyldfire wrote: post #122

Earlier quoted context omitted.

I suppose I should have asked "what does polyfill mean in this context?" Does that term really alias "run [it] on" or is there something more subtle about this term's meaning?

There's a high performance asm.js implementation of WASM (converting WASM to asm.js at runtime). ie if a browser didn't implement WASM, but had a JIT which executed asm.js at high speed, it could execute WASM at high speed

There isn't such a polyfill. There is currently no good tool to translate wasm into asm.js (or general JS) on the client. The best that exists is to run the wasm in a wasm interpreter, very slowly.

In theory a translator could be written into asm.js, but there would still be wasm code that won't run fast, such as 64-bit ints, unaligned loads and stores, bitcasts, and other operations.

Re: Goodbye PNaCl, Hello WebAssembly

#134

Post by acdha »

lvh wrote: post #65
eriknstr wrote: post #53

Earlier quoted context omitted.

I think that's what parent commenter was implying. (However, I don't agree. I remember the horrible Java applets and I am thankful that I pretty much never encounter any of them these days.)

Is the horribleness of applets intrinsic in the concept of a common target?

It's definitely a challenge trying to balance portability with support for platform specific features but I'd be a little hesitant to draw general conclusions from the two big examples since both Adobe and Sun were notoriously negligent platform maintainers addicted to haring off after some shiny whim before fixing what they had already built. Even simple things like if Sun cared about non-server performance in the 90s or if either of them had figured out how to properly package and ship updated before the 2010s could have improved their reputation immensely.

Re: Goodbye PNaCl, Hello WebAssembly

#135

Post by withjive »

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.

What you said is true, however...

I am referring to the initial offering of Native Client for inclusion into FireFox.

Since this did not happen, Native client did not see the uptake it needed— and the team was destaffed.

Since it was a working platform that actually existed and let you use a modified version of LLVM, it was quite usable.

We could of have powerful native sandboxed apps quite a long time ago if FireFox became PNaCl compatible.

Instead, Mozilla envisioned that the JIT could eventually bridge the native performance gap.

Mozilla defended this ideas such as ASM and emscripten. And now Mozilla is coming close to a more open and performant web.

Re: Goodbye PNaCl, Hello WebAssembly

#136

Post by nojvek »

bluGill wrote: post #40
richdougherty wrote: post #14

Earlier quoted context omitted.

Deprecated APIs is the cost we pay for innovation. If we're going to get new APIs then it's reasonable to expect that old, little used and superseded APIs will be retired, since the browser vendors don't have unlimited resources. Of course, it's understandable for those who are hit by a deprecation to be annoyed, but overall I think the tradeoff is worth it. It's definitely better than have unchanging APIs and having…

There needs to a middle ground. While it is true bad APIs need to go once in a while, a lot of them never should have come in the first place, and if some work had been put into getting them right in the first place they would still work just find today. Not perfect mind you, but just a little effort would be enough that we wouldn't have to deprecate them. I think the Web is moving in this direction, though I don't k…

Flash is a zombie but not dead. You can still get an old swf working by clicking a couple of things in browser settings. The thing with google is they deprecate wayyyy to fast without proper thought to the alternative. It's like their projects commit suicide than die naturally.

Re: Goodbye PNaCl, Hello WebAssembly

#137

Post by candiodari »

eeZi wrote: post #80
puzzle wrote: post #78

Earlier quoted context omitted.

In some ways, and if everything aligns, ChromeOS is actually better: https://groups.google.com/a/chromium.org/d/msg/chromium-hter... But "if everything aligns" == "only if you're inside Google".

Hah, that's a funny thread. I've heard that Google is using Chromebooks for engineers with production access. Makes a lot of sense sense since Chrome OS is much easier to secure than a normal Linux distribution.

That sounds insane. Do you have any proof ?

Google also has goobuntu, which I'm being is what's provided to engineers.

Re: Goodbye PNaCl, Hello WebAssembly

#138

Post by nojvek »

duskwuff wrote: post #108
Crontab wrote: post #79

Earlier quoted context omitted.

HTML5 Video is just an example of shitty browser behavior, as for some reason, every web browser maker seems to think that autoplay videos are great. They're not because sites are abusing it. Worst, some sites these days will waiting until you've scrolled down a bit before they start playing a video, leaving the user to locate it and stop it. As for Flash, it was indeed bad, but at least I had the option of not insta…

> every web browser maker seems to think that autoplay videos are great Huh? This has nothing to do with browsers; it's purely a site author decision. Autoplaying videos is a site author decision -- and one that they already frequently made before HTML5 video was widely available.

Not really. Browsers just need to default stop autoplaying videos out of the screen view. Or better yet what they did to popup blockers. Give one chance to behave well, if the site doesn't then it gets blocked and the user has a notification that autoplay was disabled.

Re: Goodbye PNaCl, Hello WebAssembly

#139

Post by irrational »

matt4077 wrote: post #82
irrational wrote: post #9

Earlier quoted context omitted.

Yeah, we were looking at browser stats for our website today and during the last 30 days 20% of our distinct users were using IE 6, 7, 8, 9, 10, or 11. Of course most were on IE 11, but when you still have a significant number of people still using ancient versions of IE, I despair at ever being able to use modern web technologies.

I don't quite get your numbers, because 20% * IE6, 7, 8, 9, 10, 11 = 20% * 6 > 100%. Or, alternatively, the 20% for all of them combined don't prove your point that "people are using ancient versions", because, as you point out yourself, "most were on IE 11". FWIW IE 11 is around 3% globally, all other IE is around 0.5%, combined: http://caniuse.com/usage-table

20% of our user base is on some form of IE (6-11). The other 80% are on Chrome, Firefox, Edge, Safari, etc.

Re: Goodbye PNaCl, Hello WebAssembly

#140

Post by irrational »

spiderfarmer wrote: post #22
irrational wrote: post #9

Earlier quoted context omitted.

Yeah, we were looking at browser stats for our website today and during the last 30 days 20% of our distinct users were using IE 6, 7, 8, 9, 10, or 11. Of course most were on IE 11, but when you still have a significant number of people still using ancient versions of IE, I despair at ever being able to use modern web technologies.

The only way to move forward is to ignore them. Put up a message that advises to install Chrome or Firefox and get rid of all the cruft that supports browsers older than 5 years. Most probably already have a modern browser installed but use IE out of habit. I see it at large corporations all the time. I even heard "I wish it would remind me to just use Chrome"

Unfortunately that isn't an option for us. We are mandated to support everyone. And those people on IE are retail sales associates using our site on hardware that simply cannot be upgraded. It must be replaced to get a newer browser. But the replacement cycle is measured in decades.
Post reply on HN