Persistence Is The Browsers' Most Persistent ProblemPersistence Is The Browsers' Most Persistent Problem

Over on his Tecosytems blog, Redmonk principal analyst Stephen O'Grady <a href="http://redmonk.com/sogrady/2008/10/30/get-thee-offline-firefox/">picks up</a> a conversation that he and I first batted back and forth on Twitter. Twitter, with its 140-character limit to each post, can cramp even the simplest of dialogs. Take a complex topic like offline persistence of anything (a single page, data, applications, etc.) in a browser and I'm glad he took it to the blogosphere. Sometimes only a blog wi

David Berlind, Chief Content Officer, UBM TechWeb

October 31, 2008

4 Min Read
information logo in a gray background | information

Over on his Tecosytems blog, Redmonk principal analyst Stephen O'Grady picks up a conversation that he and I first batted back and forth on Twitter. Twitter, with its 140-character limit to each post, can cramp even the simplest of dialogs. Take a complex topic like offline persistence of anything (a single page, data, applications, etc.) in a browser and I'm glad he took it to the blogosphere. Sometimes only a blog will do.Stephen offered more details on what he wants, but so far can't have. Something real simple (I hope I get it right now): Regardless of the current state of connectivity, the ability to bring back the most recent set of a browser's tabs complete with any user data that might have been entered into those tabs. Not necessarily the whole app. Just that one page.

Having lost entire blog entries because my browser crashed while I was completing a TypePad or WordPress form (thankfully, the newer versions of WordPress auto-save much the same way Gmail auto-saves), I can completely relate. When I bring the browser back to life, I could care less about a functioning offline version of WordPress' authoring tools. I just want all that hard work back.

Over on Stephen's blog post, there are people far smarter than me commenting on the technicalities of persistence (by the way, it is one of the suggested discussion topics for the upcoming Mashup Camp and Oracle has something to say on the matter as well. Hmm.) Anyway, ultimately, don't we all just want a great Web experience? I can completely relate to what Stephen is asking for. It's far simpler than the problems a persistence technology like Google Gears is trying to tackle. But ultimately, thanks in part to Gears and similar technologies from Adobe, Apache, Oracle, and Sun, we know more is possible. So, why accept less? Google knows more is possible and now we have Chrome because where the Internet lacks the fabric, the browser must step in and, unfortunately, the browsers haven't stepped in.

Persistence, I'm told, at any level (page, data, app, etc.) simply isn't something that's well-suited to a plug-in architecture. One reason this may be is the cost bit that's discussed by several others who commented on Stephen's post. Sooner or later, the Web/Internet corollary to Moore's Law will ameliorate that cost. That's at least part of the message in Chrome, no? And as that tipping point draws closer, caching and persistence will become much more synonymous with one another.

The "cache" will be responsible for the performance of Web apps as much as it's responsible for persistence of both data and code and it will be probably be big enough to impressively deliver on the need for both. To achieve such objectives, the layers of abstraction introduced by browser plug-in architectures will have to be left behind. My guess is that persistence of any kind really needs to be as much a part of the browser as the HTML parser and the JavaScript engine now are.

The question is, where do we go from here? Not only is there a complete lack of consensus on next steps, but, politically, the industry has no capacity to agree on such matters. Heck, even for the parts where de jure standards exist (e.g.: those from the W3), the browsers still part ways.

Forget for a minute the idea of fundamentally altering its browser's architecture. The Mozilla Foundation seems to me to be in a difficult position because it can't necessarily embrace one company's open source plug-in (e.g., Google's Gears) without endorsing others, even ones that aren't for persistence. It would set an ugly precedent for the relatively squeaky clean and independent organization that's behind Firefox. As Stephen rightly points out, there are other persistence mechanisms. Mozilla shouldn't have to pick sides, and won't. It's a bit of a Catch-22.

And here are two organizations, Google and Mozilla, which are relatively aligned with one another. Never mind Apple (Safari), Microsoft (IE), & Opera. Not only can't there be consensus on how to handle persistence, reaching some concord on defining it is probably equally impossible. Stephen has his definition. I have mine. Google and others have their own vision. Users are stuck in the lurch and more than likely will be for the foreseeable future (or, until some company that delivers both the applications and the browser ends up with a monopoly).

I'm afraid, Stephen, that your beckon call to be delivered from browser hell will remain unanswered. At least until your beloved Red Sox win another World Series. Both could be a while.

Read more about:

20082008

About the Author

David Berlind

Chief Content Officer, UBM TechWeb

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights