Fun with static publishing
In the old days, static publishing (or baking, where the CMS generates static HTML files at publish time), was pretty much the standard. Most of the WCM products on the market did static publishing: Interwoven, Tridion, RedDot, Percussion .... Even the frying systems like Vignette and FatWire (FutureTense/OpenMarket back then) relied so heavily on caching that they were practically baking style systems. Computing power was so expensive back then that you didn't dare to do much processing at request time.
Then frying-style systems became the norm. WCM vendors needed to have an answer to market demand for personalization and other dynamic behavior and the only way to do that was through dynamic (request-time) publishing. But static publishing isn't dead. There are many baking style systems on the market and lots of customers swear by static publishing. Good strategies have emerged to overcome its limitations. The primary benefits of static publishing are still very real: cost-savings, security, and stability. You can cheaply stand-up web servers that have the easy job of just serving up static HTML files.
And this brings me to my little obsession with static publishing. I am hosting a few sites on Amazon S3. The cost is ridiculously low and the speed is crazy-fast. Publishing them is fun too. For example, I publish my little personal site (www.sethgottlieb.com) using a site generator called Hyde, which is a Python port of a Ruby-based system called Jekyll. The way these generators work is that you enter your content in HTML, Markdown, or some other syntax and then run a script that renders static HTML pages with your presentation templates. Presentation templates can also do useful things like create listing pages. The Hyde sample site has a blog and there is a script to migrate from Wordpress. Versioning? Git, of course. In fact, using a source code control system will also allow multiple authors to collaborate too. Site generators also do useful things like minifying your CSS and JS files for maximum performance. Want interactive features like search or commenting? For search you could use Google Custom Search. Commenting can be supported through a service like Disqus. You can configure secure areas with your web servers. For little bits of interactivity, you could embed some client side Javascript or server side PHP in your static HTML files.
I also used static publishing to create an archive of a site that I no longer update. I created a Drupal website for my wife's birthday a few years ago. I didn't want to pay for LAMP hosting indefinitely but I didn't want to lose the site either. My solution was to pull the whole site down using wget and then upload it to S3. The site has lots of pages and I wouldn't want to manage them as static HTML but since I have no plans to change the site, I don't have to worry about it.
I am not saying that static publishing is a good idea all or even most of the time. Dynamic publishing opens up a whole new word of interactivity and personalization. Just don't write off static publishing too quickly — especially if your site doesn't change much and doesn't need to be very interactive.