So tell me about dynamic static sites…

History lesson

I’ve been a software engineer primarily creating dynamic websites for a loooongtime. First there was a server with html files and caching proxies. Then therewere scripting extensions (cgi, php, asp-classic etc) to spice up your html,then there were full mature web frameworks for all the things (asp.net mvc,ruby on rails etc).

But then we got traffic and libraries and platforms and sdks and databases inthe cloud and everything became slow. 😞

So we added CDNs to make it all fast, and cache invalidation to make theengineers cry.

Now what’s old is new again, but with a twist, static sites pre-generated bydynamic code (such as my blog created with jekyll). We get the benefits of old

• CDNs love static sites; caching and proxying work again; and cacheinvalidation still makes us cry.

The new saviour is serverless (functions as a service) so that we can still adddynamic stuff to these static sites.

Yes I can go read endless articles about how to do all this stuff, and turnmy CV and skills on their head so I can sell the hot new thing. But what Iactually want to know now is….

What are you doing with dynamic static sites?

Have you tried it? As a pet project? As a commercial project?

Did it go well? Is it the new future or is it just for niche needs?

I feel like because this is all sooo new, that it’s not clear yet how welladopted this stuff is or will be, and how much of the old is being thrown outand rewritten.

My opinion…

…based on good knowledge of tech but not based on any actual experience is thatit depends entirely on the type of thing you are building:

• Low volume intranet/extranet style sites - don’t bother, asp.net / rails isfast enough, and it will cost you more to develop a blended static/dynamicthing.
• E-commerce: totally worth it because you can handle any spike in traffic toyour front page, and serverless lets you seamlessly scale the dynamic parts.Caveat it will be more expensive to build but that’s okay because money inis proportional to how many customers you can serve well.
• Government or other highly accessible services - don’t do it. You can’t meetthe accessibility needs if half your site’s critical behaviour is done inclient-side javascript with calls off to serverless functions in the cloud. Imight be wrong about this, I hope I am. Maybe it’s possible but just hard.
• Your blog and other traditionally CMS driven sites: just use jekyll for yourown blog and put it on github pages.For more complicated commercial sites static site generation is a big win interms of technical complexity reduction, reliability improvements and speedimprovements for users. Which static site generator you use will depend on yourorganisation’s internal needs. (Can everyone use git? Or do you need a UI forpeople to type in? How much money to you have?)
• Etc. (there are sooo many reasons for tech, I’ve just picked a few)

Speak out now

Before you go, comment below.

What have your experiences been with the shift to dynamic-static sites? Haveyou done any of it? Do you think I’m right/wrong about any of this?