There’s general class of applications that’s been gaining some traction lately in the Mozilla communities built on a free-standing framework called Web Runner.
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 Gecko engine) — had it load Gmail.com 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 Xcode, 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 Mail.app… 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.
Factory Joe 
wow. what’s so great about the willmore’s gmail browser makes it worth $25?
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,…
Are you successfully running Gmail Macros using GreaseKit and Mailplane?
Doesn’t Leopard and Safari 3.0 threaten to break input managers and SIMBL?
it’s cool, but what about the leopard? the inputmanagers is disabled on the upcoming new os x.
I thought I lost it at first, but I found the original source code for Hiker and that template we started on.
http://hiker.wh.joshpeek.com/browser
@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?
@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.
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.
http://labs.mozilla.com/2007/10/prism/
Did you know this was coming down the pipe?
>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.
@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… 😉
So, now that Leopard is out, what does the future hold for GreaseKit et al?
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”.
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.