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.
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.