/~/blog/: Static page(s)
2024.03.04

Short History

Since the start of the World Wide Web over the internet almost 4 decades ago, Static web pages were the default, at least for a few years, before the introduction of “an unpleasant sensory and emotional experience associated with, or resembling that associated with, actual or potential tissue damage.” (pronounced as JavaScript)

And for a few years, professionals and hobbyists alike, used to craft these static websites manually using raw HTML and CSS.

Then came the dot-com boom, which gave birth to an explosion of different frameworks, paradigms, methodologies, and template languages.

Nowadays, there are so many Static Site Generator (SSG) frameworks; almost all of them support remote data sources (AKA Headless CMS), making it quite inclusive for professionals, hobbyists, small, and big businesses to build a blog, photo portfolio, news reporting outlet, or a communication channel with their audience.

In Short, Static pages are simple, versatile, fast, secure, and cheap. So cheap that over the years, many SaaS, IaaS, and PaaS providers have offered it for free (or charged just network traffic fees).
But… Most of these providers are trying to lock you into their ecosystem, which is understandable from financial incentives, but quite harmful to providers’ diversity.

Let me explain

A few years ago, Oracle acquired Wercker before starting to throttle free-tier offerings and delivering fewer and fewer updates to the platform, finally, rendering it completely useless.
Microsoft acquired GitHub, shortly before they started blocking developers residing in sanctioned countries.
AWS was already gobbling up a massive chunk of the internet infrastructure.
And I don’t like Google, plus their APIs and tools have always been quite bad.

So, I started looking for a new open-source home for my code, preferably with an open-source CI service.

Naturally, I started looking at GitLab. I have already been using GitLab for a while, mainly as a backup for the most important projects, but I wasn’t quite satisfied with its performance or with its CI system.

After some searching, I stumbled upon SourceHut. Long story short, a few months in, I migrated everything to SourceHut, with GitHub used as a backup for a few projects. I have been quite satisfied with the service, even with the recent DDoS attack.

The problem

Because during this time I was already in the process of moving this website’s domain registrar to Cloudflare, I needed to test that the website was working. I couldn’t just add a CNAME record pointing to the a14m.srht.site domain and the A or AAAA IPs were also down.

I needed to deploy the website manually, and that’s when I found that almost all the static page hosting providers only support integrations with GitHub or GitLab, or you can manually upload the generated website using UI

This is quite alarming. There are no open-source-based solutions, like using cURL, or git remote to deploy without relying on a proprietary code, or service provider APIs.
The only exception I found, was SourceHut using acurl (a custom cURL helper) for deploying the static pages, before changing it to their hut CLI.

And the same patterns can be seen also with independent CI providers, and although it’s at least much better on the integration side, GitHub, GitLab and Bitbucket are the standard supported services (because they are missing on $$$ otherwise), and although it is a much more complex case with CI, it should be theoretically possible to standardize how deploying static pages would work using webhooks or API requests.

The solution

I don’t know if there is a solution, but I hope to see more projects like SourceHut, open-source projects that challenge the ongoing monopolies, and provide alternatives that could at some point dethrone these giants.

Maybe that’s a solution.
Maybe supporting these projects is also a solution.
Maybe not.


PS: This site is built using Hugo, YAML, and Markdown
 Source: https://git.sr.ht/~a14m/a14m.srht.site