Infrastructure // PC & Servers
Commentary
10/31/2008
11:45 PM
David Berlind
David Berlind
Commentary
Connect Directly
Facebook
Google+
LinkedIn
Twitter
RSS
E-Mail
50%
50%

Persistence Is The Browsers' Most Persistent Problem

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 wi

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.

Comment  | 
Print  | 
More Insights
Server Market Splitsville
Server Market Splitsville
Just because the server market's in the doldrums doesn't mean innovation has ceased. Far from it -- server technology is enjoying the biggest renaissance since the dawn of x86 systems. But the primary driver is now service providers, not enterprises.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest September 18, 2014
Enterprise social network success starts and ends with integration. Here's how to finally make collaboration click.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.