Recently had some exposure to static HTML projects and noticed the incredible advantages in deployment/scalability/reliability. This made me re-evaluate old projects where I used dynamic web frameworks with a full tech stack (e.g. Scala/Play/MongoDB). Many of them didn't use much in the way of dynamic features, for most a request to a URL returned the same response HTML. For performance I normally ended up caching the response on the frontend webserver relying on this, so why do I insist on making things complicated?

Most of time these projects are just displaying some dynamic content retrieved from a data source using a couple of different layouts. Rather than creating an application to generate the HTML for the dynamic content each time it is requested, why not create an application to generate the HTML once at the point the content changes.

You can combine the static HTML site with a dynamic site to cover any requirements that need dynamic responses/functionality (e.g. administration, content management). Script the static site generation and deployment so it can be triggered by any content changes, use hashes based on content to minimise unnecessary regeneration. This gives you the advantages of static HTML while still allowing you to dynamically alter the content when needed. As an added bonus it makes it easier for designers/content editors to contribute, as you're just using HTML/CSS with simple templating.

Obviously this approach can't be used for everything, won't work with too large a data source or application with more dynamic content. But for websites where common request  responses are predictable, eliminating all that complexity will give you a incredibly fast and reliable site.

Links: