WHEN LEARNING web development, students are first introduced to HTML, CSS and maybe some basic JS, at which point they’re making some basic static websites. Next they’ll get introduced to some scripting language and they’re off making dynamic websites that are interactive. So we learn “static = basic”, and “dynamic = awesome”, without ever really thinking more about it. Well, let’s think about it. What does this blog website actually need?
Static VS Dynamic
A BRIEF introduction to the difference. A static website is one made of files, which are served in response to a request. These include the usual suspects of HTML, CSS, and JS files, but as a semantic web advocate, I also serve RDF, TTL, N3 and JSON-LD, plus there’s the images, gifs, fonts, and the favicon. As we’re responding with files, there’s no opportunity for interaction between the user and the website.
A dynamic website is one that can generate responses to a request. Typically it is HTML generated on the backend, but it can also be JSON if we’re providing an API, or one of the semantic web formats. This ability to generate responces means we can take some data from the user and provide customised content.
So, dynamic websites have the advantage of being able to generate custom content. But the cost of this is the computation to create the content, which has to be done frequently. Whereas for a static website, just the files are returned. Therefore a static website has a speed advantage when it comes to response times and thus a cost advantage for hosting. You can even get hosting for a static website for free. (Thanks GitLab!)
The Third Way: Static Site Generators
THERE ARE some serious advantages for development to using a dynamic website, particularly around the use of templating. For
example, the navbar will appear on every page, in a dynamic website you write it once and include it on all those pages. Therefore,
you also change it once. With a static website that navbar is in lots of
.html files, and you’re going to have to change them all.
There must be a better way! There is, it’s a static site generator. These are like creating a dynamic website, but you only run the computation stage to create static pages once. So, I’m writing content in YAML files, I have some HTML and TTL templates, and I’m using a mixture of Prolog and Python to generate this website’s HTML, RDF, TTL, N3, and JSON-LD, including the tag and subject filtering pages. I’ve got all the features and advantages this blog website had as a dynamic site, without frequent recomputation of content. There are static site generators for many languages, I only spun my own because that’s the kind of thing I do for fun.
Pros And Cons
AS MENTIONED before, this website was originally dynamic. As I started to move it over to simple web in Prolog, I noticed that the only dynamic feature was filtering posts by subject or tag, and I can generate that ahead of time. So I’ve taken the website I was going to host dynamically, I generate new files on each update, and now we’re just responding with those. I’ve eliminated my hosting costs, and in theory response times should be faster too.
It’s not all good though. My free hosting means I don’t get logs, so I can’t see if my semantic web data is being used. Talking of which, it also doesn’t support Content Negotiation, which as a semantic web advocate really annoys me. Now you’ll have to request with the file suffix to get the semantic web files: http://www.paulbrownmagic.com/blog.ttl
So, why go static? Well if you don’t need interactivity with persistence for the website you’re hosting, you don’t need dynamic. By going to a static website you’ll have faster response times and can reduce costs, and no-one’ll ever know unless you tell them in a blog post. Use a static site generator, and you get the advantages of templating too.
Have a happy one,