A year ago, I heard from a colleague about a competition Google was hosting to develop new extensions for the Chrome browser. Google had recently released the API to develop extensions, and they thought the competition might jump-start the process of building up a library of extensions from programmers outside of Google.
My friends and co-workers Pierre Heinzerling, Uwe Janner and I wrote an extension called Publinksky, which we published in mid-March 2010. We promptly lost. That was OK. For my part, I got to experiment some more with the Google App Engine (GAE), the Java Jersey (JAX-RS) library, the GSON Java to JSON library, the GAE data APIs, and JavaScript. Pierre got to work with some JQuery, and Uwe focused on the authentication portion of the Google APIs.
What did Publinksky do? Read the Fine Manual.
Some thoughts, a year later.
- It’s very easy to write a browser extension for Chrome. It’s also very easy to write a no-cost, hosted, server-side backend for the extension, assuming you need it. It takes minimal effort to get started. We should all be surprised by this, and by how unsurprised we actually are.
- The Chrome extension APIs appear quite stable. I was able to reinstall the plugin just now, many months (6? 9?) after last testing it, with multiple Chrome updates in between. Nice job.
- I found writing any substantial amount of JavaScript slow, as I’ve lost familiarity with the language, but more than that, the lack of any compiler support led me to make stupid errors over and over again which were only caught at runtime. Blame this on working too heavily with statically-typed languages for a long time now. However, IntelliJ IDEA’s JavaScript support did its best helping me find errors early.
- The Java server-side libraries have gotten better, easier to use, and slimmer conceptually. It took me almost no time to get a REST interface set up with the Jersey (JAX-RS) library, and making classes persistent was straightforward using annotations and the GAE persistence APIs.
- Google did a good job with the Google App Engine. Our server-side app is still running, 339 days after launch. I haven’t touched it since I last uploaded it. I can log in and see all the usage stats, data, manage versions, and so on, in one place. This is exactly as it should be and that means Google did it right.
- Developing multi-tier applications is not any easier, or much fun. In part this had to do with the fact that we were using essentially a beta release of the Chrome extension support. There’s a lot of starting and restarting, loading and reloading, and deploying and related nonsense associated with writing even a simple distributed application of this kind. The tools make this much easier than in the past, but in many ways it still feels like too much busy work. If I take this tool chain up again I will focus on some yak-shaving and work on preparing the tools to save me some time.
- Making a useful extension within the security sandbox is difficult. It seems difficult to write a useful browser extension that doesn’t require the user agree to a fairly liberal privacy policy. Our extension wanted to share interesting URLs with the home server so that friends could visit and comment on the links. To do this the user has to grant access to “your data on all websites” and “your browsing history”. Why? I believe “data on all websites” is so that using the extension, you could highlight a piece of text, then submit it along with the link. Making the clipboard available to the extension required this permission. And access to the browsing history was so that the extension could highlight links you had already visited. The fact that such broad permissions were required for fairly standard functionality makes me think this privacy model is simply broken. Why should you give such broad permissions to an extension written by someone you don’t know?
