Site-specific browsers and GreaseKit

GreaseKit - Manage Applications

There’s general class of applications that’s been gaining some traction lately in the Mozilla communities built on a free-standing framework called .

The idea is simple: take a browser, cut out the tabs, the URL bar and all the rest of the window chrome and instead load one website at a time. Hence the colloquial name: “site specific browser”.

Michael McCracken deserves credit for inspiring interest in this idea early on with his Webmail app, that in turn lead to Ben Willmore’s Gmail Browser application. Both literally took WebKit — Apple’s open source rendering engine (like Mozilla’s engine) — had it load and released their apps. It doesn’t get much more straight-forward than that.

For my own part, I’ve been chronically the development of Site-Specific Browsers from the beginning, setting up the WebKit PBWiki and releasing a couple of my own apps, most recently Diet Pibb. I have a strong belief that a full featured rendering engine coupled with a few client side tweaks is the future of browsers and web apps. You can see hints of this in Dashboard Widgets and Adobe’s AIR framework already, though the former’s launching flow conflicts with the traditional “click an icon in my dock to launch an application” design pattern.

Anyway, in developing my Site-Specific Browsers (or Desktop Web Apps?), I became enamored with an input manager for Safari called Creammonkey that allows you to run Greasemonkey scripts inside of Safari (ignore the name — Kato, the developer, is Japanese and English is his second language). An input manager works by matching a particular application’s .plist identifier and injecting its code (via SIMBL) into the application at run-time, effectively becoming part of the host application, in turn giving it access to all the application’s inner workings. When it comes to a rendering engine, it’s this kind of injection that allows you to then inject your own CSS or Javascript into a webpage, allowing you to make whatever modifications you want.

This is what Creammonkey did for Safari. And thank god it was open source or else we never would have ended up with today’s release of the successor to Creammonkey called GreaseKit.

Let me step back a little.

When I found out about Creammonkey, I contacted Kato Kazuyoshi, the developer, and told him how excited I was about what he had created.

“But could I use this on Site-Specific Browsers?” I wanted to know.

In broken English he expressed his uncertainty and so I went about hacking it myself.

I ended up with a crude solution where I would recompile Creammonkey and aim it at a different application every time I wanted to make use of a different Greasemonkey scripts. It was tedious and didn’t really work the way I envisioned, but given my meager programming skills, it demonstrated the idea of Site-Specific Browsers with Site-Specific Hacks.

I called this collection of site-specific scripts with a properly crafted Input Manager a “GreaseKit” and let the idea sit for a while.

Some time later, Kato got in touch with me and we talked about rereleasing Creammonkey with the functionality that I envisioned and a new name. Today he released the results of that work and called it GreaseKit.

I can’t really express how excited I am about this. I suspect that the significance of this development probably won’t shake the foundations of the web, but it’s pretty huge.

For one thing, I’ve found comparable solutions (Web Runner) clunky and hard to use. In contrast, I’m able to create stand-alone WebKit apps in under 2 minutes with native Apple menus and all the fixins using a template that Josh Peek made. No, these apps aren’t cross-platform (yet), but what I lose in spanning the Linux/PC divide, I gain in the use of , Apple’s development environment, and frankly a faster rendering engine. And, as of today, the use of Greasemonkey scripts centrally managed for every WebKit app I develop.

These apps are so easy to make and so frigging useful that people are actually building businesses on them. Consider Mailplane, Ruben Bakker’s Gmail app. It’s only increments better than McCracken’s WebMail or Willmore’s Gmail Browser, but he’s still able to charge $25 for it (which I paid happily). Now, with GreaseKit in the wild, I can add all my favorite Greasemonkey scripts to Mailplane — just like I might have with Firefox — but if Gmail causes a browser crash, I only lose Mailplane, rather than my whole browser and all the tabs I have open. Not to mention that I can command-tab to Mailplane like I can with… and I can drag and drop a file on to Mailplane’s dock icon to compose a new email with an attachment. Just add offline storage (inevitable now that WebKit supports HTML5 client-side database storage) and you’ve basically got the best of desktop, web and user-scriptable applications all in one lightweight package. I’ll have more to write on this soon, but for now, give GreaseKit a whirl (or check the source) and let me know what you think.


  1. at 1am on Oct 23rd # |

    wow. what’s so great about the willmore’s gmail browser makes it worth $25?

  2. Wim said
    at 3am on Oct 23rd # |

    Is there some directory site pointing people to all these webkit apps? That would be nice. Liking mailplane, but like to also have google calendar, reader, docs,…

  3. Derek said
    at 4am on Oct 23rd # |

    Are you successfully running Gmail Macros using GreaseKit and Mailplane?

  4. Johnny Trapdoor said
    at 6am on Oct 23rd # |

    Doesn’t Leopard and Safari 3.0 threaten to break input managers and SIMBL?

  5. wyctim said
    at 6am on Oct 23rd # |

    it’s cool, but what about the leopard? the inputmanagers is disabled on the upcoming new os x.

  6. at 7am on Oct 23rd # |

    I thought I lost it at first, but I found the original source code for Hiker and that template we started on.

  7. at 7am on Oct 23rd # |

    @James: It’s not Willmore’s Gmail Browser that’s $25; it’s Ruben Bakker’s Mailplane. $25 is kind of steep for this kind of thing, but I primarily wanted to support an independent developer and the idea making web-based, native-like applications. Granted, some folks bristled at the pricetag, I felt like I was supporting an individual pioneering in this work.

    What makes it valuable to me is all the work that went into to make it behave more like a desktop app (for example, dragging files onto a message window to attach). Is it worth $25 for these kinds of features? Frankly, not to everyone. But I do hope that Ruben continues to build it out — and as Gmail changes over time, I expect that my money will help pay for fast updates to the app to keep it compatible with the ongoing changes.

    @Wlm: There isn’t yet, besides the WebKit wiki that I started showing Existing Projects. We’re still early, but eventually these apps will saddle up alongside more traditional desktop apps.

    @Derek: Truthfully I haven’t given it a shot yet — I was just so excited that GreaseKit was out that I wanted to get the word out and see what other folks come up with. That said, I’ll probably start giving some of the available Gmail Greasemonkey scripts a whirl soon.

    @Johnny and @wyctim: fortunately there is already work underway to make SIMBL-style Input Manager work on Leopard. Specifically take a look at PlugSuit and PimpKit.

    @Josh: awesome! I think I made some improvements… perhaps we should create a Google Code project and get some more folks involved?

  8. Derek said
    at 8am on Oct 23rd # |

    @Chris do report back if you have any luck. I believe I ran all of the updated Gmail related userscripts but none of them seemed to work. I did make sure that all the selected scripts were enabled for Mailplane.

  9. at 1am on Oct 24th # |

    That’s nice, but with Gmail now supporting IMAP, I think there’s much less of an incentive to have the web-interface for Gmail open all the time.

  10. at 9pm on Oct 25th # |

    Did you know this was coming down the pipe?

  11. at 5pm on Oct 26th # |

    >I’ve found comparable solutions (Web Runner) clunky and hard to use.

    WebRunner got relaunched as Prism yesterday, and in addition to focusing on third party generated webapp bundles, it also allows end users to quickly integrate any Web application into their desktop experience.

    The planned UI still isn’t fully in place yet, but we are certainly working on cleaning up the experience for mainstream users.

  12. at 10am on Oct 29th # |

    @Alex: cool. I saw Prism. That’s a pretty excellent advance to see come out of Mozilla. Would love to talk more about this — as I’ve been thinking about these things for some time… ;)

  13. at 2am on Oct 30th # |

    So, now that Leopard is out, what does the future hold for GreaseKit et al?

  14. at 10am on Oct 30th # |

    Well, we’ll see. If you ask me, with Prism and GreaseKit, I think we’re just starting to scratch the surface of the future of “web browsers”.

  15. at 1pm on Nov 3rd # |

    Just a heads up, but apparently there is some bad mojo going on with Leopard’s Xcode and the webkit template. I tried a check out and an export and both give me the incredibly helpful and edifying error:

    “Project /webkit_template/WebKitApp.xcodeproj cannot be opened because the project file cannot be parsed.”

    I am really looking forward to playing with this, you know, when I can play with it.

7 Trackbacks

  1. [...] Site-specific browsers and GreaseKit | FactoryCity [...]

  2. [...] Site-specific browsers and GreaseKit (tags: open source technology the web arts building browsers greasekit greasemonkey site-specific webkit) [...]

  3. All in a days work… on Oct 25th at 5pm

    [...] Site-specific browsers and GreaseKit – the best of desktop, web and user-scriptable apps all in one … Site-specific browsers: take a browser, cut out the tabs, the URL bar and all the rest of the window chrome and instead load one website at a time. GreaseKit: run Greasemonkey scripts inside of Safari. (tags: Site_Specific_Browsers Desktop_Apps User_Styles/Scripts Safari) [...]

  4. [...] Site-specific browsers and GreaseKit | FactoryCity [...]

  5. [...] Site-specific browsers and GreaseKit | FactoryCity [...]

  6. [...] and the idea behind ‘em ’cause this topic has already been discussed by too many awesome [...]

  7. [...] is all part of a larger trend, referred to as site-specific browsers, which blurs the lines between the web and the way you access it. Apple seems to be ahead of this [...]