This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: Pure Client Side Web Pages
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
This means that you can unplug your networking cable (or wifi card) and still use the wiki. When you save the page (File->Save Page As, Apple-S, Ctrl-S, etc.), the actualy HTML page gets saved to your local hard drive with all the changes you've made in the wiki. It's a God damn brillent idea. The more general idea of self-contained JavaScript-HTML/DHTML pages is even more intreaging.
What This Gets You
The interesting things you get from a pure client side "web page" like this is the elimination of the connection time to the remote server and, of course, the need for a connection. So, if you had some application (and I use that term loosly) you wanted to write as a web page, but you were stymied by the slowness of connecting to the remote server or needing a network connection at all, you can revisit doing that app as a TiddlyWiki style application.
Desktop Applications as Web Pages
You can think of all sorts of other "desktop" applications that could be ported to this style of web page: spreadsheets, Quicken, all those sorts of things. If course, there may not be enough memory and processing power available to the browser to power DHTML like that (who knows how demanding JavaScript-HTML/DHTML coding is...those Ajax people probably have a good idea by now). We'd just have to try it out and see what happens.
Remote Saving
Being a network-centric guy, the first thing I think up is the need for a way to save your page to a remote server. That way, you can work on your TiddyWiki-like app from any computer: (1.) you download it from the server, (2.) make all your edits locally, (3.) then when you "Save" it, it gets uploaded to the server for you. Then, (1.) you can go to another computer, (2.) download the TiddyWiki-like app, make edits, and (3.) "Save" it to the remote machine. Etc., etc..
Indeed, if you had a system where users "checked out" chunks of data to modify and then "checked them in," you could fit this model that that system as well. You wouldn't want to complicate the simplistic nature of the pure client side web page by putting in all sorts of server chatter in the middle of steps 1 and 2 above; we can leave that to the Ajax crowd. Instead, you can treat the remote server like a file-share: it's a remote "thing," but the only interaction your application has with it is to transfer files (the JavaScript-HTML page) back and forth to it.
Previous Topic
