Slashdot Mirror
Chrome To Deprecate PNaCl, Embrace New WebAssembly Standard (tomshardware.com)
An anonymous reader quotes Tom's Hardware
Google announced that its Portable Native Client (PNaCl) solution for making native code run inside the browser will be replaced by the new cross-browser web standard called WebAssembly... Even though Google open sourced PNaCl, as part of the Chromium project, Mozilla ended up creating its own alternative called "asm.js," an optimized subset of JavaScript that could also compile to the assembly language. Mozilla thought that asm.js was far simpler to implement and required no API compatibility, as PNaCl did. As these projects seemed to go nowhere, with everyone promoting their own standard, the major browser vendors seem to have eventually decided on creating WebAssembly. WebAssembly can give web apps near-native performance, offers support for more CPU features, and is simpler to implement in browsers and use by developers.
WebAssembly is a byte code for a virtual machine. It's not native.
PNaCl is a byte code for a virtual machine, with an interfaces based on an earlier native virtual container (NaCl).
these are secure if virtualization is complete. but all known implementations are still susceptible to row hammer as it's too difficult a problem to solve for VM implementers.
“Common sense is not so common.” — Voltaire
WebAssembly: Mozilla Won (Not a put-down to the excellent Chrome developers, but acknowledging the massive and important contribution Mozilla made here.)
We should be going the opposite direction and eliminating JavaScript altogether.
Though I agree with you and others that JavaScript has been abused, I disagree that the web ought to throw the proverbial baby out with the bathwater. In some cases, JavaScript dramatically improves the user experience in web applications. It makes others possible in the first place.
Say you want to let a user fill out a web form, but you don't want the poor experience associated with having to fill out the entire form and then perform a form submission and full page reload to catch the most common entry errors. The common way to improve the user's experience is by sending a short script that prevalidates the entries before the server validates them authoritatively, letting the user fix things before they're submitted.
Say you want to offer a chat service, where users send short strings of up to 100 characters or so to a channel and other users in the same channel receive them. You might consider putting up an IRC server, but your prospective users lack privileges to permanently install an IRC client on the devices that they use. You might try to do this as a web application without JavaScript, but you'll have to rely on users remembering to repeatedly click a "Check for New Messages" button to reload the iframe containing recent messages sent to a channel, which is a poor experience for users. In this case, the least bad option is a web application with a script that waits for new messages to arrive through a WebSocket and appends them to the list of recent messages.
Say you want to develop a real-time video game and allow members of the public to play it, but Valve, Apple, and the major console makers have turned your game down for one reason or another. So instead, you decide to offer the video game as a web application. The only interactivity possible without script is a form submission followed by a full reload of a page or iframe, but that's not possible for a real-time game. Thus script is again least bad.
If you're not convinced, I have more examples.
PNaCl and NaCl are *not* virtual machines!
Yes, they are sandboxed, but they are sandboxed by constraining the assembly language generated.
PNaCl differs only in that it sends the intermediate compiled code down to the browser to be processed in the final LLVM stage backend into assembly language within the browser.
The major reason for deprecating it is that a compiler back end is a lot to carry around for little benefit.
The reason the benefit is small, however, has less to do with PNaCl itself, and a lot more to do with how Google handles projects within Google, and my inability to actually pry my 20% time -- that I was promised when I was hired -- out of Google to do work on the problem.
I talk about it in another post.
The 'best' browser apps run literally thousands of times slower than what the native hardware is capable of.
If your computer happens to be something other than a Mac, a Mac app runs at zero speed.
If I lack the funding to develop my application for more than one platform, which of the following would reach the most users?
WebAssembly doesn't allow your code to do anything more than what normal JavaScript can do. It's really just a faster way to run JavaScript. It's not any kind of major shift except for allowing faster apps to be developed. There's really no need for signing as you wouldn't sign JavaScript either.