Fog Creek Software
Discussion Board

Richer Client-Side Persistence

On the topic of "what do we need to make web applications more useful", all the obvious things are either "more stuff you can do on the client" and "better ways of communicating with the server".

In the first category, one thing that jumps out would be some kind of semi-decent object store on the client side for use when you don't have a connection to the internet.

Web mail would be a lot more useful if working offline were more of a realistic option (maybe GMail has this, but I'm not one of the chosen ones :( ). Or you could collect data for your geology lab without having to copy and paste or have someone hack together a client-specific app.

Currently client side storage is limited to saving HTML and using cookies (and I doesn't look like -- at least in Safari -- you can set cookies on saved HTML files through JavaScript). If there were some kind of (transparently?) persistent object in JavaScript (say, anything under "document.persistent"), you could do some interesting things. It'd also be nice if there were a one-function call to serialize document.persistent into an XML stream to POST back to the server.

It seems like a pretty easy thing to add to a browser...the tricky part (as with cookies) might be security and privacy. It could also make things like multi-page web forms much less of a PITA to code. The graceful failure bit would mean that you'd have to be working online to use it in IE, but maybe not in Mozilla or Konqueror or whatever.

Frank Schmitt
Thursday, June 17, 2004

I'm sure somebody will mention XML soon...
Thursday, June 17, 2004

Hey, you could store it client-side in xml...

Thursday, June 17, 2004

Yeah, but how do I do that in an OS-agnostic way from a piece of JavaScript in an HTML file I've added to my start menu called "New Webmail"?

Frank Schmitt
Thursday, June 17, 2004

Ahhh, but you can't!  You're running in a security sandbox, no soup (err, filesystem access) for you!

Actually I'm not sure how useful this would really be anyway...who wants to write their *entire* application in DHTML and JavaScript, with the web server really just acting as middleware for the DB?  Blech...  I don't see standard .asp/.jsp/.aspx/.php/.etc web apps becoming usable offline anytime in the near or distant future.

If you really really really wanted to do this, you might be able to get away with something in a Java applet or possibly a Flash movie, if you run it under a "Trusted Sites" URL.

Thursday, June 17, 2004

More specifically, I'd like to be able to click a "Save Draft" button, close my browser, shut down the machine, and send the email the next time I have internet access, again without needing a client-specific app.

JavaScript, last time I looked, (thankfully) doesn't have facilities for manipulating files on the client. Manipulating persistent data in a "playpen" would be useful, however.

Frank Schmitt
Thursday, June 17, 2004

Ummm...sites like Yahoo mail (and others I'm sure) already do that.  Yes, you have to be online to interact with your email, but there is nothing stopping you from saving a draft and completing it whenever you want.

Thursday, June 17, 2004

Client-Side persistence is a bad idea.  I think that misses the whole point of web interfaces.

christopher baus (
Thursday, June 17, 2004

I agree that the primary point of web applications is their ubiquitous availability -- in other words I don't need to be using my computer to access my email.

But it's still a matter of degree more than an either/or thing. Client-based apps are really annoying when you don't have access to your client. Likewise server-based apps are really annoying when you don't have access to your server.

At the risk of shifting the debate a bit, there's the school of thought that "everything that can be done on the server *should* be done on the server," and that is mostly true. But there's a case to be made for client-side code for things like a first-level of sanity checking of input, and for things that have to happen with low latency.

Client-side *data* (that's accessible within the DOM) currently consists solely of cookies, which really aren't rich enough to store much more than a session ID, or maybe for caching things like your timezone so the server doesn't have to hit the database to print out the date. (I'm sure some nutjob -- and I mean that in the nicest way possible -- has written a database wrapper in client-side JavaScript that stores everything in cookies). Sure there are various hacks (cf. to not have to use cookies for tracking session IDs, but they're still hacks. So there's also a case to be made for web-based client-side data (for sufficiently small values of "data")...and now we're just talking a matter of degree.

Client-side JavaScript is a really rich language, and it's a shame that it's been reduced to doing things like drawing crappy DHTML menus and (when someone is really bored) implementing MineSweeper. The primary limitation of doing anything more useful in JavaScript seems to be that there's no way to store data between sessions without connecting to a server somewhere.

Another approach would be a very lightweight local webserver, but I'll let someone else argue that point.

Frank Schmitt
Thursday, June 17, 2004

Internet Explorer has client-side persisence in the browser object model. (which is where it belongs, javascript is a language, you can also use vbscript or even perl if the user has activeperl installed).

Anyway, it's basically cookies on steroids. You have 64k of XML support.
Look for userdata.

IE has a number of the features Joel asked for. That whole locked-in-the-basement thing must have happened a little later than he expected.

Maybe Firefox also implements these features?

Thursday, June 17, 2004

Minesweeper for Mozilla/Firefox:

fool for python
Thursday, June 17, 2004

Lets see, you want to have a stateful process in a stateless environment.

How long have people wanted that?

Since people wanted to do more than hyperlink _documents_ and wanted to hyperlink behaviour.  Hence cookies.

Cookies being a kind of frozen statefulness are both cumbersome and a hole in the security layer.

So then instead you get server side statefulness, which is really some kind of session key in a database.  But then you have the issues of validating identity in a shifting address world.

So then people want client side again.

Let's just make it clear.  You cannot maintain states in a stateless environment unless those states are outside that environment.  Repeat this interminably until you realise that you need a stateful client if it truly is important or that the only viable alternative is maintaining server site state.

The problem is HTTP, not HTML.

Simon Lucy
Friday, June 18, 2004

*  Recent Topics

*  Fog Creek Home