The first and simplest is that having a batch process update pages is less maintainable. Someone can accidentally remove or break the process, not knowing what it does, and 6 weeks later you find out that there is a problem with the page, but have no clue how it was supposed to work, and there is no obvious trail back to how it was supposed to be generated. As the mantra goes, premature optimization is usually wrong.

A closely related second issue is the ease of testing and storage. It is inherently a faster and more accurate development cycle to edit a script and see feedback than it is to edit a batch process, have to run it, and then get feedback. Much experience indicates that developing with rapid feedback leads to faster and better development than developing without it. (All else being equal of course.)

Third we have the issue of amount of storage. Often to replace a single dynamic page you have to create multiple static pages. This can quickly result in a combinatorial explosion of pages, eventually leading to problems with storage that make it much saner just to have a dynamic page in the first place.

And closely related to the ease of storage is the ease of adding further customizations. If you have a dynamic page and want to add another customization, it is easily done, just add it. If you have a batch process you have to consider whether or not to rewrite it to be a dynamic script to avoid the pain, or whether you will add more pages.

In short there are a lot of issues. But there are partial solutions out there. And several of the more advanced templating systems (eg Template::Toolkit and HTML::Mason) have put a fair amount of work into figuring out how to reasonably trade off static caching, dynamic caching, and on the fly pages.

Hmmm. I assumed that the questioner was worried that he could be caught by some technicality if he went static or dynamic, and answered to reassure him that the technology was good for both, but static was faster. I tend to focus on the technical issues in my answers and assume that the procedural problems have already been thought about - I guess I should start paying more attention to the other parts of implementation beyond "Can it be done".

Some of your points rely on assumptions you have made about the situation the petitioner is in - for instance the method used to create static pages. They are valid points, but you are raising issues for a problem that hasn't been defined yet. He hasn't told us what build process he is considering, or what devel cycles he wants to follow.

When we did our static pages site, we actually wrote the site dynamically, and used it for a bit. When we were happy with it, we ran wget over it to create the static site. To us, this seemed to be the best way to get more performance out of the hardware that we had, and it worked.

I know this particular strategy won't work in every case, but it was excellent for us because we got the best of both worlds - instant feedback and debugging, and the performance boost from static pages.

As to the storage issue - well, I assumed that the questioner could do the sums. If the static website is bigger than the disk (or than the memory buffers) then clearly dynamic is better.

Please excuse this 5am post, I just wanted to get it out before retiring for the morning.

____________________
Jeremy
I didn't believe in evil until I dated it.