Yeah, this website is pretty 'ugly'

If you have managed to click-through to this obscure corner of the internet, I would assume that there's a solid 99% chance that you are just as annoyed as I am by the constant bombardment of ads, pop-ups and banners that constitutes the modern-browsing experience (TM).

Thus I thought to myself: 'Why just not do any of that and focus on what matters?' The information. The message.

That's it, that's why this website is ugly. Because I don't want to distract from the information.

Yesterday, I scribbled down my first, fundamental rant, disguised as this project's About page. I still processed it through (more-or-less, I can't keep up anymore) cutting-edge webdev tools like Astro.js and Tailwind CSS.

However, while I wanted to keep everything 'light-weight' and tried using as little CSS as possible at first, of course I inevitable failed and spent hours upon hours trying to find the right typefaces, box-shadow classes, opacity settings and just doing my best at making everything as responsive and a e s t h e t i c a l l y pleasing as possible.

If everything worked fine in the end (read: if I were a better developer), I probably wouldn't have woken up today and started looking for the easiest way to avoid all of this hassle - but of course: my design broke… and I got royally fed up with all of this overcomplication around doing something as simple as serving a (somewhat decorated) text document on the internet.

Keeping in tune with what I set out to do, I started peeling away layer upon layer of abstraction and functionality. Frameworks? Nah. Cookies? Definitely don't need those. JavaScript? Yeah we can do away with that too.

But what about CSS?

Basically, your browser already has a built-in set of styles for most HTML tags! Links, headings, lists, tables, form controls, etc. - they all should render just fine. Why would I need to apply custom styles other than to make the website prettier (read: distract from the actual content)?

Turns out I, and many others, actually don't. I'm fine with pure HTML and I intend to not get carried away by stylesheets or other fancy web development shenanigans again.

UPDATE: Shame on me, I know I know… but I want to include at least the minimum amount of compatibility with mobile readers and scrolling sideways becomes quite a hassle when I include source blocks. That's why I decided to go with the default options of org-publish, which include a tiinny bit of CSS. Here's to hoping that I don't get carried away again…

As this includes web frameworks, which I had previously used to manage my website content, and I'm not really keen on writing raw HTML (sorry, it's kinda clunky), all that was left to do to figure out a way to somehow inject my favourite piece of antiquated software into it.

I've been using emacs/org-mode as my main text-editor and organizer-suite for almost half a decade by now, so I'm super used to the org-markup syntax. That's why it only came naturally to try and make use of org's excellent HTML export capabilities for my website project as well.

While there are quite a lot of org-based static site generators out there, I was once again driven by the principle of reduction. Given that org already provides built-in support for exporting fully navigable static websites (org-publish), I set out to limit my usage to this package alone.

Luckily, I found myself in good company yet again and took inspiration from Meg In Progress, who attempted the same thing and documented it very thoroughly. Thank you Meg!

To sum it up and to give something back, I though I would share some technical details on how I implemented my org based blog. As the documentation became quite extensive, I have decided to split it into a separate post.