My entry from Tuesday on the changes to Gmail that disabled a variety of Greasemonkey scripts and a Firefox extension has spawned a couple of interesting criticisms both here in the comments and abroad that I wanted to comment on. There are two basic attacks on my original post; first, that expecting service providers to show any consideration or responsibility for GM type extensions is absurd, and second that the technical foundation that Greasemonkey and like applications is built on is essentially groundless. Interesting points, both. A few clarifications and responses:
- Responsibility of Service Providers:
Dan Sholler’s got some interesting thoughts in this area, but I apparently failed to be clear as to what I expected from Google, given a few of the comments and Dare’s post here:I find this hilarious. Greasemonkey scripts work by effectively screen scrapping the website and inserting changes into the HTML. Stephen and others who are upset by Google’s change are basically saying that Google should never change the HTML or URL structure of the website ever again because it breaks their scripts. Yeah, right.
Repeat after me, a web page is not an API or a platform.
Given that this is not what I intended to say, I think it behooves me to clarify my original remarks. So let’s start with what I’m not saying, and for that I may as well just borrow Dare’s words. “Stephen and others who are upset by Google’s change are basically saying that Google should never change the HTML or URL structure of the website ever again because it breaks their scripts” – that’s exactly what I’m not saying. I tried to emphasize this in my original post with the following, “While it’s Google’s perogative to make changes to the service as necessary for maintenance or other reasons,” but apparently that didn’t come through. So let me state for the record that Google, and any other service provider for that matter, absolutely has the right to change their application as they see fit. Every day, every hour, every minute, if that’s their thing. What I am saying is that changes have consequences. Developers are actively extending the functionality of these services with Greasemonkey scripts and the like, and given the importance developers hold today, that relationship may be worth considering when making modifications. As I just said to one commenter, my expectation is not that Google takes responsibility for ensuring that each and every script continues functioning after they make changes, let alone that they never change the HTML or URL structure as Dare contends. No, that’s clearly not possible in any sustainable or ongoing fashion. But when there’s a major change such as the base URL, do I think it’s unreasonable to expect that Google might announce it ahead of time? Just to give the developers making Google’s service more valuable to me a heads up? Nope. Think of it this way; when you’re in a relationship with someone, there are things you don’t technically have to do to preserve that relationship, but will anyway because it’s a small thing and is likely to make the other party happy. Wouldn’t you want to do that? Or would you just sit back saying, that’s not my job so I won’t bother?
- Technical Foundation:
The other primary vein of comments on this thread, one I’ve heard previously when extolling the virtues of GM, is that the approach of Greasemonkey (DOM scraping) is hopelessly flawed. The always excellent Bill de hÓra takes this position here:Greasemonkey is a cool idea, but these scripts are so fragile it’s not funny; they make side-effected GETs look robust. The page DOM is not part of the API contract, which is the basis of Alex Bosworth’s argument. In programmer terms it’s like depending on the field names rather than the field values. You build on this stuff, you more or less commit to lockstepping with the server. It feels house of card-like.
To Bill’s point, is Greasemonkey like a House of Cards? Yes, absolutely. That’s both its weakness and its strength. Because as quickly as the scripts in the Gmail example broke, they were updated and functional in most cases same day. A House of Cards, after all, is easily knocked over, but just as easy to put back together. Likewise, Greasemonkey scripts are easily updated, even without the help of fancy consultants or IT. Indeed, I find the notion that Greasemonkey is inherently flawed because of its simplistic nature perilously close to the thinking that PHP is of no account because it’s technically inelegant. Be that as it may, it works, its easy to use, and has a very low barrier to entry. So while I’m not contending that GM is the end all and be all of appliation customization, neither would I dismiss it just because its applying green screen era screen-scraping to web pages. It works, and that’s good enough for me.
Hopefully that clears a few things up, and erases some of the ambiguity of my earlier missive on the subject. As always, feedback’s appreciated – am I off base here?
Update: Here’s an example of one service provider (Feedlounge is an Ajaxed up Bloglines type client, from what I understand) encouraging downstream customization of their application. Alex, one of the folks behind FeedLounge who I’ll coincidentally be having lunch with tomorrow, even gets the ball rolling with a few GM scripts here. On the flip side, Christopher remains unconvinced (see the comments here for a more detailed debate). While we obviously disagree, he’s a sharp guy and makes some very good points.
