Strange as it may seem, there is actually no such thing as a web site. By this I mean that URLs - the things we instruct our browsers to fetch - are pretty much opaque strings as far as the infrastructure of the Web is concerned.
Oftentimes, these strings appear to have more structure to them. For example, we think in terms of 'moving up a level' or 'down a level' on a web site by removing a slash separated chunk from, or adding a slash separated chunk to, a URL. The fact that the Web itself knows nothing about this sort of URL manipulation is well known to those who, for example, develop Web spiders. These developers have to worry about finding special files on web sites to do their job which is made more complex by the fact that the very concept of 'on' in web site terms, is very slippery.
Speaking of illusions, web pages themselves - the very stuff of the web - are increasingly merely fictions of our convenience-derived mental model of the Web. We think of URLs as addresses for pages (or 'resources' to be more accurate). Resources that live somewhere on the Web waiting for a browser to request them.
The reality is that it is a very, very simple web site indeed these days that merely serves up so called 'static' pages. One very small step up from static pages are pages with embedded server-side instructions that are processed when a web browser requests the page. A lot of the web today is made up of this sort of page. A step further up the chain from static to dynamic, are pages that literally do not exist at all unless a browser asks for them.
The road from static to dynamic is a subtle and multi-faceted one. This would all be merely academic navel gazing except that failure to recognize the continuum from static to dynamic content can cost you a lot of money. For example, take the fictional dichotomy between portal-centric web infrastructure and application-centric web infrastructure. A simple static web site (portal) can be thought of as a web application in which very little happens dynamically. However, and this is the critical point, by building a static system on a dynamic bedrock, your investment is protected as you can evolve your static content into more dynamic content. However, if you start out with a static system, your evolutionary roadmap is a lot more problematic. Simply put, you do not lose anything (apart from a chimera of simplicity) but gain a lot by taking a dynamic view.
In some respects, this is an old hackneyed dichotomy at this stage. Dynamic web infrastructure has triumphed. More and more portals are based on highly dynamic subsystems that approach or even surpass what was originally conceptualized as an application server. However, no sooner has this false technology dichotomy petered out than another one takes its place.
I'm thinking of business data in databases versus business data flowing from one system to another. The former can be thought of as a static view of data and immortalized by the word 'database'. The latter is a more dynamic view of data and goes by many names, message oriented middleware, enterprise service bus, service-oriented architecture, etc.
Given the tack I took with static versus dynamic web infrastructures you can probably predict where I'm going with this. What if we build static data systems (e.g. a traditional databases) on a bedrock of dynamic data (e.g. a messaging system)?
Does it follow that we have not lost anything, but gained a lot of evolutionary flexibility? Is it true that we do not lose anything (apart from a chimera of simplicity) but gain a lot by taking a dynamic view? I believe it is.
Let me leave you with this thought: messaging systems are typically implemented on top of databases. For example, the data, at any point in time, is a good old fashioned, static database. Interesting, don't you think? The road from static to dynamic is indeed a subtle and multi-faceted one.