2023-07-15
Static websites have a low barrier to entry
Yesterday I wrote about a criticism of the usual static versus dynamic website divide, where I noted a number of (what I see as) significant differences between static and dynamic websites in practice. But there is another important difference in practice, and that's the amount of expertise that's needed to create each of them. Specifically, static websites don't require much expertise to create. Given a suitable general web server environment, which is easy to provide, all you need to set up a static website is the ability to write HTML, or even an authoring and editing tool that will do it for you.
(Well, you need to be able to put your edited files on your web server, but generally this is straightforward, especially at small scale.)
There are dynamic website environments that are almost this simple, but they're also necessarily relatively canned, fixed function environments. The obvious examples of this are the various providers of hosted blogs and similar things such as Dreamwidth. These are all dynamic sites, but your options for changing how they work are usually both relatively modest and more complicated than 'write HTML'. In addition, you have the hidden complexity of picking which of the many varieties best meets your needs.
(Then, over a long enough time span you may have to deal with moving from one canned service to another.)
A fully custom dynamic website has a quite high expertise level, because you need to be able to program (in some environment). When Wesley Aptekar-Cassels' There is no such thing as a static website looks forward to a future where there is a standard API between web servers and dynamic websites so that dynamic websites can be readily moved between providers, it's still seeing a future where you have to program to create your portable but dynamic website. You can't get away from this; it's intrinsic in the extra freedom that being dynamic gives you. Either you have to write code or you have to sort through other people's code to find one that does what you want.
In a sense, static websites have already done this sorting and arrived on a feature set for you. But it happens to be a feature set that's both fairly simple and fairly general, one that's proven to be quite adaptable in practice over the time the web has been here.
Another aspect of this is when you need the expertise. If you have only static HTML and CSS, with no JavaScript, you put essentially all of the expertise and work needed to creating the HTML and CSS. Once created, it's static and won't actively need changes (although you may want to change the look every so often even if the content doesn't get modified). All of the ongoing work lives on the other side of the static website split, in maintaining the web server itself. Pragmatically, this helps a lot to enable low-attention websites, ones that you can mostly ignore for long lengths of time and don't have to constantly look after.
(If you run the web server itself you do have to keep up with things there. But there are ways of offloading this work to someone else, and there are lots of providers of the service.)