Native Code On Chrome Dropped In Favour Of WebAssembly
Written by Ian Elliot   
Monday, 05 June 2017

Google has just announced that Chrome will no longer support native code in the form of PNaCl. Instead it will follow the lead of the other browser makers and rely on WebAssembly for fast code. In short, WebAssembly won.

chromeIcon

A native app is anything that compiles to the native machine code of the system it is running on - no virtual machines or byte code and no interpreters. Of course, this definition is very vague because the line between an interpreter and a just-in-time compiler is very fine. Whatever the definition, a native app is one that runs fast - as fast as possible - on the hardware. Browsers run JavaScript which has improved in speed over the years, but it is still much slower than native code. To allow Chrome to run native apps, in 2011 Google announced NaCl (Native Client). The idea was that compiled code could be run in a sandbox provided by Chrome. It allowed native programs to run in the browser at full speed and to prove it Google released some games.

The programmers who liked it really loved it and there was initially a lot of enthusiasm. Then the one big problem became apparent. NaCl was a Chrome-only feature and as time ticked on it looked increasingly unlikely that any other browser would adopt the technology. An improved version of NaCl was launched in 2013, PNaCl. This used a portable intermediate code which allowed native apps to run in a browser working on a range of hardware.

Even the programmers who thought that PNaCl was good, or a good opportunity to get their C/C++ programs on the web, couldn't avoid the conclusion that they were going to have to put a "Only works in Chrome" sticker on what they were creating.

Other browser makers, Mozilla in particular, expressed the opinion that native code in the browser was a big mistake and a case of old fashioned thinking. The future was HTML5 and similar technologies. The fact that they had no solution for running demanding web apps in the browser wasn't an issue that was much addressed. As a result support for PNaCl from programmers started to wain. Then there was asm.js and subsequently WebAssembly - both designed to make JavaScript go faster. At this point even Google must have started to think that PNaCl wasn't quite such a good idea.

Last year the PNaCl team was dispersed, but the open source project continued. Now we have definitive word the PNaCl is dead as far as Google is concerned:

We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions. We believe that the ecosystem around WebAssembly makes it a better fit for new and existing high-performance web apps, and that usage of PNaCl is sufficiently low to warrant deprecation.

So it was WebAssembly that killed it.

The really confusing issue is that PNaCl is still going to be supported under ChromeOS. This is because it provides the only way to run native code on Chromebooks. This is not a good situation for Google to be in and it is likely that it too will be deprecated in the not too distant future. After all, who is going to spend the time working on a PNaCl app for ChromeOS now that the technology is no part of Chrome.

Google has prepared some help in migrating to WebAssembly, but essentially all you have to do is recompile your C/C++ code to WebAssembly after changing any PPAPI calls to standard web APIs. There are going to be missing technologies that WebAssembly isn't going to support for a while - if ever. There are going to be casualties of the move.

The announcement encourages programmers to move to WebAssembly:

With the launch of WebAssembly, the web platform has gained a foundation for a new generation of fast and immersive web apps that run in any browser. We’re excited to see what developers build next!
 
Many are commenting that moving to any JavaScript-based technology is not for them. Some give rational reasons such as WebAssembly is too slow, but mostly there is a deep dislike of the language and hence anything based on it. The biggest problem is that WebAssembly is still immature and it will take time for it to develop to the point where it is the equal of PNaCl, but now that Google is on board we should see progress towards a viable cross-browser language that is at least close to native speeds.
 chromedevs
 

More Information

Goodbye PNaCl, Hello WebAssembly!

Related Articles

WebAssembly Has Mozilla, Microsoft,Apple and Google Backing It

Chrome Native Client Goes ARM and Portable

Chrome native apps split the browser world

Native client in the Chrome Web App store

Chrome beta adds native client

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

 

Banner


Dart Adds WebAssembly Support
20/02/2024

Google has released Dart 3.3 with experimental support for applications compiled to WebAssembly, along with new extension types and a revamped JavaScript interop model.



TypeScript 5.4 Adds NoInfer Type
12/03/2024

TypeScript 5.4 has been released, with the addition of a NoInfer utility type alongside preserved narrowing in closures following last assignments. 


More News

raspberry pi books

 

Comments




or email your comment to: comments@i-programmer.info

Last Updated ( Tuesday, 06 June 2017 )