Static or Dynamic?

Cleaning up some hacked Wordpress sites recently reminded me of why I had shifted my own sites away from it and onto simpler tools which create static sites—tools that result in pure HTML/CSS/JS loaded directly in the browser, no server side processing required.

The original impetus for my own move was to remove the headaches and hassles around securing and maintaining Wordpress sites; note though that you could substitute Wordpress here for any other popular framework, particularly a CMS (Content Management System), Wordpress just happens to be a big target due to it's popularity. It isn't that Wordpress is bad, full-stop, but instead that I wasn't using any of the features that would have made the costs of maintaining it worthwhile.

Sidebar: Amusingly none of the features that I would find useful enough to choose Wordpress were what Wordpress was originally built for, namely blogging. It's evolved far away from it's original purpose as a blogging tool; one of the reasons why this blog began on Ghost.

How will someone use your site?

Will they be reading articles, watching videos, listening to podcasts, or more broadly consuming what you create? Or will they (also) be interacting with either your content or each other?

Only the latter justifies a dynamic site, because it requires a form of user authentication and user accounts to make it work.

There's a third case here, around eCommerce, but that's far more dependent upon the project's size and type of products being sold. There are solid 3rd party services that can handle transactions without needing to manage a store directly on your site.

The 2023 update

Weird to see when I originally wrote this piece, which was a quick bit to explain to myself the reasoning for choosing a static site at the time. The logic for the decision has held together, and even in some cases become stronger. The security benefits remain as strong, and with more options for integrating APIs and third-party tools it continues to make sense to maintain a light footprint static site like this for what I do.

In 2015 when I first began exploring using static sites the term JAMStack (Javascript, APIs, Markdown) hadn't yet been popularized—2016 has that honor according to JAMstack.org's own home page. At the time I was settling into using static site generators, first Hugo and then the more recent pivot into using my own sites as a means of dogfooding Vue. For me static and JAMstack made sense, as I was already maintaining my own code, and it was overall less work to maintain a small Go or Vue based site, with some Node based build tools, than the more traditional server and database backed architecture.

I was making that switch for myself, but if I were taking on web development clients at the time I wouldn't have recommended JAMstack as an approach to them, despite saying above that the only justification for a dynamic site is user accounts and interaction. But the reality is that user accounts to create the pages, posts, etc. also count, and there is still utility there; that is why systems that have some kind of central CMS, like WordPress, Squarespace, Ghost, etc. were still better choices for non-developers because the means of interacting with the application than purely via text (via markdown) and Git commits. As I'm both a developer and have gotten very comfortable with markdown handling everything about my site inside my IDE is my comfort zone, but I guarantee you that it's a text-only hell for most folks.

Has anything in that department changed since 2015? Yes and no, it's a bit like a barbell: all the weight is on both ends and almost none in the middle. In the world of static sites it does still seem to require that kind of hands-on-code work to run them, so they remain suitable for developer types. While in the DIY and low-to-mid website building space, for those who don't want to code, it still makes sense to make use of larger platforms like those mentioned earlier, and both those and others (like Wix) have improved in their designs and UX since then.

JAMStack becomes a great choice again once you have a team though, as the API part of the JAMstack architecture means you can take advantage of building an independent front-end that can work together with tools like headless CMS (for your content and marketing teams), serverless functions for some types of on-site interactions, and can then decouple your backend services in a way that makes for a more flexible set of systems well suited to all the potential applications that might need to consume data from that backend API (web, mobile, etc.).