Why and how
7, November, 2020 | Go to comments- Why a blog?
- Why not Medium?
- What do I want in the blog?
- What do I don't want in the blog?
- How has the blog been created?
Why a blog?
Several years ago I stumbled upon dev.to, a software developers community where you can find experiences, technical writings or some funny caveats. A little bit later I found Hacker News, a news aggregator, software-related most of the time that has been taking most of my online surfing for the last year, where I have found lots of useful and interesting people and articles.Sometime later after reading many blog posts at Hacker News, I leapt and wrote a blog post myself regarding how the default configuration in Neo4J could cause disk space problems. After writing it, I published it on Medium, where it would be available for everyone in the world that might encounter this problem, as I found several mentions to that problematic in Neo4J's forums. Several days later, I found that Medium wasn't made for me.
Why not Medium?
After a couple of days, I found some things in Medium that I wasn't comfortable with, both as a writer and as a user:- Only two free articles a month: I want to make public some knowledge to anyone that might have the same problem. Do I want to put it in a platform that has a paywall?
- Content availability: Medium doesn't hold any exclusive rights on the content you publish in their platform, so that you have the full ownership of whatever you write, so you are not platform-locked, but having the article only in there makes you play with their rules, so if they change them or Medium disappears, your content does with it. Do I want that?
- Content monetization, monetize yourself! In the first days, Medium sent me several emails remembering me that I could enable article monetisation, where they would pay some bucks, and that's great. The possibility of writing some technical article and receiving some money for it is not bad at all. But maybe that makes me focus on making money with whatever I write instead of focusing on just writing because I want.
- Numbers, numbers everywhere: Medium is very interested in getting your content as popular as it can, as it translates in new users, so new potential customers so, in the end, money. To help that grow, Medium provides several metrics, like the visit count, average read time, number of shares, comments and applauses (Medium's like). All this information, which is ok, I don't want to look at them and, if possible, I don't want them. These kind of metrics are very useful for a wide range of use cases, but I don't want to write to increase a number in a dashboard. I want to write because I like to, so not having those numbers helps me.
Due to those reasons, I find that, if I want to write some articles and publish them, I should do it for myself, wherever I have control over its content, allow it to be visible to anyone without any kind of restrictions and not to worry at all about some kind of numbers attached to each post.
What do I want in the blog?
Once I have the full control over the blog, the following question is: What shall I include in the blog? In my case, the blog is going to follow some basic rules:Ownership
I should own the blog and its content. I should have full control over what is published and what is not, with no dependencies whatsoever from external resources. Because of that, I will manage the blog through GitHub. The changes performed within the blog will be tracked by git, and the publishing of the blog will be made through GitHub Pages. The format of the blog will be portable, so if I want to move over GitHub, I can migrate the blog to wherever else.Accessibility
The blog needs to be accessible to anyone that wants to read it. To achieve that, the blog needs to fulfil the following requisites:- Right election of colours, avoiding problems to colourblind people.
- Clean structure of the blog, so computer-assisted readers can easily read the blog to functional diverse people.
- Follow accessibility standards like Lighthouse or Deque aXe.
- Minimize resource usage. Accessibility does not only refer that the web, once loaded, should be easy to read to anyone. It also includes the ability for anyone to load the web, whatever internet connection or device the person has.
- No JavaScript. Some users disable JavaScript on their browsers, and those people should also be able to read this blog. However, do we need JavaScript on a blog? I think not.
Those requisites are not met in most of the web pages you visit daily except few exceptions, which maybe they are met to maximize the number of customers, not because of empathy, but hey, they are making it easier for everyone. It seems that we focus on working so the web can be displayed on every device, but we don't focus on making the web to work for everyone.
Ease of maintenance
I want to be able to add a blog entry wherever and whenever, without any hassle, without the need of installing any tooling or overly complicated publishing processes.Multilingualism
Every content on the blog will be available both in English and Spanish for several reasons:- Spanish is my mother tongue, so it is easier for me to articulate and communicate the ideas rather than any other language. Therefore, by writing the blog post first in Spanish will help me to structure what I want to say. Also, with this approach, I can make the content available to anyone that speaks Spanish but does not understand very well the English language.
- Several research papers point out that our personality switches depending on which language we are using. This idea is not widely accepted, but in my case, I can notice a slight difference on how I express myself in English and Spanish, mainly in the tone I use, so I find interesting to write every post twice so each personality if there is any difference, will leak into each post and will imprint its personality on each post.
- English is undoubtedly the main language on software development in the occident, so publishing the content in English is almost mandatory.
What do I don't want in the blog?
There are several things that I'm sure I don't want to be present in this blog:Cookies
Is there anyone out there that is not sick and tired of the cookie banner on every single web page? And, more importantly, why does every single page need using cookies? The answer to the latter is that almost everyone uses some kind of analytics in their webpages, mostly Google Analytics, so they need to store some cookies to send information to Google to collect information regarding web usage, how to improve SEO strategies and all these kind of stuff.In the blogs realm, it might be important to know how many visits does it have, the success of each post to know what works and what doesn't. In my case, as stated before, I don't want that information, so I will follow the path built by Henry Darger. I will write and publish only because I want to. There is a foundational difference here, and it is that Henry didn't show his work to anyone in the world, and I am doing just the opposite, but the philosophy of doing something because I want and I don't care if it has some success or not is underneath.
JavaScript
In the modern web development era, almost any web, however small it is, is built using Angular, React, Vue, Svelte, Polymer or whatever framework that is trending that day. Frameworks that usually aim to build highly interactive and dynamic web pages. This is not the use case of a blog. Because of the need for generating static websites, those frameworks also come with some tooling to help with that. Next.js for React, Nuxt.js for Vue or Sapper for Svelte.In any case, developing a static webpage forces you to learn the framework, work with the internationalisation module (i18n), how is it build and deployed, component lifecycles and so on, just to generate some old plain HTML files, and even with that, in most cases, they still need some JavaScript after the HTML files are generated.
But, is it necessary that amount of overengineering for the final result to be a simple HTML file with some text and a couple of images? No, it is not, and the amount of work, effort and learning to get that static HTML file is too high. And we are not speaking about the fact that those JavaScript files need to be parsed, interpreted and executed by the browser, which in most cases, for a blog post, it is not even remotely necessary.
Dependencies
It is well known that, when dealing with any JavaScript project, the node_modules folder becomes a black hole, where starting any project using any framework previously mentioned generates around 200MB worth of files, with lots of dependencies just for generating, again, some static HTML files for a blog post. Too much.Another awful dependency relies on software installed on your machine. Any project like that will need to have node installed, and you will need to follow several builds and deploy steps, which, if you need to rely on the node_gyp package on Windows, oh boy, you are going to have a tough time. So basically, for writing a blog post, we are relying on lots of software. It should be enough with a text editor and a decent internet connection, which will last forever, and it will not depend on dozens of dependencies that might not exist after some time.
Analytics
As stated previously, I prefer not to have any kind of analytics or metrics related to the blog, so the blog doesn't have any kind of component that gathers that kind of information. Therefore, the avoidance of cookies and their banners is easily achieved.How has the blog been created?
Once all the requisites have been defined, the next step is to choose the tech stack and build it. Let's remember what does this blog need to fulfil:- No cookies.
- No JavaScript.
- Make the blog accessible, both for functional diverse people and slow internet connections.
- As few dependencies as possible.
- Avoid all kind of metrics and analytics.
To fulfil all these rules, the tech stack has been chosen like this:
- No JavaScript framework at all, not even the ones that generate static pages, so no JavaScript is used here.
- Google Analytics not included. Cookies, metrics an analytics fall behind.
- Everything written in here will be done in plain HTML. The tech stack limits itself to HTML and CSS.
- For the looks I am using Writ, a drop-in CSS library, so, no custom CSS-classes, it just uses HTML tags to style the content. As it doesn't use classes, we can change the CSS whenever we want by just changing the CSS file. A list of drop-in CSS files can be found in GitHub.
- Both entries in English and Spanish will be separately written, in plain HTML, setting English as the default language.
- Before publishing anything, Lighthouse and aXe will be run against the web to check that it fulfils all the accessibility standards.
Those technical decisions don't come for free, as it introduces some degree of complexity when dealing with updates, template changes or things like that, as every post lives by itself, they don't depend on anything.