Live data from Hacker News

Goodbye PNaCl, Hello WebAssembly

blog.chromium.org

251–260 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#251

Earlier quoted context omitted.

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

I agree, but simply telling user to download a better browser could be a pretty condescending attitude. Falling back to a css-less html 4 would be more responsible for everyone.

It could sound condescending, but the amount of people really limited to IE9 or IE10 without an alternative is really, really small.

Re: Goodbye PNaCl, Hello WebAssembly

#252
post #244

Earlier quoted context omitted.

> instead of one Chrome instance, I'm now running five which use more than one GB of RAM each Is that true? Executables and shared object files are supposed to share (code) memory. So what big data structures does Chrome use that it can share between tabs (which are processes) and that it can't share between different instances of Chrome?

> Is that true? Executables and shared object files are supposed to share (code) memory. Different version - different DLLs

Ok, so it's a version management problem then.

Re: Goodbye PNaCl, Hello WebAssembly

#253
post #190

Earlier quoted context omitted.

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.

The problem was precisely the Pepper, a pile of API that Google thought they could force on everybody, not PNaCl per see. If the initial NaCl implementation just exposed the pre-existing Web API into the native code sandbox without adding anything extra, the story can be rather different and a version of PNaCl could be standardized.

Re: Goodbye PNaCl, Hello WebAssembly

#254

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 ?

Git bash comes with ssh.

Cygwin has ssh as an optional install.

Msys2 too.

Of course, you need to have windows first. MS give away 30-day win 10 trial VM images with git bash installed, or at least they did.

Re: Goodbye PNaCl, Hello WebAssembly

#255
post #48

Earlier quoted context omitted.

And if that VM ran on over 2 billion devices, on every toaster out there? In the end, this all is just reinventing the JVM, in slower, but more secure.

Were you around in the 90s when people actually did try to use the JVM for this? Do you remember the part where everyone started using JavaScript instead because of all the deficiencies of Java Applets? (Slow to load, resource intensive, no interaction with the surrounding page)

I was, and I wasn't saying that WebAssembly is bad — but I'd have preferred compatibility with Java bytecode, even if it'd offer different APIs.

Re: Goodbye PNaCl, Hello WebAssembly

#256
post #83

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.)

> I remember the horrible Java applets and I am thankful that I pretty much never encounter any of them these days.) Yeah, yay for progress and horrible Electron apps..

Electron apps are not really relevant when talking about Java applets. Java applets embed in the browser, so compare Java applets with HTML5, CSS3, JavaScript and WebAssembly.

I much prefer the latter (HTML5 + CSS3 + JS + WebAsm).

Re: Goodbye PNaCl, Hello WebAssembly

#257
post #48

Earlier quoted context omitted.

And if that VM ran on over 2 billion devices, on every toaster out there? In the end, this all is just reinventing the JVM, in slower, but more secure.

It's reinventing the good part of the JVM (the JIT and the bytecode), better than the JVM (unsigned ints and value types are supported), without the bad parts of the JVM on the Web (the libraries, including the slow graphics stack, etc.) What's not to like?

What's not to like? Why couldn't we just create a system compatible with Java bytecode, and just replace the APIs over which it interacts withthe system (as Android has done)?

That'd make it even possible to reuse old applets with just a tiny shim around them.

And it'd keep compatibility with a huge environment of libraries and languages.

Re: Goodbye PNaCl, Hello WebAssembly

#258
post #253
post #190

Earlier quoted context omitted.

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.

The problem was precisely the Pepper, a pile of API that Google thought they could force on everybody, not PNaCl per see. If the initial NaCl implementation just exposed the pre-existing Web API into the native code sandbox without adding anything extra, the story can be rather different and a version of PNaCl could be standardized.

That's true, although NaCl's design made that difficult because the native code sandbox had to be a different process so interacting with the page's DOM would have required IPC.

Re: Goodbye PNaCl, Hello WebAssembly

#259
post #230

Earlier quoted context omitted.

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."

I love that law. I've been putting it to use ever since I read that.

Re: Goodbye PNaCl, Hello WebAssembly

#260
post #238
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…

I always wonder what it is that these apps need that cannot be done as regular web apps, as the web platform has provided more and more controlled ways to break out of the browser sandbox. (This is not rethorical by the way.)

Some devs want to develop js apps without paying/maintaining a server.
Post reply on HN