Dynamic or Static websitesSaturday, June 14, 2003
Time and time again I get a niggling feeling that delivering "static content" in a dynamic fashion is largely a waste of resources. When a page contains the same content regardless of the visitor, then there's no real point in generating it dynamically each time. The only time a new version needs to be created is when the content is being updated - and then it only needs to be done once.
Baking and Frying of Websites
This feeling has been given a semblance of confidence from an Aaron Schwartz article titled "Bake, Don't Fry", and "Building Baked Sites". Moveable Type, although being a set of perl scripts, generates a series of static pages that is then published to the website. This Aaron calls the baking approach, as opposed to the fried-on-the-spot approach that dynamic content generation entails.
The advantages of the baked (or pregenerated) approach are obvious. By requiring no servers-side scripting and/or databases, the website is more reliable, being innoculated against any outages apart from the webserver itself.
The down-side is then the lack of dynamism, so functions like real-time comments, trackbacks are not possible within a static framework.
Giving this some longer thought and parts of the required framework fall into place rather neatly. What I'm particularly interested in is a static-content website, with the ability to "plug-in" dynamic components. And with the side-effect that if one of the resources to generate the dynamic content isn't available, then just the static content components are displayed.
The webserver is obviously a key resource for either a static or dynamic website. And considering that I'm an Apache-fan for life, and that Apache's modules are part of the webserver, it is fair then to consider PHP as part of the "static webserver" set-up, since if PHP is not working, then there's a very good chance that Apache isn't working too.
On the dynamic components, then resources like mySQL and out-going HTTP fall into this category.
So the aim is then to make a site that is reliable, using just a webserver and PHP. And then use mySQL and out-going HTTP to enhance the content - with comments, trackbacks, external RSS feeds. The idea fits like the HTML authoring of Augmentative Authoring, as discussed by Jukka Korpela, except for the server instead.
Makefile-based site generation
The biggest problem of static sites is the updates required on multiple pages when the author needs to add in a page or new section to a website. This only needs to be done once per update - not everytime a visitor drops on by. Strangely enough, there is a tool out there that deals neatly with relationships and dependancies of files, and used by millions of programmers around the world - Make. I guess its no surprise that Alan Flavell mentions Make as part of a tool set for HTML preprocessing on Usenet this morning, and naturally points out its biggest pitfall - the lack of decent easy-to-understand documentation on the subject.
Using make as a foundation for an application (or even Apache's xml-based Ant), there seems to be no technical reason why a website management application can't be built over this in such a way as to present an editable and template based approach to website construction. It feels like a drag-and-drop type application is feasible. At least in that respect it may be more flexible than the excellent Macromedia Contribute.
Yes, Moveable Type (and likely the upcoming TypePad) offers this sort of functionality already, but I want something more than just a blog type tool. I'm thinking more of a tool that can generate sites comparable to Post-NUKE, but making it more reliable by the independance of static and dynamic content. Switch off mySQL and the whole site is about as useful as a non-customised 404. I'd like either a desktop tool or a browser-based tool that allows me to build and structure a website, add in new categories, temporary disable other sections - and it generates as much of it statically as possible.
Database independant site generation
There are a few ideas I need to look into, and one of them is database independant page caching. I've got to the point where all my websites seem to be completely generated with php and mySQL, and now I feel the time is ripe to wean myself off the dependance on mySQL as the source of static information.
There are precedents to this anti-dynamism. The main one is Wiki. The stock standard Wiki implementation requires only a cgi-bin and a file system. No database. The Usemod wiki does have a page caching feature which reduces the dependance on the wiki data files, but so far it doesn't generate static pages to use instead of intensive file or database operations.
Lessons from blog-software creation
Writing my own blog software for my own use has highlighted this database dependancy as one of the problems of generating a modern albeit static site. At the moment all my blog entries reside in a database table, and every page, be it an html page or an RSS1.0 feed is generated by the use of multiple SQL queries.
Although, I think I've learnt in this exercise how to useful mod_rewrite is in allowing good looking "static-looking" URLs but having a collection of PHP scripts to do the bidding, and I think this is a good foundation to build a make-based website manager/construction kit on.
Outliner based approach
Even though I haven't quite understood the strengths and weaknesses of Outliners as a way of authoring articles, it appears to be a natural way of organising a website. I guess a play with Frontier is probably in order.
Not for business use
Bigger businesses have other ways of making their webservers more reliable, by adding redundancy and load-balancing. Sometimes it is taken to the extreme, but then businesses do have more money than sense. For me, its my pocket paying for my reliability, and I believe shared-hosting is reliable enough for my uses, and practical ideas such as the separation and independance of a website over its database is a cheap solution to reliability concerns.