Live data from Hacker News

Goodbye PNaCl, Hello WebAssembly

blog.chromium.org

221–230 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#221

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.

Can you open a socket or write to the file system with WASM ?

You can only do what the browser sandbox provides, no direct access to the underlying operating system, only to HTML/JS APIs.

Re: Goodbye PNaCl, Hello WebAssembly

#222
post #203

Earlier quoted context omitted.

How is it better than WebAssembly?

It executes (sandboxed) native code directly, instead of requiring JIT compilation to native.

But that wouldn't be portable to other architectures though. Webasm is supposed to run on anything a modern browser can run on. I think it would also be much harder to guarantee that's secure.

Re: Goodbye PNaCl, Hello WebAssembly

#223

Earlier quoted context omitted.

On windows, you no longer need either with bash for windows you can have a near complete linux experience while running inside windows natively.

If you can assure me that is the case, fantastic! Do you know of a way to test the UX of ssh from bash for windows for less than $5 ?

I don't know enough about ssh for Chrome and bash for Windows to get your point. Isn't bash for Windows (as part of WSL?) free? What is it that costs more than $5 using bash for windows but is free with ssh for Chrome? Genuinely interested, I'm on OSX mostly but I'm WSL curious.

Re: Goodbye PNaCl, Hello WebAssembly

#224

As a web developer working primarily in JS, what should I be learning now to stay relevant/up-to-date once WebAssembly is more common? Are we going to see more web stuff built with c++, like the dsp example in this blog post?

You shouldn't have to deal with C++ directly unless you really want to, it's more likely that there will be 'precompiled' WebAssembly modules of existing C/C++ libs which solve computation-heavy tasks (like physics engines, image manipulation, 3d rendering frameworks etc)... and which would offer a Javascript API. The workflow for JS devs would be the same as using a minified Javascript framework now, but instead of a minimifed JS blob you'll load a WebAssembly blob.

Re: Goodbye PNaCl, Hello WebAssembly

#225
post #46
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…

A lot of current experiments seem to be the other way around. People with C/C++ projects porting them to WebAssembly. This is partly due to the initial limitations in the current version though.

I'm not a web developer but this has definitely peaked my interest to the point I've been dabbling with WebAssembly. It's really easy to get going so I could see a lot of people with other than WebDev backgrounds getting into application development in the browser.

Re: Goodbye PNaCl, Hello WebAssembly

#227
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…

Agreed. WebAssembly is not a replacement; the point was not to allow to write extensions in native language, the point was to have a mechanism for escaping the browser sandbox in a controlled way.

Google could have allowed Chrome to be used as a cross-platform GUI library (THE cross platform GUI library), but left it to Electron (lagging behind and requiring distribution); think XUL runner. I don't see the sense in that. I'd absolutely love a modern XUL runner.

Re: Goodbye PNaCl, Hello WebAssembly

#228

Earlier quoted context omitted.

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.

I actually don't think you are incorrect. GNU is not nearly as big a piece of the puzzle as it used to be. It's just that when most people say "Linux Desktop", the part where they say "Linux" usually means the part that GNU makes up. As far as I know, GNU libc is still by far and away the most popular libc installed on those kinds of systems.

So it was just kind of a snarky joke because the parent said that to be a "Linux Desktop" you had to be able to get ssh running (presumably they meant openssh). And while that's not GNU, GNU is what the vast majority of "Linux Desktops" will use to get you there -- so the implication really was that "Linux Desktop" == "GNU/Linux Desktop".

I thought it was funny, but probably I was being too obscure. Also, I should know better than to dive into politics for no good reason.

Re: Goodbye PNaCl, Hello WebAssembly

#229
post #187

Earlier quoted context omitted.

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 con…

Does battery usage not matter?

Not for every device. Desktops aren't obsolete, some laptops never leave their desk and Chrome is a target for WebAssembly.

Re: Goodbye PNaCl, Hello WebAssembly

#230
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.

Reminds me of Cunnigham's Law: "the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
Post reply on HN