The Dark Side of Static Sites | Andros Fenollosa

Skip to content

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...