With the release of Growler and Yip (although with a misleading by-line), there is now an interesting but expected conundrum. Like any other multi-implementation of one idea, and such an awesome idea at that, notifications from web applications can and will benefit tremendously from a standard API.⌘
The Existing
From whatever I’ve gathered in the last week or two, currently there are two implementations of notifications. The Fluid way, or the Prism way. The Fluid way is more robust, and from a programming point of view, makes way more sense. Pass an object to window.fluid.showGrowlNotification with the required keys and you’re done. Of course, those keys are defined by what Growl accepts, but Fluid here doesn’t really need to do anything except pass the argument object onto Growl and let it handle the rest (translation of Javascript to Objective-C aside). Updates to Growl to accept more will be transparent to Fluid, and can directly implemented by the web application.⌘
Prism’s way is backward — passing three arguments each for the title, description and icon to window.platform.showNotification. Any updates to Growl will need a code rehash, which is always slow and cumbersome, even if it is Mozilla. But since Prism is open, it can be patched, so this is more of a non-issue. Of course, Prism being cross-platform means they have to support more notification APIs than just Growl, but that’s not the point.⌘
The Issue
The issue is the existence of these two separate namespaces, and pattern it motivates. Every web application out there needs to handle notifications differently based on whether it finds the fluid object or platform object. Any future platform will implement their own. Yip does well to support both, and it allows web applications to post notifications through Firefox without having to change anything. However it should not, just as Growler doesn’t1.⌘
What we should be aiming for is a uniform API for notifications across any application that uses an environment which contains Javascript. Whether that be WebKit, Gecko, or some new fangled engine X2. Define the specification for the next version of Javascript, and let the current notification systems in each OS implement whichever parts of it they want to. I don’t want to start with the terrible state of system notifications. I want to talk about that too, but in a future essay. Maybe doing this will help in bringing some standard to that as well.⌘
The other issue is a little deviant, but needs to be brought up.⌘
We have been trying to make web applications faster, better, and feel more native. But they need to start integrating with the OS more to be like native apps. And no, just allowing filesystem access is not integrating with the OS. The OS is not irrelevant. An application that runs in an environment can not be more important than the environment itself. Google’s latest announcement about Google Chrome OS should put that thought firmly in everyone’s head, as should the popularity of SSB’s like Fluid.⌘
The (temporary) solution
Until we reach notification API utopia, in consultation with Abimanyu, I’ve written a small library that aims to unify posting notifications for web applications. This supports all existing platforms, and all one needs to call is:⌘
window.notify(keys);
The keys are of course defined by Growl (since that’s the only notification API I have access to at the moment), but I’ll add support for more as apps like Fluid and Prism, and extensions like Yip implement them. All you (the web app guy) need to do is include the notifyLibJS.js in your <head>, and just call window.notify with the different keys. Example call:⌘
window.notify({
"title": "Woo!",
"description": "Yep, this works!"
});
That will post the simplest notification to all available APIs. I’ve made every key optional, but skipping some keys invoke a default behaviour. Not including the title will show the page’s title. Skipping the description shows ‘Notification posted from <domain>’, and if you don’t specify the icon, it will show the site’s favicon as the icon. You can remove all the default behaviour though. The code is clean enough.⌘
Needless to say, if no notification API is found, the library will silently fail. You can un-comment the exception messages so that you can debug if you need to.⌘
I’ll admit that this began as a way to overcome Growler’s lack of global object screw up, but something good came out of it. I hope this benefits new and old web apps alike, who want to start speaking back to the user in a way they’re more used to, rather than just putting coloured boxes on a page.⌘
Download
The library is released under a modified MIT license.⌘
notifyLibJS.js — Unified notifications library for web apps⌘