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

91–100 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#91

Post by dragonwriter »

sp332 wrote: post #84
dragonwriter wrote: post #31

Earlier quoted context omitted.

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.

I haven't seen any real activity from browser makers to add raw UDP APIs.

> I haven't seen any real activity from browser makers to add raw UDP APIs.

Well, for the Chrome Apps use case for Chrome OS, chrome.sockets.udp seems to be available, and wasm can call out to JS APIs. What other browser vendors do isn't really relevant for Chrome Apps.

Re: Goodbye PNaCl, Hello WebAssembly

#92

Post by skybrian »

BHSPitMonkey wrote: post #58
tostitos1979 wrote: post #51

Earlier quoted context omitted.

E.g. http://developer.samsung.com/tv/develop/extension-libraries/...

That's a controlled environment, though; Samsung almost certainly creates a customized build of Chromium for its TVs and can simply keep NaCl enabled if it wishes. They aren't beholden to the same policies that apply to the consumer Chrome releases.

Yes, it's a gradual decay, not a forced upgrade.

The problem is that you eventually end up stuck with an ancient version of Chromium without security fixes and incompatible with websites that use newer browser features.

Re: Goodbye PNaCl, Hello WebAssembly

#93

Post by na85 »

eeZi wrote: 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…

Have you tried simply avoiding Electron and the bloatware it encourages?

Re: Goodbye PNaCl, Hello WebAssembly

#94

Post by pirocks »

wcummings wrote: post #62
eeZi wrote: 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…

Why are you using an SSH client in your web browser?

In my case, because your trying to run a high school computer club, and everyone has school issued chromebooks.

Re: Goodbye PNaCl, Hello WebAssembly

#95

Post by jsfitzsimmons »

k__ wrote: post #46
sjrd wrote: post #17

Earlier quoted context omitted.

I don't think WebAssembly will become more common than JavaScript anytime soon. And even when it will be, it means the tooling will have become so good that you won't even have to think about WebAssembly. That will be left to the people who create compilers to WebAssembly. Hopefully you'll just use whatever language your org/team/etc. uses, and have it compiled to JS or WebAssembly as is most appropriate for said lan…

I guess the first ones jumping on the WebAssembly wagon will be Web developers, so we will probably get WASM modules written in languages they see appropriate, when JS doesn't cut it anymore. I guess it will be Rust or Go. Rust because of Cargo (for npm users a big +) and Mozilla (good marketing of Rust). Go because of Google (also a Web company with good marketing) and because I read some Node.js developers already…

Doesn't WASM need GC support before Go can be used? It'll need to be fully managed languages until then, I think.

With that said I'm just parroting some other comments I've seen on this topic in other contexts, so I'm asking the question genuinely.

Re: Goodbye PNaCl, Hello WebAssembly

#96

Post by gtirloni »

nerpderp83 wrote: post #61
spiderfarmer wrote: post #22

Earlier quoted context omitted.

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"

Chrome and Firefox probably dont run on their OS.

Then they have bigger problems that they should be getting on top of urgently.

Re: Goodbye PNaCl, Hello WebAssembly

#97

Post by wott »

lacampbell wrote: post #76
choward wrote: post #49

Earlier quoted context omitted.

I agree. It seems like most of the extra horsepower we have these days is used for tracking on behalf of a company instead of features that are useful for the end user.

Well, any powers can be used for good or evil. The great thing about shitty websites is that I can opt to not visit them.

At best, you can opt to not visit them again. And then you forget, or you really need to access them, etc.

Re: Goodbye PNaCl, Hello WebAssembly

#98

Post by duskwuff »

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?

IMO: No. It was more of an implementation issue. When Java applets were first implemented, the web platform was still extremely limited -- HTML was still at version 2.0, CSS and the DOM didn't exist yet, and Javascript was still very new. So it made some sense, at that point, to have Java applets exist in their own "world", and not interact with other web content.

A modern Java applet environment would probably look very different. More of a focus on providing a bridge to the browser's DOM, less of a focus on building UIs using native Java frameworks (like AWT or Swing).

Re: Goodbye PNaCl, Hello WebAssembly

#99

Post by dragonwriter »

jsfitzsimmons wrote: post #95
k__ wrote: post #46

Earlier quoted context omitted.

I guess the first ones jumping on the WebAssembly wagon will be Web developers, so we will probably get WASM modules written in languages they see appropriate, when JS doesn't cut it anymore. I guess it will be Rust or Go. Rust because of Cargo (for npm users a big +) and Mozilla (good marketing of Rust). Go because of Google (also a Web company with good marketing) and because I read some Node.js developers already…

Doesn't WASM need GC support before Go can be used? It'll need to be fully managed languages until then, I think. With that said I'm just parroting some other comments I've seen on this topic in other contexts, so I'm asking the question genuinely.

> Doesn't WASM need GC support before Go can be used?

Why can't the Go implementation can have its own GC, the same as the Go implementation for, say, x86 does?

Re: Goodbye PNaCl, Hello WebAssembly

#100

Post by phonon »

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.

Uhhh, I think you missed this--

https://wiki.mozilla.org/Mortar_Project

Post reply on HN