Chrome Apps: JavaScript Desktop Development
by
at 2012-07-05 07:00:00
original http://feedproxy.google.com/~r/dailyjs/~3/W6eLBjl9DWk/evolution-chrome-apps
June was a month of tech conferences, but it was Google I/O that really stole the thunder of E3 and Apple’s WWDC. People are understandably excited about the Nexus 7, Jelly Bean, and Chrome for iOS, but what was there for us JavaScript hackers? All of the Google I/O sessions are available for viewing, and one that caught my eye was The Next Evolution of Chrome Apps.
I saw this video referenced on Twitter by TJ Holowaychuk, and given that his JavaScript aesthetics align with mine I wanted to know why he was talking about it. It turns out there’s a lot to like about the future direction of Chrome apps and Chromebooks from a JavaScript developer’s perspective. Offline is now being taken extremely seriously – partly because existing APIs are being adapted to cope with intermittent connections, but also because Chrome apps will be integrated with the OS (whether it’s Google Chrome OS, Mac OS, Linux, or Windows). This addresses a key usability problem people have with offline web apps: how are they launched? Rather than digging around in bookmarks or Chrome’s Apps page, we’ll now be able to launch them from the OS.
After seeing this talk, here’s my hyperbolic claim: Google is going to revolutionise desktop development. Watch the talk to see if you agree.
The part of the talk that stole the show was the Arduino demo. The new APIs allow applications to access OS-level features: networking, bluetooth, and even serial IO. Mihai Parparita (Chrome Apps Tech Lead, Google Reader) demonstrated an Arduino board that controlled a motor with a potentiometer, and a Chromebook (on the latest Canary build) was able to read and write data to it.
I’ve summarised the talk below, but if you’re desperate to see sample code then take a look at the GoogleChrome GitHub account and developer.chrome.com/apps.
Breaking out of the Browser
In Breaking out of the Browser, system-level integration is discussed:
- Launch apps from outside the browser
- First-class OS windows – rather than just using the DOM, windows can be created that work with native controls and shortcuts (including cmd/alt-tab)
- Full window frame without browser chrome
- Links open in browsers, not the app
The Bizarro World Window Demo demonstrates this. This is all done with JavaScript.
Offline by Default
The Offline by Default section deals with how new packaged apps are better able to cope with offline mode or intermittent connectivity.
- The interface and application logic are entirely local
- There’s an enforced separation of data and UI to help prevent apps from getting into a broken state
- An application should work without ever having connected to the network
- Older APIs have been updated to perform better during poor connectivity
- The fact apps launch from outside the browser helps people realise they work outside the browser and will function offline
There’s a demo of a diff tool that works differently offline. When the connection is lost, it immediately displays an offline notice and only allows local files to be opened. When it’s offline remote files can be opened instead.
New APIs
The new APIs are mainly concerned with OS-level integration.
- System APIs: interacting with the hardware (USB/bluetooth) or OS (TCP)
- Shared data APIs: interoperating with other apps (photos/contacts/calendar) accessed safely from multiple apps
- (Google) Web service APIs that run well under poor network conditions: analytics, ads
- Raw sockets, which Google employees have been using to create things like IRC clients
There’s a demo showing an Arduino board interacting with a Chromebook.
Programming Model
Of course, to facilitate all of these changes the programming model has changed somewhat:
- Applications use a “background page” with a main event
- The application life cycle is event-based
- System-level signals are accessible through an event-based API
- The APIs have bindings to more languages – Dart is mentioned, but I’m not sure what else they’ll ship with
- Background applications can be created
- Apps should be single page with no navigation – basically designed like desktop applications instead of web applications
There’s a bigger emphasis on the difference between extensions and apps. Extensions are now seen as something that modifies the browser itself, while apps are more like desktop applications. Some apps on the Chrome Web Store currently use extension-level functionality, but these will have to be changed to become extensions instead. I’m not sure if a package app can be distributed with an extension, because I’m sure there are some cases where the boundary is blurred – how does 1Password or LastPass fit into this model?
Security Model
The Security Model reviews Chrome’s existing sandbox approach, but also details some new features:
- Storage isolation ensures applications can’t modify data they shouldn’t have access to
- Applications can be restricted using a new permission system
- There’s a new
<browser>element that allows apps to render a page in a similar way to an iframe, but without the security issues
Systems Applications Working Group
It certainly seems like these changes will open up new possibilities for developers interested in targeting Chrome and Chromebooks, but doesn’t this mean we’re investing in vendor-specific technology that we can’t use elsewhere? Well, Erik and Mihai addressed this by announcing that Google is working with Mozilla, Samsung, and Intel on the System Applications Working Group:
The mission of the System Applications Working Group is to define an runtime environment, security model, and associated APIs for building Web applications that integrate with a host operating system.
They’re also in the early stages of looking at adapting this technology for mobile platforms.