Google Native Client to be App Store for Windows
Windows apps are hard to find, hard to pay for, hard to secure, hard to trust, hard to update, hard to cleanly uninstall, hard to install.
For a developer, they are hard to charge for (setting up accounts with some online payment whatnot), hard to protect from pirates, hard to package (what .NET version do your end-users need and how do they get it?) and so on.
Chrome’s Web Store can tick all those boxes.
Easy to find, easy to pay for, trusted because it runs in a sandbox so no nagging the user, updated through the web automatically, uninstallable in a click, installed in a click. For the developer, secured by Google account integration.
The Chrome Web Store is the in-browser app-store in the Chrome browser. Its increasingly taking over your start-page in Chrome. And one of the things it can package and sell are ‘native client (NaCL)’ apps, which are apps written in native code (or eventually an LLVM-pcode) that run inside a browser sandbox. They can do much the same as HTML5 apps, but they aren’t written in Javascript and they run at pretty much full-speed.
Once upon a time there was this little IDE called Delphi that made single-exe programs. It was a major simplification in making an app that others could easily run. Alas it was only really checking the distribution checkbox.
The number of chrome users is massive, and growing. Most of them are on Windows, and right now there is no cool juggernaut of an app-store on Windows.
When the iPhone appeared, apps were web-apps. Its hard to even remember those days. It was a flop. Then came native apps, and suddenly every programmer was imagining making hobby games for sale in their spare time. There was a way to get people to actually pay for something!
Chrome Web Store will do the same for the desktop. But its not just entertainment and time-wasting apps that will appear; all the serious business apps will also migrate.
NaCL can be used as little applets in-page. I think the big win though is full-window/full-screen apps (with back-button integration) that look and feel like apps, not web-pages.
There’s going to be a renaissance in native 'desktop’ apps, only without the desktop integration; rather, Google account integration and distributed through Chrome.
First will come the indie games and entertainment you see on phones now. Thats just another port for them.
Then will come a semi-native UI for Google Docs.
Then will come some AAA games. Right now many studio chiefs are speculating the demise of PC-based gaming citing the costs of targeting a platform that is so buggy and varied. Studios will see that an OpenGLES 2 port is not so hard - and increasingly useful in a high-end mobile world - and its Google that is mapping to DirectX and smoothing over the highly-variable hardware problem. Google solves a technical problem at the same time it introduces them to a different demographic to Steam and there’s nothing stopping studios doing both. You might well play your next The Sims -type installment in a browser, using common code from a game console version. AAA games go where the business partnerships push them, and Google can make that happen.
Then will come the boring business apps with semi-native UI. And that’s when I see the major change for us small-time coders. Small businesses and home users will be prepared to buy business and productivity apps that smooth corners for them, and buy big systems they have been sold. And us normal programmers can get into that game because we have a way of reaching the users and telling them we have a turn-key solution for filling in Estonian tax forms and that’s just what they need.
Native widget toolkits will be ported to run in NaCL. That is, they’ll be 'semi-native’. It will completely lap HTML-based UIs. HTML-based UIs were always compromising user experience for provider distribution and control convenience. Native Client gives both. You can get some measure of control by restricting the browser choice but that’s never worked out well for HTML apps. It’ll work just fine for an NaCL app.
The downside of course is that these 'native’ apps will all look as inconsistent as they always have, because there is no single UI framework or guidelines that they are following. And they won’t all magically work well at different screen resolutions or touch. That takes prorgammer effort. I hope the framework boffins - programmers always like making tools more than programs - embrace NaCL and put a lot of effort into smooth resolution solutions and touch integration.
In a corporate environment, getting someone in IT to approve the installation of Chrome (possibly in parallel to the company-mandated IE6) is one hurdle once by one person; getting IT to approve each and every native win32 app is one hurdle per app per person.
I haven’t looked into the backend of the Chrome Web Store itself but I rather hope its using Courgette-style updates and, eventually, deduplication. There’s going to be a lot of apps with the same big chunk of framework compiled into them. Lots of duplicate bytes between packages.
There are things Chrome can do to make this better: The Intents system from Android would open up a whole new way to make apps and inter-app flows and its a good model for dealing with the dreaded back-button. Peppar is still missing IndexedDB and I haven’t noticed video neither. And you can imagine desktop integration e.g. automatic shortcuts on desktop, perhaps notification widgets or C2DM integration, top-level windows.
Desktop apps can rummage around in filesystems. NaCL apps cannot. If the user selects a file using a picker for the NaCL to consume, the NaCL app cannot open other files (giving it a document cannot let it open a template without tedious user intervention) and it cannot seamlessly save it back. Its more import than in-place access. On reflection, this is likely not as big a deal as it might sound. I can live with this, and can imagine everyone else living with it too. Sandboxes are what give me confidence in this.
And I’m really looking forward to it!
↓ click the "share" button below!