Reply with your personal site that runs on @vercel. RTs appreciated.

— max 🌳🏔🐕💻 (@mschoening) January 5, 2022

Been thinking of doing a mini-site of sorts. “Microformats That Work,” with real-life markup examples and tips ’n’ tricks. (I mean, there’s the wiki and I know I’m able to edit it, and DRY and such, but it is kind of hard to navigate.) Maybe that: just examples, no discussion. Like, a minimal example and one that goes all out, per post type. And possible, “traditional,” RSS alternatives.

May one day port some of the tricks I’m using to “greatly” simplify my “WordPress IndieWeb experience” to an add-on plugin, or a theme, or both. Or at least better document how I do things like set titles (yet “hide” them on the front end) for notes, to make for a more convenient back-end browsing experience. As an alternative to Post Kinds, perhaps, and existing themes. (And then make the whole thing Gutenberg-compatible. 😬)

The reason this blog still exists today, after going through so many iterations, is that I always self-dogfood. This is a term in the IndieWeb community that means that I use my own creations. On my blog, everything has been built by me, for me. I haven’t thought about whether my code could be used by other people. It probably could. It’s all on GitHub for anyone to use. I have licensed my code under an MIT license so anyone can use it.

Over the last two days, I have found myself frustrated by this blog. My primary concern is scalability. When I say it out loud, I do wonder why I am so worried about how my site will scale. With all of the computing power available today, it would take a very long time for me to reach a point where my website rendered slower than a point I deem acceptable.

I am worried about scalability because I want this code to be lean. I don’t want to be bogged down by slow rendering times that make changing my site difficult on my local machine. I like speed. It’s the very reason that I moved from a site powered by React.js and Next.js to a static website. The way I see it, I have three options: build my own dynamic site, continue to use Jekyll, or look into another dynamic site generator.

The Dynamic Option

When I had a spare moment yesterday, I noted down what benefits of having a dynamic website are most important to me. The highlight was that I would have more control over the content that I share on my site. I would be able to experiment with new types of content because I’d have access to a database. My database could keep growing to support thousands of entries. I believe that if I had the option, I would be creating content on a similar cadence for this website between my blog posts, reviews, quantified self reports, and other data that I would generate.

Having a database gives me a lot of options. I know how powerful SQL is. I could use it to analyze how I post data over time. I could use it to easily support multiple post types. I could integrate my site with tools like Micropub to share my content on the internet. The question is not whether databases give me options. I am wondering whether they are giving me the right options.

I must note the educational benefit of building a static website. I am unsure what technology stack I would use. Flask seems to be the most appealing. I have quite a bit of experience with Flask and so I could probably get quite far in a short period of time. This is speculation. When I look at what I would need to do to set up a Flask site, I see tons of work that is, when I am really honest with myself, unnecessary.

The Static Option

I chose a static website for simplicity. My last site made API calls to Airtable to analyze my coffee data. I had a button on my desk which, when pressed, updated a counter on my site which said how many cups of tea I had drank that day (back in the days where I was more of a tea drinker). These were features. They were good additions to the website.

I can remember myself getting stressed about the state of my site. React, for a blog? It may work for some people but for me it seemed like too much. What’s more is that I got lost in components. I did not really understand how the site worked on a nuts-and-bolts level. I knew that it worked and that was good enough for me.

Static websites introduce new constraints. I cannot create database tables for new types of content. Do I really want to have that option? I’m not sure. I like the current structure of my site. Everything is so visible. All of my posts are stored in markdown which I believe is easier to maintain than a database. A few days ago, I went and updated all of the titles on my blog posts to use the correct capitals. It was bugging me for a while that Jekyll just capitalized the first letter of each word.

I went back and made the requisite changes to all ~60 or so posts. It was manual but it was so easy. With a database, I would have had to write individual queries for each post. That would have been a pain to do. I probably would have given up on the task before I had finished. Maybe that would have encouraged me to find a way to update my posts that I cannot presently envision. Who knows.

I like having a Jekyll site. I am proud to be on Jekyll. My content is easy for me to understand. I have a folder called _coffees where I am going to store my coffee reviews. I have a folder called _posts where my posts live. Adding new content to the site is simple. That’s what I like and need. The more difficult it is for me to update my site, the less likely I am going to do it.

Other Generators and Next Steps

I came across Jamie Tanna’s personal website yesterday. It was not the first time I have been a guest. ¹ I read that his site was powered by Jekyll and I got excited. I thought someone had cracked the issues I was facing with scalability. It turns out that he moved to another generator, Hugo. His Jekyll site took him far but he felt like a change was necessary. Jamie documented the process of moving over to Hugo on his blog.

I tried to set up Hugo yesterday to see how it works. One of the thoughts that came to mind is “why am I doing this?” That is a very good question. Why am I looking for another static site generator? What I have right now works fine. It may not work if I have ten thousand pieces of content on this site. That could happen if I build more elaborate bookmarks feeds, or write a lot of webmentions over the years. But what I have now works. It works. It works. ²

As a programmer, I have a tendency to over-complicate my work. I spoke about this in a recent blog post. There are so many ways I can improve this site. When I built support for my coffee reviews, I added support for the h-review microformat. I enjoyed doing it. I took my work a step further and I learned a lot in the process. I didn’t need to be using Flask to learn what I learned. So, for now, I am going to stick with Jekyll.

I am somewhat tempted to place a bet with a friend that if I move to another generator I’ll have to give them $100 or something. I haven’t quite made my mind up on that one just yet.

The only reason why I have Windows on this PC is for games and to be nosy about the progress of the Insider Preview (so much stuff in KDE/GNOME is popping up in Windows now!)

I might, however, just throw it into a VM - attempting to run Python or Node on Windows is a joke. And terminal emulators are still very supbar. Even with the Windows Terminal preview.

Even though we have a lot of trouble with SPOA when @aaronpk breaks something accidentally, I think a centralized Microsub server could do some stuff that could be tricky to accomplish without it.

Centralized feed fetching

If one server fetches and sorts feeds for several people, we get a reduction of bandwidth for popular websites, which may be important in IndieWeb because some people like me host their sites on a low-power machines such as a Raspberry Pi.

Also we get some degree of anonymization for public feeds because feed is fetched only once without revealing the IP address of a person reading it - only the Microsub service owner’s IP is revealed.

Recommendation feeds

A Microsub server hosting several people’s feeds would be able to match categories that people are reading often and recommend blogs that post often with the same categories.

This one could be done with an external service too. It would also have the advantage of being able to work across Microsub servers, but may be not integrated so well.

The workflow I’ve envisioned requires a Microsub client that could subscribe you to a person by clicking on a button near their author card: 1. The user goes to a special “recommended” feed 2. The server gives them a preassembled feed of posts matching following criteria: author isn’t in any other feeds and the post tags are similar to tags appearing on the user’s feeds. 3. The user reads the feed and if they’re interested in a person, they click on their h-card and the reader prompts them to subscribe to this person.

Category feeds

A variation on the previous one: the user could subscribe to a category instead of a URL, and the server would be able to construct a feed of all posts it knows of with the same category.

This one, though, could also be replicated by syndication and external feed services.

ah, true. although you might get around that by uploading large images etc to something like cloudinary first, then only send the hosted asset URL to the endpoint. 🤔

— Max Böck (@mxbck) October 7, 2019

hey has anyone made a #micropub endpoint as a serverless function yet? that would be really useful! #IndieWeb

— Max Böck (@mxbck) October 6, 2019

I was going to try out BitWarden but I have to try to install a bunch of .NET stuff on docker which usually I’m not opposed to but I can’t be bothered to right now.