May 2025 IWC—More Easily Joining Small Web Communities

Chris chose this month's theme of “small web communities.” I'm writing about making it easier to become part of a small web community on the IndieWeb: some potential inroads, potential problems, and open questions I have.

UPDATE: if you're interested in making your own site, Coyote has a helpful guide here—please check it out!

Barriers to Joining the IndieWeb

Max Böck (writing back in 2022) succinctly captures an issue that's been on my mind lately, observing that

Generally speaking: The more independence a technology gives you, the higher its barrier for adoption.

I love the experience I have on the IndieWeb, using technologies like webmentions and microformats ^[1] to interact with others in a way that's open and modular. I like the IndieWeb principle of “small pieces loosely joined,” and how that allows me to replace any one piece of my IndieWeb infrastructure should what I'm using “enshittify.”

I want to make this independence more accessible—to ease some of the issue Max Böck mentions—but how? I'll use this post to think through some possibilities I've been mulling over (addressing a range of potential levels of tech experience), and I would be very interested to hear other people's thoughts and input on these possibilities!

Ways Around These Barriers

On the IndieWeb Without Your Own Website?

First, Tracy Durnell suggests that

we can help people escape the corporate silos even if they don’t want their own website. […]

The more people who use the independent web—whether creating new work, participating in conversations, curating links, or simply reading—the healthier it becomes.

I like the idea of expanding participation in the IndieWeb beyond just the people who own a website, and including non-site-owning readers. Speaking as someone who maintains my own site on the IndieWeb, I love when I see people interact with my writing on social media sites where I POSSE my posts—no webmentions required.

Comment sections on personal sites can be great as well, ^[2] and can offer further ways to interact. Alex (someone who does have webmentions on their site) writes about preferring when blogs also have a comment section, noting that

I’m just sometimes tired of high quality stuff, you know? Sometimes, all I want is to comment on someone’s post to say « lol » or « nice thanks for sharing » or « saaame! » and that’s not something that warrants a whole blog post and entry in my RSS feed.

Finally, there's email. I have a mailto link at the bottom of every post, and I've had nice experiences sending and receiving emails related to my and others' writing on the IndieWeb. Even outside the practicality of more (and more ubiquitous) ways to talk, I like the personal nature of (non-work) email, and the way it feels kind of like letter-writing.

Website Ownership for the Non-Developer

OK so someone wants to have a personal website, but doesn't know much/anything about programming. What then? Böck mentions Mastodon, Ghost, Tumblr, and micro.blog as contributing to lowering the barrier of owning one's own content, and those certainly are decent options.

Even with the more blog-like Ghost and micro.blog, as well as similar things like Bear, my biggest issues are 1) the editor is coupled to the backend, and 2) the data formats for your pages are less standardized than I would like. To expand on point 1, the tool for creating pages and posts is accessible via a web interface owned by the same people running the hosting servers. For point 2, I would prefer a generic format that has stood the test of time, such as Markdown.

My stance on both of these issues is because at this point, I use technology with the assumption that any tool or platform will enshittify, and I will have to be able to migrate to something else. I see my strategy here as fitting with the IndieWeb approach of “small pieces loosely joined”; I strive to make my workflow “modular,” with individual parts as generic and replaceable as possible.

For example, I use Obsidian for maintaining a personal wiki: Markdown documents, extended with wiki-style link syntax to link between notes. However, I make sure not to use plugins or features that would narrow compatibility of my documents, and I ensure that my notebook is compatible with e.g., Vimwiki, Zettlr, the Foam plugin, etc., so I can switch anytime Obsidian does something I don't like.

In my ideal no- or low-code web publishing tool, authors could use a program on the desktop that takes in a common format (such as Markdown) so that all pages can easily be moved to another CMS/static site generator (SSG). Since the program is not bound to any given hosting service, authors could put the resulting generated HTML on any service; Netlify, Neocities, GitHub Pages, and others are currently decent options, but with this setup, could easily be replaced.

Existing Low- & No-Code Options

One tool that I find to be a promising (but still imperfect) idea is Publii. It's an open-source (GPL-3.0) CMS/SSG that runs as a GUI desktop app. You can use a WYSIWYG, block, or Markdown editor to write pages and posts; create menus, add page tags, add CSS, and many other things; and then generate your site, outputting a folder of static HTML/CSS/JS files that can then be put on a server.

I like that this program is a standalone desktop app that can work with any server, and that it's easy to use. What I don't like:

• It doesn't seem to store posts and pages as (e.g.) plain Markdown files that could easily be moved to another similar tool.
  • It might be possible to get it to do this, but I wasn't able to figure it out; it doesn't seem to do it by default; and it certainly doesn't point the user toward this kind of workflow.
• Design is not very flexible. You can choose from a limited selection of free themes, with paid options, but even the paid options are monolithic, and you can't combine, say, a block layout skeleton with a layout-independent color/font/icon theme.

One idea this gives me, though, is a GUI SSG with Markdown files as input (and maybe with modular layout features), and with community extensibility. I use Eleventy and enjoy it very much. However, requiring the use of the terminal seems to be a big barrier (whether real or psychological) to use by non-developers.

Since writing/note-taking tools that use Markdown (such as Obsidian or iA Writer) seem to be decently usable and liked by non-developers, I could imagine a GUI wrapper around something like Eleventy/Hugo/Jekyll being helpful. Authors could take a folder of Markdown files (perhaps written using one of the aforementioned writing/note-taking tools) and turn them into a website, with the generator handling all code beyond the Markdown itself.

It might even be feasible to make a GUI wrapper that's compatible with multiple SSGs: choose from a menu whether you want to use Eleventy, Hugo, Jekyll, Astro, or another popular option. Because the terminal commands to install and use those are relatively straightforward, the GUI wrapper handles installation and running the SSG for users who might be intimidated by the terminal.

Inspired by Publii's model of themes, I could also imagine a system of modular community HTML templates and CSS themes. Perhaps one set of modules handles a CSS flexbox-based block layout, with just the CSS and the HTML<div>s/classes necessary to do so, and another handles the styling for colors, fonts, icons, etc. It could be an interesting engineering challenge to integrate something like this with e.g., Eleventy's partials and/or shortcodes systems, or similar parts of another SSG.

I haven't attempted any of this, so let me know if there's a roadblock I'm not considering, but I figure that integrating with one or more popular SSGs could further the goal of modularity and flexibility, and make the GUI wrapper easier to create and maintain.

What Makes Coding Intimidating

I have some changes I would like to see in the perception of what a website entails to make things less intimidating if someone does want to get their hands dirty with coding. I think a lot of people's perception of what programming entails makes putting together a basic webpage seem more intimidating than it actually is, especially with the “frameworkism” and emphasis on JavaScript in many frontend spaces. In addition to the obvious hurdle of coding at all, I imagine the complexity of the websites most people see on a daily basis unnecessarily skews the perception of what needs to be done to make a website.

Even if someone knows they can make a simple site, the lack of such sites creates an unfair comparison for people's first projects. ^[3] When I first started coding I was unsure of myself and didn't want to put something online that looked “less than” in comparison to other people's sites. Now that I've had the time and experience to form more thought-out opinions on programming and the web, I look at sites like motherfuckingwebsite.com and bettermotherfuckingwebsite.com with appreciation for their minimalism and focus on content.

I want to see more widespread emphasis that what these sites do is plenty, and that there's nothing shameful or “less than” about putting that online. ^[4] As I wrote about here, the magical thing about the web is hypertext itself: the way hyperlinks connect ideas and create something far bigger than any one person's ideas or writing.

Additionally, I want to emphasize to those potentially interested in the IndieWeb that webmentions/microformats/etc. are nice but by no means essential. As I mentioned above, a simple mailto link on each post—especially combined with POSSE-ing posts—is a fairly decentralized and open way to socialize on the IndieWeb without much technical overhead.

Of course, I should acknowledge that even this requires at least some degree of both technical know-how and comfort with searching/willingness to search for technical answers online. ^[5] Additionally, if only some IndieWeb community members have access to webmentions/etc., while others “only” have email links, I worry that less-technical community members won't be able to feel like full participants. I don't have an answer to this—again, it's that inverse relationship between independence and barrier to entry—but I'm continuing to think about it.

Wrapping Up

This was the first post on this blog for which I made an outline, and I even re-wrote the outline multiple times! This was because I apparently have a huge list of thoughts on this inverse relationship between independence/barrier to adoption, and many of them didn't make it into today's post (in the interest of brevity and clarity).

I plan to continue writing on this topic, and as I continue to think through all this, I welcome input from others with whom any of it resonates. Until next time!