chapter

Smol or Not

Karl & André about the updated Hackers & Designers Website

In this written conversation, André Fincato and Karl Moubarak discuss the process of working on the latest version of the Hackers & Designers website. It is about the pains and joys of decision making, the complexity of creating a website for a growing group that includes many voices, while paying attention to and taking important steps in improving the site in terms of accessibility, a more sustainable server infrastructure as well as multilingualism for the content and structure.

KM = Karl Moubarak

AF = André Fincato

KM: What was the initial trigger to work on an update of the already working Hackers & Designers website? What was wrong with the old one?

AF: The previous version of the website had some recurrent small problems, which were learned and handled by the few people who frequently updated the wiki. My motivation behind reworking the site and being able to archive the wiki was initially triggered when I accidentally wiped out the entire server the year before. So I wanted to create a live archive of the wiki and an easy backup format. In this case this meant creating HTML files + images etc. At the same time, I must admit, I got caught by the bug of static websites and ‘smol web’ by browsing certain areas of the Fediverse,1 and somehow by building a live static site generator everything came together. Luckily the smol web bug disappeared quite soon, after 6 months, because I realised I could have this more interesting (and sophisticated) live-updating system to generate an ongoing archive of the wiki thanks to the MediaWiki APIs.

KM: What is the “smol internet” bug? Why is/was it relevant for our website?

AF: The smol web (see smolweb.org) is part of an ongoing obsession / preference / moral imperative to go back to writing software simple enough so that one human being can understand it all and to avoid ‘bloated software.’2 The outcome is often that people use computers only through the command line interface to minimize their computer’s processing power to the most essential and show us that the only way to use a computer is by typing text in it. Everything else beyond such text input is considered bloated. You are suppose to “man up,” get behind the terminal and throw out your mouse.”3 The smol web is a branch of this fediverse phenomenon that contrasts big internet corporations that primarily build social media apps, big websites, algorithmically enhanced. The smol web proposes to go back to a simpler web. Sometimes web 1.0 is the primal reference, sometimes people suggest that you should learn how to build your hand-coded website and turn it into a craft (https://html.energy/index.html). It all smells very reactionary even though the starting point can be a set of problems I agree with: see for instance the case with the permacomputing scene (http://viznut.fi/texts-en/permacomputing.html and https://permacomputing.net). They argue for computer frugality, low-energy software, commonality, and the like. Somehow I haven’t seen a mention on the permacomputing wiki that permaculture — a concept from the 1970s they borrow from — has been heavily criticized already at the time, for being sold as a form of advanced new technology in white western culture, whereas it has been the core principle of how to engage with land from indigenous populations around the world since a longer time; is permacomputing a continuation of these politics? In computer culture people tend to go back to the golden days of Unix and the C programming language.

KM: A remark that came back often about our old website is how slow, inaccessible and clunky it was. Even if for a fleeting moment, do you think your dive into the “smol internet” trend / moral imperative when approaching the development of the new site helped resolve some of these issues?

AF: I think what helped was not the smol web, but rather the desire to make an archive. Originally, it was the plan for the new website to be a live archive backed up in git repositories, which should live in different locations. The HTML-first approach drove it. The trend of a few years ago about static site generators was more influential to the final outcome of the new website. The smol web is more a “moral + cultural” layer.

KM: My last question about this phenomenon: Would you describe our new website as “smol”?

AF: On a technical level, we cannot describe the new website as part of the smol web, because the way we run it is quite unorthodox and not small at all: we run a MediaWiki instance and create a new HTML page whenever an article in the wiki changes. A smol web approach would probably erase the MediaWiki variable from the equation. We also do it all in Python as a running program (not a one-off command as opposed to how a static site generator would work), which is slow and not very efficient. Besides this, I think the smol web is all about being part of a certain club of people following a certain set of morals, camouflaged with a layer of technical reasons, and I personally don’t belong to it. It’s possible though that some part of H&D will find the phenomenon interesting in the future and or are engaging with it already, for which I cannot speak about.

AF: what do you think of the smol web if you have any impression of it?

KM: I have to admit, maybe with a little bit of shame, that I fully bought into it at first. I was very excited by the growing culture of hand-making websites (again) and the metaphors of websites as gardens that need to be maintained and kept with a “personal” touch and a lot of care. This was an ideology that I really wanted to see reflected in our new website. Fortunately the reality of website-making these days is very different than a hand-crafted, well-kept and beautifully manicured garden. Our website was an example of a wild, weedy mess with many hands fervently trying to fix it up as it was being made, sometimes under precarious conditions. There are many moving parts, a lot of holes, leaks, and hectic efforts to continuously mend them. The garden metaphor just doesn’t hold up. This is a good thing.

AF: For me it ultimately comes down to a new moral standard that asks to be followed, which does nothing against the climate crisis. After all, there’s a lot of well-written, efficient, websites that are also part of complex software , so it’s more of a spectrum IMO than creating another division of who is in the club and who is not because “bad”. xD

KM: If not “smol”, what were the core ideologies you wanted to take into account when building this website?

AF: I can’t list out the ideologies right away, so I’ll write down the core points I had in mind at the beginning:


So, maybe the core ideologies were:


Things have changed in the process, also quite drastically!

KM: It’s eye-opening to see how these were leading principles for the project, and these are definitely visible in the website’s inner workings as it currently stands. Indeed the reality turned out a little different. What conditions took the project further away from these principles?

AF: The website has become more reliant on the MediaWiki for many things. Maybe for the better, but I really at first wanted to move away from it. Maybe you can talk about it, since these were the changes you introduced to the project, which helped us to actually finish it? (:

KM: What I remember from the discussions with the group is that the proposal to give up MediaWiki was left unanswered. I am not sure what the reason was, but I imagine it had to do with us not having proposed a “better” alternative. In a way, despite it’s clunky interface, backwards API and messy developer experience, MediaWiki is a good and reliable space to write, collaborate and edit articles for the group. Although not a Content Management System, MediaWiki has been the best system for us to manage our content…

AF: That’s true. I won’t touch on that subject in relation to group politics, and overall as I said at the beginning, the idea of dropping MW stopped being an option for me too once I decided to leave the group. I think your suggestions nonetheless were less about strictly wanting to stop using MW, and more concerned, in a practical way, about how to implement certain features without using MW. In retrospect, if you did not suggest those middle-ground decisions, I would have probably found myself stuck in there because of “ideology.”

KM: Glad my amateur brain could be of help.

AF: Given the conditions just outlined, what was your experience in joining an existing project running since a few years already?

KM: My incentive to join the project was to work on two main aspects: the accessibility of the website and it’s maintainability in the long run. To be completely honest, I was scared of being handed over the responsibility of maintaining a repository like the last one. I am not the most experienced Python programmer and the way the former repository was written really followed one individual’s way of thinking. So for this project, I really tried to be involved from the start, even if a bit uncomfortable, and to follow along, process and tried to contribute where I could.

I’ve also had a positive experience of our exchanges. I felt I could get comfortable working on the parts of the project I was confident about such as writing more accessible HTML and CSS, and whenever I wanted to get a little bit uncomfortable and learn a bit more of the pythonic inner-workings of the site, you left me enough space to jump in and write together :)

AF: As a side comment, the previous website was where I wrote my first ever lines of Python code and my first exposure to web REST APIs. I did not know how to import Python functions (or that you could!) so it’s just one big file.

AF: What were the hardest things to understand in the process of joining the project?

KM: My initial response to this is technical: the repository of functions and classes was a lot bigger than I expected, and I wasn’t yet used to working on such large project with many imports. With some documentation and many many explanatory meetings, this eventually turned out okay.

Zooming out, the biggest difficulty I had with this project was it’s fluid timeline. We started in 2021 by gathering feedback from different sources, getting our current site audited for accessibility, consulting with experts and listing out the needs of the group. For many very justifiable reasons, we weren’t able to stay on track with the initial timeline we set for ourselves. We pushed and pushed until we finally deployed the website in February of 2024. A lot changes in people, an organisation and on the Internet in three years. It often felt like a construction site for a building with changing architectural plans.

Another challenge was being part of the group whose website we were making. There is a joy in working on our “own” project, but it was complicated to account for the needs of everyone in the group while being one of these people. In a way, I missed the distance and pressure of having an external “client” (for lack of a better word). I really wanted to be selfish with what we make but couldn’t as it had to work for everyone.

KM: How was it for you to juggle your own needs and those of the group when working on this project?

AF: I more or less did what I wanted, adjusting along the way for things that seemed to be helping the project (in those areas at risk of getting stuck forever). I perceived very little communication and exchange with the rest of the group, except at the end when it was time to dress up the website at which point it was already three years in and the visual design was not my focus, so I went along with it.

AF: How do you see maintaining the project after you “inherited” it?

KM: I am happy to “inherit” code that I was involved in writing and can understand. So far, it’s been a joy to go into and follow the documentation, and make changes where necessary. It’s clear that this repository was written to be maintained in the long run. It’s still a bit of a challenge every now and then to “enter” the development mode of the project, as I have to start up at least three different services to make any change, but maybe that’s something to work on in a v3.

One thing I think about sometimes is how central my position in the maintenance of this website became after your departure from the group. I am afraid of being a point of dependency (and potential failure) for any project as essential to the group as this. Like many of the infrastructure related tasks in our group, my intention for future maintenance is to collectivize this task: I would like the responsibility to be shared between multiple different people in the group. Let’s see what they think about it ;].



  1. The Fediverse is a decentralized social network where different websites talk to each other using a specific protocol (ActivityPub). A website in this case, is an ActivityPub instance (eg. a web server) where users can sign up for an account. Each instance can decide to which other instance they want to talk to. This is all in direct contrast with commercial social media platforms, where a company dictates unilaterally how the given network operates. For more on the topic, see Seven Theses On The Fediverse and The Becoming Of FLOSS.

  2. Bloated software is a term used with a negative connotation by a computer user towards a certain software having lots of unnecessary functionalities that makes it slow or power hungry. Often times, the term is used with a big emotional charge attached to it, as it comes from the experience of a frustrated and / or unhappy computer user. Sometimes the term goes through certain phases where it’s used a lot in a manic depressive way expressive more a sense of fear and obsession of the user rather than a software being actually bloated in any actual way.

  3. See Terminal boredom, or how to go on with life when less is indeed less.