Several major web companies are pushing the idea of using web apps as replacement for native apps, including Google on desktop and Mozilla on mobile. The launch of the Chromebook and the continued developments in their web apps signalled that Google definitely wants web apps, such as those on the Chrome Web Store, to supersede most traditional native apps like office suites. While there has been little news about them since their launch, I always loved the vision of Chromebooks being used in education environments with their low-cost, less-likely-to-break nature.
However, Google seems to have taken a bit of a step back from the vision of an entirely web-app powered computer by introducing a plugin for NaCl (Native Client, not sodium chloride) apps to be executed within a browser.
How NaCl Apps Work in Chrome
Essentially, Native Client apps are powered by the NaCl plugin in Chrome which gives the browser the ability to executive traditional C and C++ applications within a browser window on Windows, OS X, Linux and, perhaps more important, Chrome OS.
NaCl apps are safe, however. Native Client apps are sandboxed within the browser and Google restricts what privileges the app has access to. Additionally, Chrome will scrutinise an app’s execution to make sure it isn’t doing anything unsafe, like writing to a hard drive. Essentially, Google will answer for you the question “do you trust the source?” that many of us are asked when trying to run download software on Windows, or OS X.
Currently, there’s only four NaCl apps which are hardly anything special. Nonetheless, they are creating a path for future, potentially more popular apps to make their way into the Chrome browser.
Native Client apps listed in the Chrome Web Store are hardly anything special, and currently there's only four of them.
Contaminating Web Apps
My first thought when I saw the news was that these apps would, for lack of a better term, contaminate the web app ecosystem. The theory of a Chromebook and Chrome OS is great, and the fact that little computing power is needed means that working entirely in web apps is a distinct possibility in comparison to primarily native apps. A web app is optimised for a universal platform, not ported or emulated, so it can generally run in most environments perfectly.
Unfortunately, NaCl introduces the possibility for a lot more crashes, performance slowdowns and the like because, to put it simply, they aren’t (really) meant to be on the web. It’s like wearing sandals in the snow, it’s possible but there’s a high likelihood of undesirable consequences.
Forming New Links
On the other hand, the existence of NaCl as a “compatibility” option could build more links between a native and web-powered environment. All major Adobe apps are written in C++, including Photoshop and Illustrator, as are a lot of games. Imagine a Chromebook turning into a gaming machine!
Having the option to use these apps, albeit ported into a new environment, while maintaining the benefits of using a web-based operating system in other areas is arguably a best case scenario. It’s just unlikely C++ developers, like Adobe, will ever get on board and port these to Chrome OS.
Now offering native apps!
Get to the Answer!
My ultimate opinion is that no, I don’t really want native client apps in my browser. I just don’t see a reason or scenario in which this would be favourable, even though their are a few benefits. If I was to pick a web-only platform like Chrome OS, there’s clearly little need for native apps in my workflow, and if there is, I should be using them on a platform they’re optimised for like Windows or Mac OS X. Plus, the types of potential NaCl apps generally have adequate web-based alternatives which aren’t to be shrugged off.
Do you think this is a step forward, or a step back for Chrome? Let us know in the comments below.