The Chrome Route

Two weeks ago [I talked about my little editor project]( In the meantime work has progressed quite a bit and I’m really liking where it’s headed. However, one thing I had not yet figured out at the time was deployment: how are people supposed to get and run this editor? Since it’s all based on web technology the obvious answer would be: web browser!

However, there’s some drawbacks to that approach:

1. Many people still want to edit source code that resides locally (including me) and that web apps don’t have access to.
2. Many people want to edit even if they have no internet connection available (including me) while this is all technically possible with HTML5, my experience has been that the HTML5 support is not yet very stable, also it’s counter-intuitive to start up a browser while you’re offline (what’s the point?)
3. Web apps have to be hosted. I’ve been very closely involved with hosting a web-based IDE before, and I have no interest in repeating that exercise in my spare time.
4. Browser compatibility. Yes, I hear all the incompatibilities have not yet been resolved. Any day now, people. Any day now!

An alternative approach would be to wrap it in something like [node-webkit]( and create a downloadable application. However, this approach has problems too:

1. You have to host the application’s downloads and prepare builds for all platforms.
2. Upgrades are tricky: you either need to build in support for upgrades in the application, or just ask users to download a new version from time to time. Either way it’s work for somebody.
3. I would like to offer cloud features, like automatic syncing all your editor settings between devices. Yet, I have no interest in building an infrastructure to support this.

Basically, going with a downloadable app would mean going back to the pre-web days. Don’t want to do that.

So, after doing a quite a bit of research I chose to go a slightly different route: [Chrome Packaged Apps](

If you package up your application as a Chrome App, you get [access to APIs]( you usually wouldn’t have access to (like simple key-value storage that syncs between your machines), it allows you to create various kinds of windows (including ones without any chrome — hah!), bind global hotkeys and in the future: get its own desktop application icon, i.e. you can run the application without having to fire up Chrome. It does have some constraints: you cannot randomly access the local file system, although you can open and save to individual files. Also, the environment is designed to be more secure than a regular webpage, e.g. no inline scripts or eval [and some APIs are disabled](

Chrome Packaged Apps are in principle fully offline capable. When the user installs the application all resources will be downloaded locally, so that it can be launched offline. In addition, Chrome automatically handles upgrades and offers storage sync APIs to easily sync application settings between devices you’re logged into (think: editor preferences).

Of course, Chrome apps are specific to Chrome, but quite frankly I don’t care. I use Chrome as do most other people that I know. I tend to be pragmatic in these things. I don’t have the time nor interest in ensuring compatibility with other browsers. Who knows, if and when Firefox will offer similar capabilities (maybe they already do), I or somebody else can repackage it as a Firefox app.

Until then: Chrome only. And yes,, this will be the app that will make ChromeBooks viable (Google, feel free to send me a [Pixel]( for testing).

All in all [Chrome Packaged Apps]( are pretty interesting Chrome feature. Currently it’s not yet possible to upload these applications to the Chrome Webstore, but it [will be “soon”](