Google has pretty much given up on developing a JavaScript API for GMail. There was once a Greasemonkey script Google developed for GMail but that broke and Google shows no sign of fixing it.
James Yu is now trying to fix that scenario with GMailr, a JavaScript API for GMail. It is made from the code he wrote for 0Boxer, an extension for GMail that turns organizing your inbox into a game. Yu is also a lead developer at Scribd.
Yu said developing the API took him on a path fraught with frustrations and dead ends. He writes there is supported official JavaScript API for Gmail. The Greasemonkey script is broken and no one has yet released a frontend API for Gmail. He said he needed access to the various user actions in the UI as the backend APIs were not going to work as he wished. He decided to write his own library from scratch.
But this was no easy task. Gmail runs its code through the closure compiler, thereby obfuscating everything. On top of that, Gmail is probably one of the most sophisticated JavaScript apps out there. Needless to say, I am now intimately familiar with the various DOM elements that make up the Gmail interface, as well as how the data is transported.
The work Yu is doing reflects on the fragile state of services such as Rapportive, Baydin and Unsubscribe.com, each of which have developed complex APIs that can and will break when GMail decides to change its app structure.
What we need, he says, is a robust and easy-to-use Javascript API for GMail that is shared across extensions and applications. He hopes developers will improve Gmailr, and over time, make it a robust API that developers find useful. He cites a few ways it can be improved:
- Expose methods that allow insertion of UI elements into various places in Gmail, like the sidebar.
- Improve the reliability of the API, taking into account the various weird states that Gmail can get into.
- Add capabilities to read the contents and metadata of emails received, sent, and interacted with.
Yu’s work points to the need to create APIs that are not dependent on powerful vendors. Independent providers such as Rapportive should be supportive of these efforts for they provide a level of sustainability that otherwise could result in service breakdowns and irreparable damage to the communities they are seeking to grow.
