webkit – Factory Joe

Google Chrome and the future of browsers

News came today confirming Google’s plans for Chrome, its own open source browser based on Webkit.

This is big news. As far as I’m concerned, it doesn’t get much bigger than this, at least in my little shed on the internet.

I’ve been struggling to come to grips with my thoughts on this since I first heard about this this morning over Twitter (thanks @rww @Carnage4Life and @furrier). Once I found out that it was based on Webkit, the pieces all fell into place (or perhaps the puzzle that’s been under construction for the past year or so became clearer).

Last May I ranted for a good 45 minutes or so about the state of Mozilla and Firefox and my concerns for its future. It’s curious to look back and consider my fears about Adobe Air and Silverlight; it’s more curious to think about what Google Chrome might mean now that it’s been confirmed and that those frameworks have little to offer in the way of standards for the open web.

I read announcement as the kid gloves coming off. I just can’t read this any other way than to think that Google’s finally fed up waiting around for Firefox to get their act together, fix their performance issues in serious ways, provide tangible and near-term vision and make good on their ultimate promise and value-proposition.

Sure, Google re-upped their deal with Firefox, but why wouldn’t they? If this really is a battle against Microsoft, Google can continue to use Firefox as its proxy against the entrenched behemoth. Why not? Mozilla’s lack of concern worries me greatly; if they knew about it, what did they do about it? Although Weave has potential, Google has had Google Browser Sync for ages (announced, to wit, by Chrome’s product manager Brian Rakowski). Aza Raskin might be doing very curious and esoteric experiments on Labs, but how does this demonstrate a wider, clearer, focused vision? Or is that the point?

Therein lies the tragedy: Google is a well-oiled, well-heeled machine. Mozilla, in contrast, is not (and probably never will be). The Webkit team, as a rhizomatic offshoot from Apple, has a similar development pedigree and has consistently produced a high quality — now cross-platform — open source project, nary engaging in polemics or politics. They let the results speak for themselves. They keep their eyes on the ball.

Ultimately this has everything to do with people; with leadership, execution and vision.

When Mozilla lost Ben Goodger I think the damage went deeper than was known or understood. Then Blake Ross and Joe Hewitt went over to Facebook, where they’re probably in the bowels of the organization, doing stuff with FBML and the like, bringing Parakeet into existence (they’ve recently been joined by Mike Schroepfer, previously VP of Engineering at Mozilla). Brad Neuberg joined Google to take Dojo Offline forward in the Gears project (along with efforts from Dylan Schiemann and Alex Russell). And the list goes on.

Start poking around the names in the Google Chrome comic book and the names are there. Scott McCloud’s drawings aren’t just a useful pictorial explanation of what to expect in Chrome; it’s practically a declaration of independence from the yesteryear traditions of browser design of the past 10 years, going all the way back to Netscape’s heyday when the notion of the web was a vast collection of interlinked documents. With Chrome, the web starts to look more like a nodal grid of documents, with cloud applications running on momentary instances, being run directly and indirectly by people and their agents. This is the browser caught up.

We get Gears baked in (note the lack of “Google” prefix — it’s now simply “of the web”) and if you’ve read the fine-print closely, you already know that this means that Chrome will be a self-updating, self-healing browser. This means that the web will rev at the speed of the frameworks and the specifications, and will no longer be tied to the monopoly player’s broken rendering engine.

And on top of Gears, we’re starting to see the light of the site-specific browser revolution and the maturing of the web as an application platform, something Todd Ditchendorf, with his Fluid project, knows something about (also based on Webkit — all your base, etc):

In spite of its lofty rhetoric in support of a free Internet, Chrome isn’t Mozilla’s pièce de résistance. Turns out that it’s going to be Apple and Google who will usher in the future of browsers, and who will get to determine just what that future of browsers are going to look like:

To put it mildly, things just got a whole lot more exciting.

Site-specific browsers and GreaseKit

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.

So Mozilla wants to go mobile, eh?

As with baseball, on the web we have our home teams and our underdogs and our all-stars; we have our upsets, our defeats, and our glorious wins in the bottom of the ninth. And though I’m actually not much of a baseball fan anymore (though growing up in New England, I was exposed to plenty of Red Sox fever), I do relate my feelings for Mozilla to the way a lot of folks felt about the Red Sox before they finally won the World Series and broke the Curse of the Bambino: that is, I identify with Mozilla as my team, but dammit if they don’t frustrate me on occasion.

Tara wonders why I spend so much time on Mozilla when clearly I’m a perennial critic of the direction they’re headed in and the decisions that they make. But then Tara also didn’t grow up around vocal critics of the Red Sox who expressed their dedication and patronage to the team through their constant criticism and anger. It might not make sense, and it might not seem worth my time, but whatever the case, you really can’t be neutral about Mozilla and still consider yourself a fan. Even if you disagree with everything decision that they make, they’re still the home team of the Open Web and heck, even as you bitch and whine about this or about that, you really just want to see them do well, oftentimes in spite of themselves.

So, with that said, let me give you a superficial summary of what I think about Mozilla’s recent announcement about their mobile strategy:

Too little, too late.
Are they a product or a platform company?
XUL is their widget platform? SRSLY?
Is Google putting them up to this? Or is it Intel?
Follow the money.
Go Red Sox!

If you want to stop reading now, you can, but the details and background of my reasoning might be somewhat interesting to you. I make no promises though.

Continue reading “So Mozilla wants to go mobile, eh?”

Browsers, the future thereof

When I first realized the web as a medium — like artists found clay — I was someone who built websites. I grew up an artist, dabbling with pastels, sculpture, painting; I took lessons in all the classics. Back when I started out on the web, well, I threw my paint against the wall, watched it dry differently; tried watercolor and salt; mixed in color pencil. I created on someone else’s canvas, beholden to the whims of the Internet Explorers and Netscapes.

It wasn’t until I grew frustrated trying to create a publishing and composition tool for regular folks in CivicSpace that I realized that it wasn’t that the brushes or paint that I was using that were flawed — but that the canvas itself could be streched so much further. And so when the opportunity arose to go work on and set the direction of Flock, I jumped at the chance. The thought that I could take a number of the ideas on content creation that I’d been trying to implement in regular webpages into the browser itself was too irresistible to pass up.

And that’s how it started for me — working first on the side of web content developers — and then on the side of the actual rendering context and application. I doubt that I was qualified to work on either, but that’s besides the point, since that’s where I found myself (and artists worth their weight are hardly what I would call experts).

So now, a few months out after leaving Flock, a few heady announcements about microformats, a new Firefox Beta to toy with, a number of webkit-based apps to ponder over and an emerging identity standard coming to the fore, I’m starting to see the future materialize in front of me. From where I sit though, there is a lack of clarity as to what it’s all about, what’s really going on and what’s missing in between to glue it all together and — perhaps most importantly — a sense for what we can learn by focusing on the negative space of our current situation.

I’ve been reading about Doug Engelbart lately and the stuff he was doing in the 60s with his Augment system. He’s now collaborating with my buddy Brad Neuberg on a system he calls “Hyperscope”. I can’t help but see disjoint parallels between his ideas and what’s emerging today. Simply put, there is no grand theory or unifying concept that will bring it all together, just as there’s no single design for a tree — in fact, it takes many to make a forest, and we’re only now beginning to see the emergence of the forest in spite of the individual trees that seem oh-so-important.

And we don’t even have the benefit of LSD. Man, how are we to escape what we already know to imagine what’s possible? Oh well.

Anyway, lemme get down to brass tacks, coz I can tell you’re getting bored already. I almost am, striking out at some kind of point out of this rambling.

When I was at Web 2.0™ (I think) I mentioned to Jason Fried — as I’ve done to others since — my desire to have a webwide conversation about what the future of web browsers should look like. This was the work that I thought I’d started at Flock, but the reality is that they’re a business and not an academic institution and need to pay their employees (a harsh reality that I’m now realizing owning my own company and having a payroll). I left because of this — and maybe for other personal reasons — but primarily because my vision for the future wasn’t exactly compatible with where they needed to go in the short term. Hey, bills, remember?

Anyway, let me put it out there: I don’t get where Firefox is going. I don’t think it’s going anywhere actually. I think it’s strong, it’s stable, it’s a great platform. But it’s not innovative. It’s not Quicksilver. It was a response to IE and now IE7 will come out, co-opt everything that makes Firefox great or interesting and we’ll run through another coupla years of stagnation. Blah.

There is a solution though — you’d be surprised maybe, but you can find it in Safari and I’m dead serious about this. The number of webkit-based apps being released is growing by the week. Pyro, Gcal, Webmail, Hiker (thanks Josh!). There was talk about the future of the merged Internet-desktop as, quite clearly, this is where we’re going — but the choice of user agent is sadly coming down to facility over featureset or robustness. Why isn’t this happening with XUL Runner or Firefox (you figure it out)?

At Flock, this is where I saw things going. I didn’t see Flock as a monolithic package of integrated apps like Netscape or Office — bundled up with unmaintainable software sprawl… but with a solid underlying platform that these secondary apps could be built upon (yeah, Lucene, yeah, Microformats, yeah IM, yeah video and audio and all the rest). Speaking RSS, microformats, Atom and other syndicated content natively, you’d be able to universally star anything for later sharing… you’d be able to upload anything… be able to have any AJAX’d experience offline with a super-cache that could handle the sporadic network connectivity that most of the world puts up with (or that we put up with when we travel). And hell, with OpenID, we’ve even got a way to sync it all up together. Toss in a platform that is built on and around people people people and you’ve got something to really take us forward into the next evolution of Things As We Know Them™.

I wanted Firefox to be my Chariot, Flock to be my Sun.

Such as it is with Open Source, trying to inspire end-user interface innovation is often a losing battle.

(As an aside in parentheses, I think this is biological; I met Tara’s 2-year-old niece this weekend and she mimicked everything we did; thus it’s developmental and inherent — yet the problem remains: how do we bring the majority of user interface innovation to the open source space?)

So anyway — Safari; webkit apps… the future.

For the benefit of everyone involved, whether Mozilla, Flock, Microsoft, Opera, and so on implements any of this stuff… there needs to be some major advancements made in browser technology, both for normal humans and for web… um… painters. This stuff, seriously, is still way too opaque, and way too obscure for most humans for whom “delicious” still means “tastes good”. I want to have that web-wide conversation about the future of the web but somehow, my instincts tell me that the venue to have that conversation isn’t going to be on the web… it’s going to be in barber shops and gas stations and restaurants and the places where normal people really hang out.

If we’re ever going to bear witness to the promise of Doug Engelbart’s achievable vision, it has to be this way. And, to paraphrase walkway wisdom: nothing worth doing is easy. And so I challenge you — those who give a shit — look at what’s out there — and more importantly — what’s not out there — and begin to think seriously on what comes next… on what’s missing… on where this medium needs to be stretched in order to make the most of what’s possible.