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.
Feel free to use or contribute to http://examples.tpxl.io - it sounds pretty similar to what you're taking about.
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. 😬)
Gutenberg compatibility would be killer. All the tools are there in Gutenberg to make awesome IndieWeb friendly posts, but might be difficult to get it to play nice with the current plugins & themes.
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. 1 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. 2
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.
You have hit upon one of the great conundrums of the IndieWeb - everyone loves static sites until they want to do something dynamic 😄
I know you already moved off Next.js but I use that now, and it can actually be a mix of statically generated and dynamic content which works great for me.
The other thing to look into is basically fancy build steps. I don't really know if it is common in Jekyll, but in things like Gatsby and 11ty it is quite common to have a build step that pulls data from external sources, then new builds can be fired by webhooks.
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.
Tried wsl2 yet? I've found it works with pretty much anything I've thrown at it. Only issue is the slow windows filesystem - but apparently it's way better if you use the specific wsl file system
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.
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.
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.
This is actually pretty close to some ideas I had for a microsub "middleware".
With the way microsub is built it would be possible to generate recommendations and category feeds without a centralized server. You can create a "client" that can automatically read channels from any server and create feeds / modify existing items.
I already have a decent working example in removing like posts from a feed and sending them as a daily rollup instead at https://glitch.com/~microsub-middleware
With this middleware idea there is also no need for specialized servers and clients, it should all just kind of work (hopefully)
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
Yeah there might be workarounds, and there is the idea of a micropub media endpoint for that sort of thing. But it doesn't feel as nice to have one part serverless and the other part not.
People have at least thought about this, not sure if there are any working examples out there though.
A common problem people ran across was serverless functions enforcing a maximum post body size, so no real media posting.
Oh hey, you're just down the road from where I live! Enjoy!
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.
Try bitwarden_rs instead! I've been running that for a year or so and loving it.