The Dark Side of Static Sites

For almost 8 years I used a static site generator for my blog, specifically Jekyll. However, when I decided to redesign my site, I was very clear that I was going to migrate all the content and logic to a dynamic solution. I had spent too long limited by the static nature to repeat the same mistake. After a long but satisfying change, I can now say that I don't regret having taken the step.

Before I start, a note on transparency: I am the author of Django LiveView, the framework I now use to serve this blog. So take what you read with that vested interest in mind.

I want to share the reasons that led me to this move, and along the way, talk about the dark side of static sites that not many dare to say out loud. And before being accused of heresy, I want to make it clear that I am not against static sites. In fact, I still think it's a good option for many use cases and a good gateway to get started in the world of blogging.

Arguments in favor of a static site

When we start a blog, we all instinctively feel seduced by the idea of a static site. And rightly so:

• Write with your favorite editor: You create or edit your articles in plain text with your favorite editor.
• Simple deployment: You only need a web server or any free hosting.
• Minimal maintenance: No security worries or emergency patches.
• Good performance: No need to worry about server load.
• SEO friendly: Search engines will love your site.

And why deny it: a feeling of moral superiority over the big CMSs that require a server and a database. You feel more independent, more of a hacker, and aligned with the IndieWeb philosophy. Win-win.

If you are the profile that asks nothing more of your blog than: that the articles read correctly, that it is navigable and that it has an RSS feed; a static site is perfect for you. You don't need more. However, every big project started out small. As soon as you want to take a step further, the opportunity costs begin. Every concession implies a sacrifice.

The opportunity cost of a static site

The fact that content is static doesn't mean it can't have dynamic elements. For example, to personalize the appearance (dark mode, font size, etc.). However, not everything can be fixed with a bit of JavaScript or an extension of your static site generator. As soon as you need communication between your reader and you, beyond email, we are already setting foot on rough terrain. Such as a form (comments, contact, search, etc.). But it can also be that you want a better user experience (infinite pagination, content preview, etc.). A static site runs out of resources.

As the site administrator, you have to hack it:

• Create a script that generates the content periodically.
• Use JavaScript to manipulate the content.
• Integrate a third-party service widget.
• Implement a backend (or APIs or Serverless).

You depend on the outside and the headaches: Do I want my content to be mine or third parties'? For example, if you use Disqus for comments, or a similar service, the comment content will be stored on a server and database that isn't yours. If they close your account, everything will disappear. Also, your indie site is storing your readers' data on a server that isn't yours. Note the contradiction.

In short, every time you gain a dynamic feature on a static site, complexity and maintenance cost increase. Or worse still, dependence on third parties increases.

What a dynamic site brings

Let's talk about what I have now, which before I either couldn't do or was very complicated to implement.

• Scheduled publishing: I can write an article and schedule its publication for a specific moment.
• Contact form: I can receive messages from my readers and reply to them, without exposing an email address.
• Comments: I can receive comments from my readers, render them alongside the article, and moderate them from any device.
• Search: With results that are instant and navigable.
• Newsletter: They can subscribe or unsubscribe. All their information is stored on my server and not on a third party.
• Protocol integration: I can receive and send Webmentions, or partially interact with ActivityPub.
• Admin panel: I can make quick and subtle changes from the browser or smartphone.
• Multimedia content: I can upload images and videos, and the system takes care of optimizing, resizing, and converting between formats.

Furthermore, I can now offer browsing tailored to visitor types.

• AIs: They read the content in Markdown.
• Indexers: They read the content in HTML, statically, without executing JavaScript. Also for human readers with JavaScript disabled.
• Human readers: They read the content in HTML over WebSockets (SPA) and with dynamic content.

The same content in 3 different formats, adapted to each way of consuming it. I develop all of this in more depth in Write in Markdown, serve it dynamic.

I would add screen readers to the list, since it's the part that shines the least but on which I have also invested considerable time and I don't want it to go unnoticed. However, it is not a feature exclusive to a dynamic site.

Some of the functionalities are salvageable if we have our backend/script running on a server, with some API that lets us interact with JavaScript. But here we enter territory that is not trivial: is it still a static site? A hybrid, where the content is static but the interaction with the user is dynamic?

We don't lose the advantages of a static site

The 4 advantages I mentioned at the beginning about static sites are still valid, although with nuances:

• Write with your favorite editor: Perhaps the part we value most is precisely editing content in plain text. Each of my articles is a Markdown that is dynamically rendered to HTML. I can even preview the result in real time, without needing to compile anything. My backup is still a Git repository.
• Simple deployment: We can't hide the complexity behind a dynamic site in its deployment, but once you have built your pipeline, it's as simple as a static site. In my case I only have to run a git push and my CI/CD pipeline takes care of the rest.
• Minimal maintenance: Not every day, but from time to time you have to review security updates, both in my framework and in my Debian. Even so, I consider the work to be very low: a few commands every now and then to update dependencies and the system, which I review myself before applying.
• Good performance: With CDNs and content caching, the performance is comparable to that of a static site.
• SEO friendly: Everything remains indexable and accessible to bots, even better since I can customize the content for each type of bot or human reader.

Stack

Before closing, it would be a good exercise in transparency to show my current technology stack. I don't consider it to have anything exotic.

• Web server: Nginx
• Database: PostgreSQL
• Backend: Django + Channels + Django LiveView
• Background tasks: Huey + Redis
• Frontend: None, Django LiveView handles it all.
• Operating system: Debian
• Containers: Docker + Docker Compose
• CI/CD: Gitea + Script

The content lives in Markdown files and the multimedia files are optimized on the fly with Imagor, which I use for various purposes.

Conclusion

I think it's faster and more satisfying to start with a static site. Although if you are ambitious, it will end up being a burden. The opportunity cost too high and the dependence on third parties too great.

On the other hand, modern CMSs are very good and easy to install with containers. Besides, it's relatively simple to reach all my points through extensions or with a bit of code if you are a developer. There are also hybrids like Astro, with Islands architecture, that let you have the best of both worlds. But if you want total control over your content and your readers' experience, a dynamic site is the best option.

A static site is a good option for a personal blog without many pretensions or that doesn't care about its visitors' information. But if you want to go a step further, or you go professional, dynamic sites break through any limitation, even surpassing the advantages of a static site. Of course, it all depends on your needs and your technical skills. Let's not forget that for the vast majority of cases, a static site is more than enough. But I'll leave you with one last reflection: is it enough for your readers?