Live data from Hacker News

Goodbye PNaCl, Hello WebAssembly

blog.chromium.org

31–40 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#31
post #16

OK, so where do I get a mosh client programmed in WebAssembly? Without it, my chromebooks might as well be bricks.

By the time Google disables PNaCl on Chrome Apps, this kind of thing won't be an issue. There is a reason why the announced 2018 deactivation excluded Chrome Apps and Extensions.

Re: Goodbye PNaCl, Hello WebAssembly

#32
post #25

The most material result of this is that Chromebooks won't have a working SSH client starting sometime next year, because WebAssembly can't do real sockets without an external proxy.

No, FTFA: “We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions .” Chrome Apps (and extensions) using PNaCl will continue to work.

Yes, because non-portable NaCl has higher usage inside Chrome Apps and Extensions, but I don't for a minute believe that Google is going to continue investing eng resources in maintaining (non-portable) NaCl now that pNaCl is dead, so I'd expect that to get deprecated sometime in 2019 or 2020.

Disclaimer: My opinion, not that of my employer.

Re: Goodbye PNaCl, Hello WebAssembly

#33
post #21

This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps. Some examples of specialized apps I use all the time that would require a native app otherwise: - Signal Desktop - TeamViewer - Postman - SSH client - Cleanflight drone configuration tool It was one of the best things that happened to Linux desktops in a long time and removing it hurts users an…

Your comment scared me, but TFA doesn't say that: > We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions. Where do you see that chrome apps are being discontinued? Otherwise this is FUD.

EOL for Chrome Apps outside of Chrome OS was announced in August 2016 https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...

Re: Goodbye PNaCl, Hello WebAssembly

#34
post #21

This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps. Some examples of specialized apps I use all the time that would require a native app otherwise: - Signal Desktop - TeamViewer - Postman - SSH client - Cleanflight drone configuration tool It was one of the best things that happened to Linux desktops in a long time and removing it hurts users an…

Your comment scared me, but TFA doesn't say that: > We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions. Where do you see that chrome apps are being discontinued? Otherwise this is FUD.

[deleted]

Re: Goodbye PNaCl, Hello WebAssembly

#36
post #32

Earlier quoted context omitted.

No, FTFA: “We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions .” Chrome Apps (and extensions) using PNaCl will continue to work.

Yes, because non-portable NaCl has higher usage inside Chrome Apps and Extensions, but I don't for a minute believe that Google is going to continue investing eng resources in maintaining (non-portable) NaCl now that pNaCl is dead, so I'd expect that to get deprecated sometime in 2019 or 2020. Disclaimer: My opinion, not that of my employer.

> Yes, because non-portable NaCl has higher usage inside Chrome Apps and Extensions, but I don't for a minute believe that Google is going to continue investing eng resources in maintaining (non-portable) NaCl now that pNaCl is dead, so I'd expect that to get deprecated sometime in 2019 or 2020.

Sure, it is deprecated and will be deactivated eventually (but maybe not soon; consider WebSQL). Google's got every incentive to make sure that WebAssembly (plus the APIs exposed in ChromeOS) provides a complete replacement for PNaCl and apps have had time to transition before doing that.

Re: Goodbye PNaCl, Hello WebAssembly

#37
post #25

The most material result of this is that Chromebooks won't have a working SSH client starting sometime next year, because WebAssembly can't do real sockets without an external proxy.

Isn't this solved for (newer) Chromebooks by running an Android SSH client?

https://blog.google/products/chromebooks/the-google-play-sto...

Re: Goodbye PNaCl, Hello WebAssembly

#38

Earlier quoted context omitted.

Your comment scared me, but TFA doesn't say that: > We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions. Where do you see that chrome apps are being discontinued? Otherwise this is FUD.

EOL for Chrome Apps outside of Chrome OS was announced in August 2016 https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...

But OP is specifically calling out how this hurts Chrome OS, but it doesn't seem to affect that platform, from what I can tell.

Re: Goodbye PNaCl, Hello WebAssembly

#39
post #16

OK, so where do I get a mosh client programmed in WebAssembly? Without it, my chromebooks might as well be bricks.

Google is adding support for Android apps to Chrome OS, so presumably you'd get an app like JuiceSSH from the Play store.

https://blog.google/products/chromebooks/the-google-play-sto...

Re: Goodbye PNaCl, Hello WebAssembly

#40
post #2

At this point, I really loathe adopting any facet of web-browser technology: there are too many broken APIs in too many browsers to maintain on both sides of the system: the browser developers have an insane number of combinations of features that need to be useful, secured and made reliable and developers for browsers are always at some weird disadvantage where they can spend months or years maintaining an applicati…

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 know how well.

Post reply on HN