
Goodbye PNaCl, Hello WebAssembly - Ajedi32
https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html
======
eeZi
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 and makes them less secure.

Now everyone is moving to Electron and instead of one Chrome instance, I'm now
running five which use more than one GB of RAM each. Much less secure, too,
since each has its own auto-updater or repository and instead of being
sandboxed by Chrome's sandbox, they're all running with full permissions.

It also means I cannot longer use Signal Desktop on my work device since
installing native apps is forbidden for good reasons, while Chrome Apps are
okay.

It also hurts Chrome OS users since Chrome Apps are being abandoned in favor
of Electron. It also makes it less useful for developers to create Chrome Apps
since the market is much smaller.

Since Chrome Apps continue to be available on Chrome OS, I'm considering
separating that functionality into a stand-alone runtime or making a custom
build for Linux. Anyone wants to help with that?

~~~
quickben
Add to that list:

\- unblockable advertising

\- stronger DRM

\- Bitcoin mining that regular user can't detect

\- etc..

It will be good and bad, but, more bad than good.

We could choose not to run .exe .bat and the rest

So far, webassbly doesn't look optional.

~~~
pcwalton
> \- unblockable advertising

Ad blockers primarily look at domains, so blocking will continue to be
possible at the request level. They aren't interpreting or parsing JS to begin
with.

> \- stronger DRM

If sites were going to ship Web Assembly-based DRM, they would already be
shipping Web Assembly along with the Emterpreter. Remember that wasm has a
polyfill already. I haven't seen that happening, so I see no reason to believe
it'll happen in the future.

> \- Bitcoin mining that regular user can't detect

A regular user certainly would notice the 100% CPU consumption. And anyway,
bitcoin mining in a WebGL shader would be more profitable than anything wasm-
based.

Moreover, though, surreptitious bitcoin mining on consumer PCs would be
ludicrously unprofitable no matter what. Here a Stack Overflow answer _from
last year_ that calculates how much a site with 2M daily visitors would make
_if they could all somehow run the fastest C implementation_ [1]. It was less
than 50 cents a day back then, and in the meantime the hash rate has grown by
nearly an order of magnitude [2]. Good luck.

[1]:
[https://bitcoin.stackexchange.com/a/42413](https://bitcoin.stackexchange.com/a/42413)

[2]: [https://blockchain.info/charts/hash-
rate?timespan=2years](https://blockchain.info/charts/hash-
rate?timespan=2years)

~~~
ehnto
I doubt a regular user would notice 100% CPU usage and even less certain that
they would know what to do about it or what was causing it. Most OSes operate
chrome just fine when another process is asking for 100% as well.

~~~
bas
Their fans running at max (or a very warm device) would let them know. This
has been the experience among the non/less-technical users in my company.

~~~
ehnto
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
concern to your company maybe an automated CPU usage monitor could alert the
team to anomalies.

~~~
spc476
They would care when their laptop shuts down. [1]

[1] I was running a test today when the program being tested ran into a very
tight loop and the fan _really_ kicked in. I was curious if it would finish
and let it run for several minutes until all went quiet and the screen went
dark. It had shutdown to prevent heat damage.

~~~
witty_username
That means the fans need to be cleaned of dust.

A laptop overheating from few minutes of 100% CPU is not normal.

~~~
thegreatpl
Unless it is a really crappy laptop.

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

~~~
bitmapbrother
How exactly did Mozilla win this fight? WebAssembly was inspired by Mozilla's
asm.js and Google's PNaCl. Also, the team working on WebAssembly are from
Mozilla, Microsoft, Google and Apple. The real winner here are users because
we now have a standard among all major browsers.

~~~
roca
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 are now going by the wayside.

Mozilla put together a small team and did asm.js to show that you could port
C/C++ apps to the Web and get good performance while reusing the JS engine and
all the existing Web platform APIs.

Now we have WebAssembly, which uses existing Web platform APIs and which
browser vendors are implementing by reusing the guts of their JS engines. It's
obvious who won.

In a way it doesn't matter "who won" because as you say Web developers are the
ultimate winners. But it does underscore how much the Web continues to owe to
Mozilla.

(It's also an illustration of how powerful companies can commit massive
blunders and get away scot-free in the marketplace and in PR.)

~~~
dragonwriter
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.

~~~
roca
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.

~~~
dragonwriter
> Google wasted huge resources on an approach which it was obvious from the
> beginning would never lead to a Web standard.

But it _did_ lead to a web standard, even if it didn't _become_ one. And in
the interim, it provided utility to Google.

> Mozilla people, including me, told Google people even before PNaCl appeared
> that introducing the whole new non-standard Pepper API was unacceptable.

Yeah, you've mentioned that quite a few times. So what? Unacceptable
nonstandard moves are a big part of what stimulates standards progress.

~~~
roca
If spending any amount of resources to get any amount of utility counts as
success, then there is no such thing as failure.

~~~
will4274
Google makes money from the web. Massive amounts of money. Something like 93%
of their revenue. If WebAssembly leads to the decline of mobile apps, the
amount of resources that Google spent on PNaCl is so tiny compared to the
amount they will make by continuing to own the world of online advertising.

------
lwlml
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 application for the browser to find it rots out from
underneath them.

Should you even be slightly successful in the use of an API, you always have
to worry about deprecation when someone is no longer interested in doing the
maintenance any more.

I am sure there were more than a few game developers that are are livid today
about this announcement.

These things will go in cycles and I expect there will be an native-
application cycle coming soon from browser-api-fatigue.

~~~
irrational
Yeah, we were looking at browser stats for our website today and during the
last 30 days 20% of our distinct users were using IE 6, 7, 8, 9, 10, or 11. Of
course most were on IE 11, but when you still have a significant number of
people still using ancient versions of IE, I despair at ever being able to use
modern web technologies.

~~~
spiderfarmer
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"

~~~
irrational
Unfortunately that isn't an option for us. We are mandated to support
everyone. And those people on IE are retail sales associates using our site on
hardware that simply cannot be upgraded. It must be replaced to get a newer
browser. But the replacement cycle is measured in decades.

~~~
indolering
> And those people on IE are retail sales associates using our site on
> hardware that simply cannot be upgraded.

I'm sooooo glad I'm not you. I've literally halted all personal projects using
JS until they get modules implemented natively.

------
nimrody
Then perhaps Andreas Gal's "Chrome Won" assertion wasn't entirely accurate.
After all WebAssembly is something that was derived from Mozilla's asm.js.

~~~
pvg
The assertion was about market share so the fact that Chrome might have
adopted some mozilla-derived technology doesn't affect its accuracy.

~~~
dtech
Yep, consider x86_64. That's an AMD instruction set but it's very safe to say
that Intel at the moment has won the desktop CPU market.

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

~~~
dragonwriter
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.

~~~
cbhl
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.

~~~
dragonwriter
> 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.

~~~
i336_
WebSQL is so sad.

[https://stackoverflow.com/questions/42288596/websql-has-
incr...](https://stackoverflow.com/questions/42288596/websql-has-increasing-
browser-support-whats-its-future)

------
gklitt
It seems like the browser vendors are doing a good job coordinating to provide
a robust ecosystem around Web Assembly. Clearly much healthier for the future
of the web than fragmented browser-specific solutions.

------
seanwilson
I'm so confused why Google deprecated Chrome Apps. You'd think they'd take
advantage of the abundance of Electron apps by extending the capabilities of
Chrome Apps to grow their Chrome ecosystem and attract new developers.

------
coolmitch
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?

~~~
camus2
WebAssembly is a medium for ASM.js apps, and ASM.js apps are mainly C and C++
. You have to learn C and C++ period.

~~~
dasmoth
Right now, that's probably the best way to go if you're keen to build non-
trivial wasm stuff, but I don't think it's a foregone conclusion that it'll
stay that way. There's a Rust implementation now, for instance. And some talk
of better support for garbage collected languages.

------
tehabe
Am I in the minority that I think it is a positive development, when Google is
discarding proprietary ideas in favour of open developments?

Not perfect but the direction looks good so far.

~~~
angry_octet
If you care about security, performance or having portable offline
applications its a sad day. Google just pressed reset and erased your work.

The way Google has abrubtly sent PNaCL to the knackery, rather than a gradual
transition is just ugly. By removing the PNaCL functionality completely from
builds they have broken faith with the development community. They didn't even
commit to allowing PNaCL to run in deprecated mode via a feature flag or
something.

In hindsight, I can see that Google had shifted their effort away from PNaCL
several years ago. But to kill it they way they have it just brutal.

I would agree that for general web development this seems a way out of the
javascript purgatory. But there is a long way to go before it can match what
PNaCL did. And I find it bizarre that they created a 32 bit implementation; I
know they had _reasons_ but they seem shortsighted.

~~~
roca
AFAIK the main missing feature in WebAssembly that PNaCl had is shared-memory
multithreading and that is implemented and waiting on spec finalization to
ship. What else is there?

~~~
angry_octet
Security (code signing, timing determinism, large API attack surface, complex
javascript interpreter/jit), performance (obvious deficit between an IR
bytecode and jit, static analysis vs runtime checks), concurrency (how many
cores on your new 2017 box? By 2027?), features (the p/nacl api let you do
more, like access devices for video/graphics/audio; instead it will be an
implementation specific thing; networking - open sockets to unrelated hosts;
same origin is a straight jacket), elegance (wasm/asm.js/js is just hack,
hack, hack; thanks Mozilla), maturity (just bugs need time to be sorted).

~~~
roca
I don't think PNaCl guarantees timing determinism.

Not sure what you mean by "code signing" in this context.

The API attack surface is a non-issue; it's already accessible by any page
that serves a PNaCl object.

There's a small performance deficit but it's getting smaller. AOT compilation
and caching of compilation results is possible; asm.js did it.

I already mentioned shared-memory parallelism (it's just about done); did you
read what I wrote?

Standard cross-browser Web APIs give you access to those devices already.

Same-origin is a strait-jacket --- a necessary one. "Break the Web's security
model" isn't a desirable feature.

"Elegance" is just a point of view. From another point of view, "duplicate
everything in the Web platform" is not elegant.

As for maturity and bugs --- having multiple interoperating implementations
and real specifications is a good way to drive competition on quality ... and
to distinguish "this is a bug, fix it" from "hello de-facto standard!"

------
lawthemi
It's sad. PNACL is more efficient. Go to lichess.org/analysis, make a few
moves, turn on the engine analysis. With firefox and WASM, my machine compute
300 knode/s. With chrome and PNACL, my machine compute 2000 knode/s. That's a
big step backward.

~~~
gok
I see nothing inherently more efficient about PNaCl. Both it and WASM expose
an architecture-agnostic 32-bit virtual instruction set, then rely on the user
agent to apply good optimization. WASM’s performance will improve.

Non-portable NaCl did have the advantage that it could specifically target and
optimize for one CPU architecture, and it had the beginnings of 64-bit address
space support. These were nice, but not widely used. And we both could
conceivably make it into WASM in the future.

------
jhpriestley
From the asm.js FAQ:

    
    
        Q. Why not NaCl or PNaCl instead? Are you just being 
        stubborn about JavaScript?
        A. The principal benefit of asm.js over whole new 
        technologies like NaCl and PNaCl is that it works today
    

asm.js however wasn't good enough to actually be useful, as evidenced by the
lack of adoption and the move to wasm. So now we have wasm which is not
backward compatible. We would be further along now if Mozilla/Eich would have
gotten behind Google's more mature effort, this really was stubbornness IMO.

~~~
roca
PNaCl had two big problems Google never attempted to solve: * No spec, just
import some particular version of LLVM and it does what it does * Dependence
on Pepper for its platform API --- just a big pile of Chromium code that does
what it does _and_ duplicates all the standard Web APIs

~~~
jhpriestley
I don't have any insider knowledge, but my sense is that Google never tried to
solve these sorts of issues because Mozilla made it very clear that they
wouldn't support it. Now they're backtracking and building a non-js asm system
too. Do you think wasm apps will always use slow JavaScript ffi to call opengl
say? We'll get a new pepper in like another decade.

~~~
roca
I personally told Google people that the Pepper platform API situation was
unacceptable to Mozilla years before PNaCl even appeared. That didn't stop
them pushing ahead. So if your theory is correct then Mozilla opposition was
not strong enough to stop PNaCl development, and not strong enough to stop
them exposing it to the public Web, but strong enough to stop them trying to
turn it into a proper Web standard.

Wasm is only superficially non-JS. AFAIK every browser vendor is implementing
Wasm by reusing the optimizing compilers in their JS engines.

I think we might see some extensions to WebIDL and Web platform APIs to
improve Wasm app performance. We're sort of already seeing that with
[AllowShared]. But there's no need to develop entirely new platform APIs,
because fundamentally there's no reason calls from Wasm through JS API glue to
the browser should be slow; JS API glue can be inlined into the Wasm code, for
example.

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

~~~
dragonwriter
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.

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

~~~
dragonwriter
> 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.

------
willvarfar
This is a sad day. NaCL was excellent tech, and its a shame it didn't get
incorporated into LLVM proper, and that it didn't take off. We should be using
NaCL/pNaCL for all apps everywhere, and for components within apps... etc.

ZeroVM was a desktop/server sandboxing environment that just didn't get any
attention and mindshare. Shame!

I want a ZeroVM-like system that makes all of the Debian user-space available
on any other OS, each app in a little sandbox... It ought just be another
compiler target and automated.

Oh to what could have been! :(

~~~
krzyk
How is it better than WebAssembly?

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

~~~
traverseda
Have you seen the "the birth and death of javascript"? More interestingly it
could vastly reduce the cost of interprocess communication to the point where
the idea of a process starts to look a bit weird.

Want to query a database? Upload a function you wrote yourself for complicated
queries like GIS, or let the SQL parser generate the raw wasm on your behalf.

Want to authenticate your users, but don't want to deal with all the different
permiations on hardare tokens, ssh keys, etc? Just let them upload a wasm
function.

~~~
willvarfar
_cough_ java was supposed to do all that, right?

~~~
traverseda
It seems like a lot of people were simply unwilling to support java. Bundling
the execution enviroment with such an un-fun language was probably a mistake.
Not to mention the patents and oracle in general.

It was before my time, but I don't imagine the open source community was ever
going to really embace it.

------
xoroshiro
I'm not familiar with what goes in a browser, but for some reason, browsers
seem to eat up a lot of resources.

While I am happy that it looks like this will (more or less) be standardized
across browsers, I still hope for the day where running a more minimal browser
(text, image, maybe videos) will become viable. Of course, I'm pessimistic on
this, seeing as so many sites are probably not functional without javascript
and other related technologies, but maybe some web developers care about
choice. Who knows.

~~~
Ajedi32
Well, there's AMP. Most people on HN seem to really hate that solution though.

------
JacobiX
We used PNaCl to port some games to a Smart TV. It was a painful experience.
Debugging chrome from a custom gdb, breaking changes from release to release,
and some very subtle bugs in pepper API. But the final results were
surprisingly not so awful.

------
camus2
Why bother investing time and resources in Google techs when they keep on
discontinuing them? they don't care about enterprise software, if they did,
they wouldn't act like that. AMP? lol, think again before implementing this,
it will not be worth the effort since Chrome will eventually drop that too.

A good reminder not to invest in any Google specific technology.

> We recognize that technology migrations can be challenging.

You recognize you wasted a lot of people's time.

~~~
josteink
> Why bother investing time and resources in Google techs when they keep on
> discontinuing them?

I really think this is a good question, despite the form of your post (hence
the downvotes).

To anyone who decided "lets use NaCl or PNaCl", I have a genuine question: Are
you honestly surprised to see this tech too go obsoleted?

> We recognize that technology migrations can be challenging. ... You
> recognize you wasted a lot of people's time.

They are taking this from Apple's book: Don't leave any compatible stuff
behind. Leave the maintenance-cost to others.

------
Crontab
Is WebAssembley going to turn into yet another web technology that can be used
by websites in order to track us or to annoy us with advertising?

I'm asking because every time something new is introduced, it feels like it
ends up being used to abuse users (Javascript, XSS, Cookies, HTML5 Video).

~~~
marcosdumay
It doesn't do anything that Javascript didn't already do.

By the way, why do you think HTML5 is a problem?

~~~
duskwuff
The suggestion I got was that "HTML5 Video" was the subject. Which still
doesn't make sense; the alternatives which it replaced (Flash, QuickTime, WMV,
Java-based video players...) were all radically worse, and much more
abuseable.

~~~
Crontab
HTML5 Video is just an example of shitty browser behavior, as for some reason,
every web browser maker seems to think that autoplay videos are great. They're
not because sites are abusing it.

Worst, some sites these days will waiting until you've scrolled down a bit
before they start playing a video, leaving the user to locate it and stop it.

As for Flash, it was indeed bad, but at least I had the option of not
installing it.

~~~
duskwuff
> every web browser maker seems to think that autoplay videos are great

Huh? This has nothing to do with browsers; it's purely a site author decision.
Autoplaying videos is a site author decision -- and one that they already
frequently made before HTML5 video was widely available.

~~~
nojvek
Not really. Browsers just need to default stop autoplaying videos out of the
screen view. Or better yet what they did to popup blockers. Give one chance to
behave well, if the site doesn't then it gets blocked and the user has a
notification that autoplay was disabled.

~~~
roca
Blocking scripted calls to "element.play()" really sucks for Web developers
building games and other kinds of apps. Safari on iOS did this and it was
horrible for developers.

Firefox and Chrome let you mute tabs. Firefox Nightly also blocks playback in
any tab you haven't actually looked at yet. Other than that there's not much
they can do.

------
TekMol
Can somebody ELI 5 what is the benefit of WebAssembly vs Asm.js?

~~~
johncolanduoni
It's a format designed to be a target for static languages that do manual
memory management (like C/C++) instead of JavaScript that some engines know
how to recognize and optimize. The binaries are smaller and _much_ faster to
parse and the sandbox model results in much less overhead.

For a concrete example, at least two JavaScript engines (those of Chrome and
Firefox) need to emit almost no range checks on regular memory accesses with
WebAssembly on 64-bit computers. (For those interested in going past ELI5,
they do this by allocating a large chunk of virtual address space, such that
any out of range pointers will land somewhere in that space (WebAssembly
currently only has 32-bit pointers). Some of the space is filled with memory,
and the rest causes a controlled signal/exception so the engine can safely
terminate the instance.)

~~~
TekMol

        target for static languages that do manual
        memory management
    

So I will have to do all the garbage collection myself? Isn't that a huge
burdon on the programmer? And will this lead to lots of apps with memory leaks
that needlessly eat up my resources?

~~~
AgentME
That's already the case if you want to do high-performance stuff with C/C++.
WebAssembly is primarily about getting that into the web.

------
r0anne
>We will remove support for PNaCl in the first quarter of 2018

While the new Google Earth with PNaCl was just introduced, a large engineering
cost for a semester-lived technology! Too bad

~~~
nnethercote
Plenty of people were left scratching their heads when the new Google Earth
was introduced, precisely because it was clear that PNaCl's days were
numbered.

I think the likely explanation is that Google is a large company with numerous
departments and those departments don't always pull in the same direction. I
imagine some people within Google weren't happy with the Google Earth
announcement.

------
ap46
Can someone get opencv running on it?

~~~
Houshalter
Webasm doesn't currently have access to SIMD instructions or the gpu. So that
kind of intensive matrix math stuff might not benefit too much from webasm.

------
zurn
Say hello to memory-unsafe languages and resulting vulnerabilities in web
apps?

~~~
roca
To some extent yes, but not nearly as bad. One feature Wasm has (shared with
asm.js, but NOT PNaCl) is that the stack of return addresses lives outside
addressable memory, and therefore can't be corrupted by an arbitrary-write
primitive, so no ROP attacks. Likewise Wasm memory is entirely non-executable
so you can't return or jump to exploit code. Function pointers are quite
restricted; you can only make an indirect call to a function that's explicitly
listed as indirectly-callable.

Wasm applications can have type confusion bugs, use-after-free bugs, and array
overflow bugs, etc, but this is inevitable for any realistic C/C++ compilation
target.

