David Clarke does Blogging

Firefox vs Chrome App APIs How do the API’s compare ?

When porting a chrome packaged app to a firefox packaged app you will need to do an inventory as to which chrome specific api’s you are using and create a level of abstraction around them, as the naming / capabilities of the apis vary across the platforms.

I will try to break this article into information on which apis are supported across both platforms, where you can find docs, and lastly which apis have no commonality across both platforms (Firefox or Chrome).

Web APIs in Common:

The Web APIs that share commonality in function between the two platforms, are listed below:

The difficulty for the developer will be in writing an app that can handle both browsers elegantly. This is already done in many cases with the use of W3C compliant API’s such as geolocation data.(navigator.geolocation, which is also supported under google chrome, just not listed as such in their packaged apps documentation (ack), and soon to be battery status. But for the majority the function calls are different as well as the data being returned.

Basically this is a bit of a cluster bug until W3C steps in these APIs aren’t close enough to easily describe all the differences in one document. The best case scenario is if you are only using a subset of the above APIs and you manually code an abstraction layer, or use an intervening javascript framework like phonegap which would make the interfaces of less consequence to the developer.

The other part of the discussion could revolve around which Firefox OS API’s are not yet implemented in Chrome OS. How close are all the APIs to standardization ?

The APIs that I would personally like to see implemented are around internationalization, serial, usb. I believe if there are to be different types of devices / targets out there it will be helpful for end devices to be able to read / write to serial /usb. This could enable a suite of new types of devices / functionality we don’t really expect.

I think HTML5 definitely needs to think about how to support background processes, I am unsure what mechanism that may be in the future.

The take away from this article would be to experiment / deploy as you write your apps, and definitely make sure you have a level of abstraction around APIs that are not standardized through the W3C, as they may change, and your app will likely have to change as a result.

Here’s a neat project that utilizes Chrome USB/Serial APIs for connecting the editor to the device: http://www.espruino.com/
The developer expressed interest (after talking to him during the kickstarter campaign: http://www.kickstarter.com/projects/48651611/espruino-javascript-for-things) in releasing an editor that works with Firefox when it supports Chrome’s APIs – that won’t happen, though, but similar APIs can be introduced in Firefox (at least for extensions).
The WebUSB work is unfortunately in hiatus at the moment, and it would not (AFAIK) provide access to a serial port which the Espruino editor requires.
I’d really like to have an alternative to Chrome for developing with this platform, so here’s to hoping Firefox will introduce APIs that extensions can use to connect to arbitrary hardware (via USB/Serial/whatever). I wanted to file a bug about that since a few weeks …