So tell me about dynamic static sites…
History lesson
I’ve been a software engineer primarily creating dynamic websites for a loooong time. First there was a server with html files and caching proxies. Then there were 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 in the cloud and everything became slow. 😞
So we added CDNs to make it all fast, and cache invalidation to make the engineers cry.
Now what’s old is new again, but with a twist, static sites pre-generated by dynamic code (such as my blog created with jekyll). We get the benefits of old
- CDNs love static sites; caching and proxying work again; and cache invalidation still makes us cry.
The new saviour is serverless (functions as a service) so that we can still add dynamic stuff to these static sites.
Yes I can go read endless articles about how to do all this stuff, and turn my CV and skills on their head so I can sell the hot new thing. But what I actually 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 well adopted this stuff is or will be, and how much of the old is being thrown out and rewritten.
My opinion…
…based on good knowledge of tech but not based on any actual experience is that it depends entirely on the type of thing you are building:
- Low volume intranet/extranet style sites - don’t bother, asp.net / rails is fast enough, and it will cost you more to develop a blended static/dynamic thing.
- E-commerce: totally worth it because you can handle any spike in traffic to your 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 in is proportional to how many customers you can serve well.
- Government or other highly accessible services - don’t do it. You can’t meet the accessibility needs if half your site’s critical behaviour is done in client-side javascript with calls off to serverless functions in the cloud. I might 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 your own blog and put it on github pages. For more complicated commercial sites static site generation is a big win in terms of technical complexity reduction, reliability improvements and speed improvements for users. Which static site generator you use will depend on your organisation’s internal needs. (Can everyone use git? Or do you need a UI for people 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? Have you done any of it? Do you think I’m right/wrong about any of this?