Free widgets for your website!

I've been writing technical tutorials on my website since I started it last November, but this thread asking about static site generators for beginners on 32-bit Café made me realize I've never made a proper tutorial regarding SSGs from the ground-up basics. This post initially began as a reply to that thread, but I realized I had enough to say to fill an entire blog post. I hope this is helpful to anybody who has been interested in static-site generators but has found trying them out to be difficult, obtuse, and with a lot of friction. I'm someone that grew up using SSGs, going from editing the HTML on my Tumblr straight to setting up a blog with Jekyll when I was a teenager around 15 years ago now. While I would say I'm knowledgeable, being able to communicate and articulate that knowledge (particularly to beginners) is another skill entirely, and one I want to cultivate more. Hopefully I do a good job with that here! ## Prerequisites Let me start off by saying that, if you're brand new to web development, I do **not** recommend beginning with a static-site generator. If you're making your first website (or ten), I really recommend writing out the HTML and CSS yourself—this removes a lot of the abstraction that occurs with SSGs. Nearly all SSGs assume you know the fundamentals of HTML, CSS, and sometimes JavaScript. They also assume some familiarity with programming concepts, the terminal, and usually version control such as Git. You certainly do not need to master all of these before making a site with an SSG, but knowing what is going on underneath the hood will make the inevitable errors much less mysterious. ### Free resources I would work through the resources below in the order I've listed, creating your own sites along the way: * **HTML:** HTML for People is a friendly introduction written for people with no previous coding or web experience. MDN's HTML learning module is a more technical reference for when you want to get to aspects like semantic elements and accessibility. * **CSS:** MDN's CSS styling and layout modules explain things like the box model and CSS layouts. If you prefer interactive exercises and projects, freeCodeCamp's Responsive Web Design course covers HTML, CSS, accessibility, and responsive design. (Responsive meaning mobile-friendly in most cases) * **JavaScript and web fundamentals:** MDN's JavaScript module is a good addition to its HTML and CSS lessons. And freeCodeCamp's JavaScript curriculum is another free, interactive option. * **Programming fundamentals:** CS50x is Harvard's free introduction to computer science. Computational thinking, algorithms, data structures, functions, variables, conditionals, and loops. You don't need to know all of this, but the first few weeks of the course would give you a good foundation. * **The terminal:** MIT's Missing Semester teaches the shell, command-line environments, editors, and debugging. Check out the introduction to the shell. * **Git and version control:** Pro Git is a free online book that starts with the command line and basic commits before moving on to branches, remotes, and hosting. Reading this on a Kobo during my commute to college was how I learned git myself. * **Markdown and YAML:** The Markdown Guide is good for seeing how symbols are used for writing in Markdown. For YAML, the official YAML 1.2 docs are more detailed than you need, but the introductory explanation is useful. * **Checking your work:** To see if your HTML has any errors, the W3C Nu HTML Checker is a good resource to detect any invalid markup. MDN has a "Learn Web Development" resource as a single place to learn HTML, CSS, JavaScript, and browser fundamentals. There are others, like the Odin Project, web.dev, w3schools, and more. Understand that you don't need to know everything. You're doing this as a hobby, it's fine to make mistakes or do things in unorthodox ways that guides don't recommend. The important thing is not to finish every course before starting—build tiny sites as you go along with what you learn. Each step will give you more competency and functionality to add to your projects. ## Definitions Next, before I jump into the history of static sites, I want to define some often-used terms you'll see when reading static-site documentation and guides, since a lot of this jargon is typically not defined well. Most developers will simply think you already know all of this stuff by default. ### The Web and the Generator **HTML (HyperText Markup Language)** is the base document of a webpage, it's a language of structure and semantics. Headings, paragraphs, links, images, lists, and stuff like that. HTML is not a programming language, so it doesn't make decisions or repeat actions by itself. <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>My First Page</title> </head> <body> <h1>Hello, world!</h1> <p>This page has a <a href="https://brennan.day">link</a> and a list:</p> <ul> <li>HTML gives a page its structure.</li> <li>There's no CSS yet, so this is all default styling.</li> </ul> </body> </html> Save that as `index.html`, open it in a browser, and you get a real page—see it live here. **CSS (Cascading Style Sheets)** changes how HTML is rendered. This is how you add specific and unique colours, spacing, fonts, responsive behaviour, etc. body { font-family: Georgia, serif; max-width: 35rem; margin: 2rem auto; padding: 0 1rem; background: #fff2ce; color: #02005d; } h1 { color: rebeccapurple; } Add that inside a `<style>` tag in the `<head>` and the exact same page now looks like this. **JavaScript** is the most commonly-used programming language in web browsers. It is frankly rather janky, but it's what we have to work with. It can add behaviour and interactivity to your site, but it is rarely ever necessary and can slow down and bloat a webpage. I personally recommend using it sparingly. const button = document.querySelector("#surprise"); button.addEventListener("click", () => { document.querySelector("h1").textContent = "JavaScript did this!"; }); With a `<button id="surprise">` added to the page, that script does this. An SSG can also use JavaScript, for example, to run its build process or its template code. In 11ty, you can even write an entire template as JavaScript: // hello.11ty.js module.exports = function () { return "<h1>Hello from JavaScript!</h1>"; }; * **Static** means that a server returns a file as-is, without generating a new page for every request (typically a user visiting the page). A static page can still contain JavaScript and can still be changed later, as “static” only describes how the page is delivered, not whether it is immutable or boring. * **Dynamic** means that something generates or changes the response at request time. A traditional content-management system might query a database and assemble a page whenever someone visits it. A store website would need to keep a database of inventory that changes based on when people add an item to their cart and purchase, for example. * **Static-site generator (SSG)** is a program that takes source files (like Markdown content, templates, configuration, and assets) and builds a rendered site of HTML, CSS, JavaScript, and image files from them that can be hosted as a static site. * **Build** is running the generator's command that turns those source files into output files. * **Source files** are the files you edit, such as Markdown posts, templates, stylesheets, and configuration. * **Output files** or **built files** are the finished files produced by the build, often placed in a folder such as `_site/`, `public/`, or `dist/`. * **Local server** is a web server running on your own computer. A development server lets you view the built site at a local address (like `localhost:8000`) and can rebuild it when you save a change to a source file. ### Configuration and Data * The **Configuration file** is a file containing site-wide settings—it can include things like a site's name, base URL, menus, output directory, RSS options, etc. Different SSGs use different filenames and formats, including `config.yml`, `hugo.toml`, and `eleventy.config.js`. * **YAML** (usually pronounced “yamel”) is a human-readable data language often used for configuration and front matter. It represents values such as strings, numbers, lists, and key-value mappings. Indentation in YAML is significant, so a stray space can cause a build error. * **Key-value pair** really just means here's two parts to each config option, such as `title: My post`. In YAML, a collection of these pairs is called a mapping. * **Parameter** or **option** is a setting passed to a command or configured in a file. For example, `--serve` is an option in a command shown later in this guide. Here's an 11ty site settings file (`src/_data/site.json`), where you edit the user-facing details of your site: { "name": "My Cool Blog", "description": "Where I write about whatever interests me.", "author": "Your Name", "url": "https://example.com", "language": "en" } Every key-value pair becomes a variable your templates can use: putting `{{ site.name }}` in a layout prints "My Cool Blog", so changing the name here updates it everywhere at once. This is one of the neat features of SSGs, and it means you only have to change the name in one place. Other SSGs put the same idea in `config.yml` (Jekyll) or `hugo.toml` (Hugo) instead. ### Templates and Content * A **Template** is a reusable file containing the structure of a page, with various placeholders. * **Layout** is a template for a larger page shape, containing all of the following: the document language declaration, `<head>`, header, main content area, and footer. * **Partial** is a smaller reusable fragment, such as a navigation bar, header, footer, or post metadata block. “Include” is the instruction that inserts one file or fragment into another. * **Templating language** is the syntax used to insert variables, loop over data, and make decisions inside templates. Liquid, Nunjucks, and Go templates are examples. * **Conditional** is a yes-or-no instruction in a template, such as “show this element only if the post has an image.” Here's a simple layout (`_includes/layouts/base.njk`, written in the Nunjucks templating language) that uses a few partials: <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>{{ title }} | {{ site.name }}</title> </head> <body> {% include "partials/header.njk" %} <main> {{ content | safe }} </main> {% include "partials/footer.njk" %} </body> </html> And the partials are fragments of HTML: <!-- partials/header.njk --> <header> <a href="/">{{ site.name }}</a> {% include "partials/nav.njk" %} </header> <!-- partials/nav.njk --> <nav> <a href="/">Home</a> <a href="/archive/">Archive</a> <a href="/about/">About</a> </nav> <!-- partials/footer.njk --> <footer> <p>© 2026 {{ site.author }}</p> </footer> When a post's front matter says `layout: base.njk`, 11ty wraps it in this template: `{{ content | safe }}` is where the rendered post body goes, and each `{% include %}` puts a partial in place. Edit the header once and every page on the site updates. This is the copy-paste problem SSGs solve. * A **Content file** is a source file, like a page or a post, typically written in Markdown. In SSGs this is often Markdown, but it may also be HTML, plain text, or another supported format. * **Markdown** is a rather well-known markup language that uses punctuation symbols to represent headings, links, lists, emphasis, and other document structure. A generator converts this into HTML. * **Front matter** is a small metadata block at the beginning of a content file, commonly enclosed by two lines of `---`. It can contain a title, date, tags, layout name, or draft status. * **Blog-aware** means that a generator is specifically built for posts. It can usually sort them by date, and can generate specific pages like an archive, tags page, and RSS feed automatically. * **Metadata** is information like a post's title, author, publication date, tags, description, canonical URL, or chosen layout. Here's a single 11ty blog post (`posts/my-first-post.md`) that uses all of the above: front matter metadata written as YAML key-value pairs, Markdown content, and a little templating language. --- title: My First Post date: 2026-09-22 tags: - posts - cats layout: post.njk draft: false --- Welcome to my blog! This paragraph is **Markdown**. This post is called "{{ title }}". {% if draft %} This sentence only appears while the post is a draft. {% endif %} The front matter between the two `---` lines is metadata 11ty reads before rendering. `layout` tells it which template to wrap the page in, `tags` makes it part of the `posts` collection, and `date` is how the blog-aware sorting knows where it belongs. Everything below the second `---` is the content file's body. ### Validation and Publishing * **Hosting** is the service or computer that stores the output files and makes them available on the internet. Hosting is separate from writing the site, and also separate from version control. * A **Backend** is the server-side code and infrastructure that runs behind a website. It handles authentication, forms, business logic, or database queries. A purely static site does not need a backend to serve its pages. * A **Database** is similar to a spreadsheet that software can query and update. A traditional dynamic blog stores posts, comments, and settings in a database. Anytime you see `SQL`, that's a database. * **FTP (File Transfer Protocol)** is the protocol used to copy files between computers, commonly from your computer to a web host. It is one way to publish a site. * **rsync** is a command-line program that synchronizes files between locations. It can copy just the files that were modified, which makes it useful for uploading a built site to a server. * **Link validation** is a nice quality-of-life feature that checks if any links go to missing pages. Some SSGs do this during the build, and others require a plugin or an external checker. ### Version Control * **Version control** is a system for recording changes to files over time so you can inspect history, compare versions, restore an earlier state, and collaborate with other people. * **Git** is one specific version-control program. It runs locally on your computer and can record the history of a project without requiring a hosting service. * A **Repository** (or **repo**) is a folder/project directory with a history managed by Git. * A **Commit** is a saved snapshot of changes in a repository, typically with a message describing the change. * **Remote** is another copy of a repository. Typically, there's a remote hosted version of the repo on Codeberg, GitHub, GitLab, or a server you control. * **Push** is a command that copies commits from your local repository to a remote. And **Pull** retrieves commits from a remote and incorporates them into your local repository. * **Git hosting** is a service that stores Git repositories and may provide extras such as issue tracking, code review, or automatic builds. This includes GitHub, GitLab, Codeberg, etc. * Git hosting is convenient, but it's good to remember that it is not the same thing as Git, and is not required to use Git. Here's what publishing a new post with git looks like in the terminal: git init # turn this folder into a repository (once) git add posts/new-post.md # stage the file for your next commit git commit -m "Add new post" # save a snapshot with a message git push # copy your commits to the remote ## A (Very) Brief History of Static Site Generators Now that we have all those definitions out of the way, let's actually talk about the context of static-site generators. SSGs didn't start with Jekyll. The idea of separating your writing from the code goes back to the mid-1990s. A really early example is HSC ("HTML Sucks Completely"), an HTML preprocessor Thomas Aglassinger released in 1996. The term "static site generator" wouldn't exist for another decade or so, but HSC already had includes, conditionals, and link validation. For most of the late 90s and 2000s, the mainstream answer to "how do I blog" wasn't static. It was hosted, dynamic services like Blogger, LiveJournal, and Open Diary. Or full-stack tools with databases and a backend, like WordPress. The one exception was Movable Type, a Perl-based platform Ben and Mena Trott built in 2001 that did something clever: every time you published through its web GUI, it rebuilt your blog into plain static HTML files behind the scenes. You weren't using the terminal, but the output was static. Movable Type was one of the first tools to bring the benefits of a static site for people who never typed a `build` command. Nanoc was built by Denis Defreyne in 2007 after finding all Ruby-based CMSes ran painfully slow on the 96MB VPS he was using. Nanoc introduced layouts, page metadata, Markdown support, and plugins. It was a year later, in December 2008, that GitHub co-founder Tom Preston-Werner released Jekyll, out of frustration with complex blogging engines like WordPress. Jekyll built on Nanoc's ideas and added two things: front matter (the YAML block of metadata at the top of every content file) and being "blog-aware" out of the box, meaning you could put Markdown files in a folder and it would turn them into a blog with no extra setup. GitHub launched GitHub Pages alongside Jekyll as free static hosting, and that combination is a large reason why Jekyll popularized SSGs for many, including myself. Everything since has really been reinvention and iteration on the same idea in different languages. Some prospered and some failed. Octopress (RIP) and Middleman iterated on SSGs in Ruby. Pelican and Hyde are Python-based and Laravel-based SSGs, respectively. In July 2013, Steve Francia released Hugo, written in Go and compiled to a single binary. This was far simpler relative to Jekyll: there was no entire Ruby environment you had to install, or gem versioning you needed to wrestle with, and Hugo is fast enough to render thousands of pages in seconds. Eleventy (11ty) was created by Zach Leatherman in late 2017 as an agnostic alternative to Jekyll, using JavaScript and NPM instead. Whereas Jekyll required you to use the Liquid language, 11ty lets you use: * HTML `*.html`, Markdown `*.md`, WebC `*.webc`, JavaScript `*.11ty.js`, Liquid `*.liquid`, Nunjucks `*.njk`, Handlebars `*.hbs`, Mustache `*.mustache`, EJS `*.ejs`, Haml `*.haml`, Pug `*.pug`, TypeScript `*.ts`, JSX `*.jsx`, MDX `*.mdx`, Sass `*.scss`, and even Custom `*.*` Jamstack.org has a full list of different SSGs, if you happen to have experience in a specific programming language and want to leverage that. Something important I want to note is that some of these generators haven't been updated in years. And guess what? That's actually usually fine! The "static" part of SSGs means there's no backend or database to hack. Another benefit is that security isn't something you need to worry about. Did your favourite SSG add genAI slop in the newest update? Just never update. Your SSG will continue working and building your site the way it is now indefinitely. Hurray! ## Why is git always recommended? Aside from programmers just finding git to be the status quo default, I think a lot of the assumptions regarding git are due to the fact that Jekyll, the first popular SSG, began as a GitHub-specific project. Using GitHub (or Codeberg, or GitLab, etc.) answers the question "where do the files live?" which is in the repository. Neocities/Nekoweb answer this by you uploading your files onto the site. When you use something like Codeberg Pages or GitLab Pages, a lot is happening underneath the hood, and every time you upload or edit a file, it _is_ being committed and pushed with git, you just aren't running the commands yourself manually via the terminal or GUI interface. If you're self-hosting, then the answer is just your own computer, somewhere like the `/var/www/html` folder if you're on Linux. If you have a Tildeverse account (which is yet another rabbit hole), then your files would live on the publicly-shared computer. Here's my Tilde.town site for example, where I use the command `rsync` to upload my local files from my computer to the tilde.town computer and they're hosted automatically. There are two different things git is actually doing here, and they're easy to conflate. * Version history (so you can undo a bad edit or see what changed and when) * Hosting (somewhere for the built files to actually live). You don't need git for either one. `rsync`, an FTP client, or dragging files into a browser upload window all work fine for hosting. And you can take care of backups for your own small personal site instead of worrying about version history. Git just happens to solve both problems at once and for free, which is why it often becomes the path of least resistance. ## Theory vs. Practice On paper: * You take Markdown files in a `posts/` folder * They're rendered with a template in a `layout/` folder * Which has modules of HTML in `partials/` like `header.html` and `footer.html` * And there's probably a `config.yml` file in the root or something similar where you can edit the parameters of the site, like the name, colours, etc. * That `config.yml` handles site-wide settings, but most SSGs also give each individual post its own small metadata block, usually called front matter, sitting at the top of the file between two lines of `---`. * That's where a single post's title, publish date, and tags live, separate from the global config, so the generator knows how to sort and label a page without you having to name it `"2024-03-14-my-post-title.md"`. In practice, it is far more complicated. The process of taking all of the above and outputting it to a rendered static site (say, into a `/_site` folder) requires a programming language to process it. Most popular SSGs _try_ to make this simple: you run a command like `hugo build` or `npx @11ty/eleventy --serve` in the terminal, and that will do the above. (That `--serve` flag will start a local server on your computer, and regenerate the site anytime you edit the source files, rather than just building once and quitting. That's what makes editing a static site feel nearly as immediate as editing a live page.) Platforms like Netlify (or the self-hosted Coolify) essentially have a restricted remote computer that will detect which SSG you're using and run the appropriate command automatically, and your `/_site` is then hosted at `yoursitename.netlify.app` similar to how you'd manually upload your own HTML files to Neocities and have your site hosted at `yoursitename.neocities.org` There are other platforms that do the same (that I would not personally recommend): Vercel, Cloudflare Pages, GitHub Pages, and surge.sh. But all of the above has _a lot_ of assumptions built-in: you've done everything perfectly, _and_ the programming language used to build the site installed correctly, _and_ you know how to use the terminal. This XKCD comic on average familiarity comes to mind. If you have a typo anywhere important that breaks something (which could be as innocuous as an extra comma somewhere) the entire thing is fragile enough to break either during the initialization or build process, and the error message is designed for the programming language, _not_ the SSG. Which means you'll get a very technical output. Here's an example of a failed Netlify build my site had recently simply because I had a trailing comma in the file that stores JSON. If you don't have the stubbornness that masochistic programmers (like me) have, it's very understandable that you see the above error and go "fuck that" and just handroll your HTML, or use a CMS, or just don't make a site at all. That last one is the most heartbreaking to me. ## My Starters/Themes The way I learned was by taking pre-made starters/themes others have made (as others in this thread have recommended) and tinkering with them. Then, I started to get proficient enough to make my own. If you want to get to know an SSG, I hope I can recommend these, as they have good-enough documentation/guides and are designed to be instructive for beginners: * **IndiePaper** is a Hugo starter I made with all the IndieWeb stuff built-in (microformats2, h-card, etc.), where you put your posts in the `/post` folder and edit the `hugo.toml` file to customize. * **11ty-Indie-Web-Blog-Starter** is an 11ty starter I made from the ground-up based on my own site, where you put your posts in the `/posts` folder and edit the `site.js` file to customize. * **Watery** is a Jekyll starter I made ages ago, where you put your posts in `/_posts` and edit the `_config.yml` file to customize. All of these themes are minimal and plain (and kinda ugly) because the actual CSS styling and design aspects are left to the user. ## Other (Simpler) Alternatives All the SSGs I used above are very popular ones, but there are many more relatively simple options out there. Like barf and bashblog and kiki. * **barf** (blogs are really fun) is a shell script by btxx that's only 170 lines. It's forked from Karl Bartel's blog.sh. There's no front matter and no templating, you just write Markdown files, run `make build`, and it produces a `build/` folder you rsync to your server. It generates valid RSS automatically, runs natively on Linux, macOS, and OpenBSD, and the stylesheet is four lines of CSS. You can read the README or view a live demo. * **bashblog** is a single ~1,000-line `bb.sh` script with zero dependencies, using base Unix utilities such as `date`, `grep`, `sed`, and `head`. Carlos Fenollosa built the first version in 2011, writing about it on his own blog, and it's still maintained today. You download `bb.sh`, put it in a public folder on your server, and run `./bb.sh post` to start writing. It handles drafts, tags, Markdown, and RSS out of the box, no installation step at all. If you want more features, there's a community fork called bashblog-ng. * **kiki** is by vga256 and self-describes as "a tiny homepage construction kit with a small footprint". It uses PHP rather than shell, and it can run as either a live dynamic site or generate a static one, and also double as a public wiki or (in preliminary form) a Gopher hole. It's shareware and free with a footer credit, or pay $15 CAD and get additional features. It's 1,500 lines of hand-written code, zero JavaScript and zero external dependencies. It's a great option if you have a host that only allows PHP and doesn't give shell access. And here are a few others: * **ssg** is Roman Zolotarev's POSIX-compliant shell script. It's the inspiration for several of the others on this list; there's a Python rewrite called pyssg. * **sw** is a minimal web framework written in C, and the fork **simple-static** strips it down further into what its README calls "the simplest static site generator I can think of." * **makesite.py** is a Python equivalent of barf and bashblog. It's under 130 lines and built by Sunaina Pai around the idea that "the code is the documentation." The idea being that there's nothing to configure that you can't just read and edit directly. None of these alternatives have anywhere near the features that Hugo or 11ty have, but as a result, they also don't have the complexity. Finally, you may also be interested in making a blog in Gemini:// which is an entirely different rabbit hole I've been getting into recently, and eliminates the need to generate anything at all. ## Conclusion I use SSGs because if I were to handroll the HTML for my site, then I'd have to copy-paste the header and footer for every page, and SSGs take care of that kind of thing. I go into more detail about this in my IndieWeb ladder article. To me, I don't care how you webweave or what method you use to get your work online, as long as you're participating and trying, I think you're succeeding! Give my WEBMASTER@ manifesto a read if you haven't already. Static-site generators are just one of many ways to get into webweaving, and I certainly hope you join us—however that looks.

I'm Agnes the Alien (it/its), a 25 year old writer, artist, and hobbyist developer. This is my personal site.

Since writing my article on DHH, I've been getting an above-average number of emails in my inbox decrying my stance and public advocacy. And I have to be honest, I find it so _weird_ , more than anything. It's confusing to me how many typical people—men of the same ilk as myself—want to play defence for the handful of millionaires and corporate executives and weird little guys. A lot of the time, religion will be invoked, specifically Christianity. I'm a Christian myself, I've written my testimony before, and while I've had a wayward path, I know God meets people where they are. And that's why it's so baffling to me that people would attempt to invoke Christ when they tell me (and these are actual quotes from emails I've received) that they have scorn towards the "underpaid illegal labor," and that they refuse to become "inline with transgenderism" and that their "empathy and compassion are finite." It's baffling to me how the clear disdain for fellow human beings isn't obvious when they're spouting this rhetoric. And, perhaps more importantly, these kinds of beliefs are simply antithetical to the teachings of Jesus Christ in the Bible. Explicitly so. To go after the marginalized, to be anti-social justice, to support the rich? None of this is Christ-like. ## Christ Touched the Untouchable Let's begin when a leper came to Him, someone untouchable under the Law, and Jesus didn't keep His distance. Mark 1:40–41 says: > Now a leper came to Him, imploring Him, kneeling down to Him and saying to Him, "If You are willing, You can make me clean." > Then Jesus, moved with compassion, stretched out His hand and touched him, and said to him, "I am willing; be cleansed." Christ touched the untouchable. In Luke 17, ten lepers stood at a distance, crying out for mercy. Jesus healed all ten. Only one turned back to thank Him, and he was a Samaritan, a foreigner and outsider. Jesus said to him, "Arise, go your way. Your faith has made you well" (Luke 17:19). The outsider was the one who returned. A woman, often interpreted as a sex worker, and known as a sinner wept at His feet, washing Christ's feet with her tears and wiping them with her hair. And Jesus did not recoil at all. He instead said, "Your sins are forgiven" (Luke 7:36–50). He let her love be the evidence of grace. And later, in Matthew 11:19, Jesus said of Himself: > The Son of Man came eating and drinking, and they say, 'Look, a glutton and a winebibber, a friend of tax collectors and sinners!' He did not deny it. Christ has always been a friend of sinners. ## Love Your Neighbor, and Love the Stranger Scripture does not leave neighbour-love to our finite instincts. Leviticus 19:18 says: > "You shall not take vengeance, nor bear any grudge against the children of your people, but you shall love your neighbor as yourself." And when a lawyer asked Jesus, "Who is my neighbour?" Jesus told the parable of the Good Samaritan. A man is beaten and left for dead. A priest and a Levite pass by. The Samaritan stops, bandages his wounds, and pays for his care. The Samaritan was a despised foreigner. Jesus asks, "So which of these three do you think was neighbor to him who fell among the thieves?" (Luke 10:36). Not the one who shared his language, culture, or passport. The answer is the foreigner, the one who showed mercy. Then Jesus says, "Go and do likewise." The Law is explicit about immigrants. Leviticus 19:34: > "The stranger who dwells among you shall be to you as one born among you, and you shall love him as yourself; for you were strangers in the land of Egypt: I am the Lord your God." And Deuteronomy 10:19 says: > "Therefore love the stranger, for you were strangers in the land of Egypt." This is clearly not about assimulation. God says to remember you were strangers, and love the stranger. Christ always touched lepers, forgave the sex worker, made the Samaritan a hero, and commanded us to love the foreigner as ourselves. ## Christ and Those Outside the Binary Christ also made room for the eunuchs. Those who were not fully male by the categories their culture recognized, barred by Mosaic law from full inclusion in the assembly of the Lord (Deuteronomy 23:1), and treated as neither one thing nor another. Bodies or identities which did not fit into the binary. And Scripture says not to condemn them, but to promise them a place. Isaiah 56:3–5 says: > "Do not let the son of the foreigner who has joined himself to the Lord speak, saying, 'The Lord has utterly separated me from His people'; nor let the eunuch say, 'Here I am, a dry tree.' For thus says the Lord: 'To the eunuchs who keep My Sabbaths, and choose what pleases Me, and hold fast My covenant, even to them I will give in My house and within My walls a place and a name better than that of sons and daughters; I will give them an everlasting name that shall not be cut off.'" God doesn't tell the eunuch to become something else before he's welcome. God tells him his exclusion is over. Better than sons and daughters. An everlasting name. In Matthew 19:12, after His disciples balk at His teaching on marriage, Jesus says: > "For there are eunuchs who were born thus from their mother's womb, and there are eunuchs who were made eunuchs by men, and there are eunuchs who have made themselves eunuchs for the kingdom of heaven's sake. He who is able to accept it, let him accept it." Jesus names those born that way, made that way by others, and those who choose it. There is no condemnation. He doesn't erase the differences. He says some people don't fit the categories everyone assumes, and that's alright with Him. In Acts 8, Philip is sent out to the desert road to meet an Ethiopian eunuch, a court official, reading Isaiah in his chariot. This man is a foreigner, a Gentile, and a eunuch who would have been excluded from full worship at the Temple under Mosaic law. Philip does not hesitate. He explains the good news, and when they come to water, the eunuch asks, "See, here is water. What hinders me from being baptized?" (Acts 8:36). Nothing hinders him. Philip baptizes him on the spot. The very first Gentile convert recorded after Pentecost is a gender-nonconforming outsider. Christ's church opens the door wide. Paul, in Galatians 3:28 writes: > "There is neither Jew nor Greek, there is neither slave nor free, there is neither male nor female; for you are all one in Christ Jesus." The categories the world uses to rank and exclude people, including the male/female binary used to justify so much hate today, collapse at the foot of the cross. If Christ's own body of believers has no use for "male nor female" as a line of division, then the transfolk in our pews, our families, and our replies aren't a problem to be solved. They're already inside the "all one" Paul is describing. Given all this—the leper, the Samaritan, the sinner, the eunuch, the stranger—I struggle to find a single figure Christ excluded who was already reaching for Him. He was short with those hoarding power, and those turning away the vulnerable to protect their wealth. ## Camels and Needles And what of the rich? Let's not forget that the Omacom Foundation received over 18 million dollars, the majority of it coming from the personal bank accounts of millionaires. In Matthew 19:24: > "It is easier for a camel to go through the eye of a needle than for a rich man to enter the kingdom of God." A rich young ruler asked what he must do to inherit eternal life. Jesus told him, "If you want to be perfect, go, sell what you have and give to the poor, and you will have treasure in heaven; and come, follow Me" (Matthew 19:21). Of course, the ruler was devastated. For he had so, so much. In Luke 12:15, Jesus said, > "Take heed and beware of covetousness, for one's life does not consist in the abundance of the things he possesses." And He told the parable of the rich fool (Luke 12:16–21), the fool who built bigger barns for his surplus grain and said to himself, "Soul, you have many goods laid up for many years; take your ease; eat, drink, and be merry." But God said to him, "Fool! This night your soul will be required of you; then whose will those things be which you have provided?" In Matthew 6:19–21: > "Do not lay up for yourselves treasures on earth, where moth and rust destroy and where thieves break in and steal; but lay up for yourselves treasures in heaven, where neither moth nor rust destroys and where thieves do not break in and steal. For where your treasure is, there your heart will be also." James 5:1–6 is even more direct: > "Come now, you rich, weep and howl for your miseries that are coming upon you! Your riches are corrupted, and your garments are moth-eaten. Your gold and silver are corroded, and their corrosion will be a witness against you and will eat your flesh like fire. You have heaped up treasure in the last days. Indeed the wages of the laborers who mowed your fields, which you kept back by fraud, cry out; and the cries of the reapers have reached the ears of the Lord of Sabaoth. You have lived on the earth in pleasure and luxury; you have fattened your hearts as in a day of slaughter. You have condemned, you have murdered the just; he does not resist you." ## Empathy of the Spirit Empathy and compassion are fruit of a Spirit that multiplies loaves and fishes. To attempt to desperately ration it, to instead prioritize those who look like you and act like you—sounds like the priest and the Levite, stepping around the body in the road because helping is inconvenient and beneath them. There is no love there. I don't hear Christianity. I hear Matthew 19's rich young ruler, walking away grieving because the cost of love was too high. I hear James warning the rich to weep and howl for what's coming. Scripture, especially Christ's teachings, were always centered around loving those that society deemed the most difficult to love, and the easiest to hate. And Christ never promised the Kingdom of Heaven to the rich and powerful. I know Gospel will continue to be politicized and weaponized for cruelty, I know that. But it is really an invitation, repeated across a thousand pages. It is not difficult to figure out how to practice Christ's teachings in the modern day. It ies easy to see who is being shunned and cast out, who are being rejected and targeted. It is up to followers to do the right thing and love, and to speak up against injustice and power the way Christ did. That is simply what it looks like to follow Him. Go and do likewise.

Protest against the Omarchy/Omacom Foundation and the tech companies and executives funding far-right open source.

An Archive of Our Own, a project of the Organization for Transformative Works

Is anyone reading this? I made another blog recently to put one of my domains to use and try out Pagecord. I decorated it all in rainbow and Comic Sans but i...

This is what we'll be considering the "official web home" for updates on Femslash.Club projects. I'm so excited to finally be making this a real and expansive community, y'all. I love femslash so much. I love fandom, even if I struggle with what it has become these days---I believe in a fandom where we talk about things that bring us joy, things that we love, and uplift others while doing so. I believe in a fandom that is a supportive and equal community first and foremost. I want to help make it that way. So: femslashclub. A lot of people say femslash shippers need to shut up and make it ourselves. I find that line of thinking to be deeply annoying, but there you go. I made it myself, a home for femslash fans on the web, a real community. I'm proud of it all. Of course, I still think we deserve a home in wider fandom---to _not_ have to be _forced_ to make our own spaces, to be as welcomed as slash and het shippers are, and I will continue promoting and fighting for that. But it's also very refreshing to have a place catered directly to the things I'm looking for, the kind of people who share interests with me. We've been needing a place besides Tumblr to store updates for a while, and as Sunset slowly approaches its one year of existence, and as I begin to expand the services I offer, I figured it was finally time. Welcome official femslash.club website. Thank you Pagecord. Now it's time to look forward. I posted an interest check where I asked the community what services they'd like to see involved in the Femslashiverse. The top results were, in order: 1. PHPBB/Old web style forums 2. Dreamwidth clone 3. Femslash community wiki 4. BookWyrm/Goodreads alternative catered to F/F books/etc 5. Fediverse/Mastodon instance. I'm starting school in... ah. A week. So I know I have to limit what I take on. I think moderating Fediverse and forum instances would be too intensive at the moment, but I do plan on working on... -the Bookwyrm instance. This is almost completely set up I just need to fill in instance information. -the Dreamwidth clone. It is almost completely set up as well, but I'm having trouble implementing S3 storage. (If you can help me debug this, _please_ shoot me an email.) Additionally, recs is now open for users, and I've set up a page that tells you how to get an account on each of the sites. When I finish these projects, you'll hear from me again. For now, I want to say THANK YOU. Thank you for making Sunset possible, for posting on the site, for helping with the new server, for supporting me, for being there for me and the rest of the community, for everything. Thank you thank you thank you. Here's to many more years of Loving Women+ Online.

Information on femslash webhosting.

If you've been on the Internet, you've seen someone venting. The act of sharing anger, sadness, grief—usually with vulnerable, personal details. Almost universally, these get a bad rap. People are often drained, or annoyed, or resentful towards those who vent, and communities go out of their way to prohibit it. Not to pick on 32-bit Café, but they have a detailed section on mental health topics and discussions in their community guidelines: > The 32-Bit Cafe is not a replacement for support groups, therapy, or mental health organizations. There are excellent arguments against venting that they list, and I'm not trying to change any minds here; however, I do want to write a post in defense of the venters, because I think someone has to. Something I haven't written about on this blog yet is that I've been a Listener on 7cups for over ten years. I've had text conversations with hundreds of strangers, trying to console and comfort them to the best of my abilities as a layperson crisis support volunteer. The spectrum ranged from people who just needed someone to talk to about minor stresses, and say what they've been harbouring out loud in order to let it go. And on the other end, people who had active dangerous plans they were enacting and that I was not qualified for, nor what the site was intended to handle. What I learned quickly is that, for the most part, people just want to be seen and heard. To have the immeasurable weight of their burdens and trauma they carry to be a gravity felt by others, no matter how temporarily. People want to know that the intensity of their emotions isn't irrational, or too much. Psychologist Bernard Rimé studied the social sharing of emotion, between 88% and 96% of emotional experiences get talked about with someone else, usually within hours of happening. It's just something we do. And when someone listens well, the sharing strengthens the bond between people, because the listener's attention and empathy are reflected back to the person who vented, and the venter feels closer to the listener. A related study on friends working through stress together found benefit comes from both parties in the exchange, not from one person tolerating the other. Venting is how we've always regulated emotion. Together instead of alone. And we _are_ talking about the web, here. #vent channels on Discord have allowed people to "meet their needs for social support via vent channels by receiving commiseration, advice, and validation from the responses of others" according to research done by Kayode Oladeji et. al. James Pennebaker's research on confiding and expressive writing (which can absolutely include blogging) started as he observed trauma survivors who never told anyone about what happened to them showed worse health outcomes than the ones who did. He built a theory of inhibition arguing that holding back our thoughts and feelings takes a physiological toll similar to chronic stress. Follow-up studies found writing or talking through difficult material caused measurable gains in immune function, including in people suffering from HIV, asthma, and arthritis. How a vent works depends a lot on the person listening. Responding with real empathy, rather than passive sympathy, changes the outcome entirely. The idea that keeping your feelings to yourself is the mature, healthy default is backwards and harmful. Bottling things up has a cost that is sometimes irreversible. The reason why people end up dumping their emotional baggage and trauma in a one-sided manner, sometimes without even asking first, is because their cup is full. There is simply no more room to hold everything in any longer. When we aren't privileged enough to be raised in an environment surrounded by emotionally mature, thoughtful people, what do you think happens? Even further, when we are unfortunate enough to be raised surrounded by cruelty or malicious intent instead? The answer is that we do not vanish. Remarkably, we endure. But we only do so by coming up with mechanisms of defence and survival on our own. And these coping mechanisms are often maladaptive or self-destructive, because what else do we know? There are dozens of ways to mitigate emotional pain, and only a handful are healthy, and the healthy ways typically don't give us the same intensity of catharsis. Recommending people seek professional, clinical help comes from a privileged assumption that people can afford professional, clinical help—and that they have the time and energy. Beyond this, certain mental health issues and problems are considered (incorrectly) as "treatment resistant". The frameworks of Western psychology and our pharmaceuticals are just not sufficient for some people. And I don't think that maladaptive coping mechanisms like emotional dumping are sufficient either, but people need outlets. People need harm reduced. We cannot ask others to start at an acceptable starting point, we must meet others where they actually currently are. And we need each other, because all we have is each other. Community is not just a group of people, or a setting. Community is a living medicine. You cannot expect the medical industry to do all the hard, difficult work and only deal with tolerable, semi-healed folks. The mind, body, spirit and emotions all need healing and tending to. People need connection to others, as well as language, ceremony, and the land. Some people simply need to feel loved and understood by people they love, and they will heal. Other people though? Some are just inherently miserable. And I frankly think it's absurd to ostracize people for their inherent demeanour and character. Likewise, I think it's awful that venting is weaponized and moralized by others, as though it's evidence of negative character traits. Being anti-venting—and being pro-snark or pro-gossip—these too are just other unhealthy modalities of catharsis, and mechanisms for dealing with our own mental health. You are not "better" than someone who vents if you do not. You are not "better" if you have figured out healthier ways to deal with your shit. People are just people. Some of us have lost the ability to look outward, and others to look inward. If you don't have the capacity to be around people who vent, that's understandable, and it's within your right and similarly good to be able to articulate and express your boundaries. But I'm not one of those people. I would always rather someone vent to me than bottle it up, or far worse, going to a genAI chatbot to vent instead. That's why I've been a volunteer on 7cups for so long.

Quaker Quest is a social media site for Quakers or Quaker-adjacent folk on the fediverse. It's a community where you can be with other Friends, while interacting and messaging with others beyond this site. You may be interested in "A friendly introduction to the fediverse" to learn more.

Menopause saved my life. I'm kind of tired of writing about my suicidal ideation, but even when I have moved past it, it still feels like shelter. Like wi...

A week ago, when I was working on my project for HTML Day 2026 I stumbled upon this passage from an essay on `blink` and `marquee` tags: > At the time, there was a new breed of web professionals proudly labeled “webmasters.” Part designer, part developer and part evangelist, webmasters held enough esoteric knowledge about the web to manage, edit and create websites, both large and small. > — Jay Hoffman (August 28th, 2017) And that's when everything clicked for me. Over the past year, I've written dozens of articles on the Independent Web. Forty-two essays on principles, technical tutorials, accessibility, and advocacy. And, in a way, it has all been leading to this manifesto. Only through months of research and getting to know many kind and talented people and building things myself have I finally understood the true power of the webmaster. I think this will be the most important thing I'll ever write, and I wish to share it with you. With everyone. ## Part One: THE PAST The earliest webmasters were unauthorized, self-taught, one-person operations. The first webmaster was a woman, Stanford librarian Louise Addis. ### i. ORIGINS (1993) It was a few years after Tim Berners-Lee christened the first web server at CERN at the end of 1990, and published the first website `info.cern.ch` on August 6th, 1991[1]. The webmaster was first understood as the Internet's equivalent to the real-world postmaster. > "Other protocols have defacto standards for well known mailbox names, such as USENET@domain for NNTP (see [RFC977]), and WEBMASTER@domain for HTTP (see [HTTP])." > — RFC 2142, "Mailbox Names for Common Services, Roles and Functions," Dave Crocker, Internet Mail Consortium. (May 1997) This RFC—alongside `<POSTMASTER@domain>` (required by RFC 822)—is what cemented "webmaster" as the canonical, protocol-level point-of-contact role for a website. > "The word “webmaster” comes from a similar role defined in the original specification for email called the postmaster, which in turn comes from the similarly named government position Postmaster General. You can think of the postmaster as an email administrator. The idea being that you can email postmater[sic] @ some domain, and always be connected directly to somebody that could fix a problem with the email. That remains a reserved name today on any email inbox. The webmaster served a pretty similar purpose on the web." > — Jay Hoffman, "What Happened to the Webmaster" (June 16, 2020) And thus, `webmaster@domain` was already the de facto email inbox address tied to the HTTP protocol itself. The label and title quickly grew into something far more than that, though. > "At first it referred to that frustrated techie who set up the rogue Web server without company authorization, coded HTML by hand in a text editor, FTP'd the files to the server, and in his spare time answered all the incoming corporate e-mails, usually also without company authorization." > — Brian Wold, "What Happened to the Webmaster? (And other misleading titles)" (May 12, 2006) ### ii. GOLDEN AGE (1994-2001) The era that conjures "webmaster" most strongly began in the mid 90's, as Beverly Hills Internet was launched, now known as GeoCities. > "[T]he point about the web before social networks or before Web 2.0 is not that you had a profile on GeoCities, but that you had a chance to build your cyber home outside of it, you could exist and grow outside of a centralized service." > — Olia Lialina, quoted in Cybercultural by Richard MacManus (March 7, 2025) A culture developed as people realized anybody could make their own website. 88x31 buttons, blinkies, .GIFs, web rings, visitor counters, guestbooks. All originate from this time. > "In 1996, the web was littered with black-and-yellow-striped animated .gifs reveling in metaphors of road construction... 'This site under construction' was the default home page disclaimer, until everyone realized that the inherent nature of the web was that it would be perpetually under construction." > — _Fresher Styles for Web Designers_, O'Reilly (December 2008) While GeoCities is fondly remembered now, it certainly had its problems and issues. Similarly, there were other platforms at the time as well, such as Tripod, Angelfire, and Homestead. It can be easy to revise history into an idealized monoculture. > "It was not a paradise for early web makers. It was not even a good web hosting service. It was free and not worse than others, that's why webmasters endured the pain of clumsy page builders, interventions from commercial scripts being injected into their pages, accidental file deletions, etc…" > — "GeoCities' Afterlife and Web History," by Olia Lialin, One Terabyte of Kilobyte Age (July 30, 2019) Over 38 million pages were deleted when Yahoo shut down the platform in 2009. ### iii. THE DECLINE (2008-2020) As sites grew and the Internet evolved from the expectation of a handful of HTML files located in `/var/www/html/` into instead a complex beast of software and content management systems, the "one person does everything" model stopped being the default, and the title became a culture-war topic among web professionals. Schisms grew from the complexity. The Internet became a vector for business, and then _the_ way to make money as the dotcom bubble inflated. People needed to specialize, whether that was to design for the front-end, or program and administrate the server from the back-end. You needed usability specialists and network engineers and search engine optimizers. > Dammit Jim, I’m a Webmaster, not a Digital Government Web Content Communications and Application Development Knowledge Management Specialist! ...or am I? > Is the term webmaster an accurate description of the responsibilities of today’s web professional, or is that moniker just a quaint artifact from the simpler, earliest days of the web where someone akin to a similarly quaint notion of a Ringmaster juggled a circus of unwieldy text, spinning logos and blinking text? > — David Kitzmiller, FCC Webmaster, Mastering the Web: An Old-Fashioned Notion? (August 12, 2010) Perhaps the clearest and most citable marker of the term's formal retirement from mainstream professional use is when Google rebranded "Google Webmasters" to "Google Search Central" in 2020. An institutional funeral. > "Merriam-Webster claims the first known use of the word 'webmaster' was in 1993, years before Google even existed. However, the term is becoming archaic, and according to the data found in books, its use is in sharp decline. A user experience study we ran revealed that very few web professionals identify themselves as webmasters anymore. They're more likely to call themselves Search Engine Optimizer (SEO), online marketer, blogger, web developer, or site owner, but very few 'webmasters.' In brainstorming our new name, we realized that there's not one term that perfectly summarizes the work people do on websites." > — Google Search Central Blog (Nov 12, 2020) * * * ## Part Two: NOW It is your innate human right to create. All of the above was pretext for this: **You can be a webmaster right now.** You can create a website right now. Yes, you. Your website can look however you want it to, and function in any way you want. It can have whatever you want on it. You can look up tutorials, and you can have your questions answered by humans just by joining forums, IRC channels, and independent platforms. The act of creating and learning inherently places you in the community. ### prelude: The Deception Generally speaking, we have been deceived into thinking many broad falsehoods: Regarding the webmaster: 1. The Internet has become too complex for a single person to master all aspects of it. 2. You must use a certain tool or platform to properly be part of this movement. Regarding the Internet: 1. Technology is inherently addictive, and brings us harm. 2. In order to stay connected to others online, we must use corporate social media platforms, become the product, and surrender our privacy. 3. The Internet is primarily falsehoods, misinformation, and meaningless spam content. Regarding us: 1. Most of us are incapable of learning technical, scientific, mathematical concepts. 2. Those of us who are knowledgeable are reluctant to share information, and hostile to beginners. When plainly laid out like this, it's easy to see how we've been conned into a cynical, pessimistic—even misanthropic view of things. Companies worth billions of dollars have a bottom line that depends on the general population to continue believing all of the above. Our perspective on technology and other people has been greatly distorted into the negative. In reality, the Internet has terabytes of high-quality resources to learn from. There are thousands of people just like you looking for connection, hungry for a better vision of the future, wanting to cultivate nourishing hobbies. You are so capable. The idea that one person cannot master all aspects of the web, as the webmaster was once known to, is demonstrably false. Be optimistic about your capabilities and the willingness of others to help you. Be skeptical of anybody who attempts to divide or gatekeep, proclaiming the mandated use or superiority of a specific tool or platform. Likewise, I want to note that searching for "return of the webmaster" in 2026 may lead you to discussions of the "agentic web" or "orchestration," a euphemism for somebody who employs generative AI to do the multidisciplinary work that comes with being a webmaster. Those who manage a stack of expensive large language models, those who are prompt engineers for static site generators, and those who neglect to take the time to learn for themselves, unwilling to put in the effort themselves (or thinking they're incapable to). That's not what this is. My manifesto is not about becoming an orchestrator. Being a webmaster means **becoming a sovereign creator.** We are not reclaiming the title of "webmaster" only to then offload the work and art onto chatbots. We are reclaiming it because it is the only title that remains which still carries the weight of total, unapologetic human agency over our digital lives. ### a. The Bare Minimum is All You Need To be a Webmaster, you need a computer, a text editor, and a way to host. That's it. You don't need a degree in computer science. You don't need a $50/month subscription to a proprietary builder. You don't even need the money to buy a domain name if you don't have the cash. 1. Use https://freedns.afraid.org/ to get a free domain. 2. Throw your files up on Neocities or Nekoweb or web 1.0 hosting. 3. Write your HTML in Notepad. Edit your CSS in TextEdit. If you don't have a computer or Internet yourself, you could be sitting in a public library on a recycled Chromium machine and still you have everything you need to become a Webmaster. There are not gatekeepers at the doors of the World Wide Web. Like many other things in life, the only lock is the one we put on our own ambitions. A Webmaster is not just a developer. You are a UX/UI designer, you are a writer and editor, you are an accessibility specialist, and an advocate for others to reclaim their digital autonomy. You are a creator, rather than a consumer. And you are capable of all these things. You will wrestle with semantic markup to make a page accessible. You will agonize over typeface kerning and colour palettes. You will write prose and publish your weird obsessions and link to your Internet neighbours. You will manage server logs, tweak the `.htaccess` file, and you will decide and design the architecture of your digital home. This is not a career path, this is a craft. This is the last best multidisciplinary sandbox, both creative and technical, all rendered on an `index.html`. And **there is no wrong answer.** Serve your website over the Gemini protocol. SSH into the Tildeverse and build a terminal-based homepage alongside strangers. Set up a homelab in your closet using the old, defunct family computer. There are a million ways to do this. The only wrong answer is sitting on the sidelines believing you don't belong in the arena with us. ### b. The Last Public Square Corporate social media platforms we used to call the "new public square" have been astroturf'd, bulldozed, and sold to the highest-bidding fascist oligarch. Your existence is a rental, your voice is a throttled lottery. Your so-called "community" is at the mercy of a billionaire's whim. Building your own website is an act of digital repatriation. Creating your own corner of the Internet reclaims one of the only mediums where we retain freedom, creativity, and autonomy. With the plethora of hosting options available, you can migrate if terms of service change to your disliking. There's no pay-to-play visibility. There's just you, text, and the open protocols of the web. ### c. The Myth of Incompetence The most effective way the power structures of our age have oppressed us is by making us feel as though we are stupid, as though we are incapable of learning. Many of us have been convinced coding is arcane magic, that servers are eldritch horrors, and that computer science is reserved for child prodigies and those who are privileged to just "naturally get it." A user who is afraid of the machine and doubts their own capabilities is one that will surrender and pay for a solution. You are not incapable. There is a lot to learn, yes. And the technologies are deep. But do not forget we are still living in the golden age of human knowledge—endless free resources, tutorials, wikis, and forums are available at your fingertips. I will repeat myself and say the only barrier that exists is the one you construct in your mind. You require grit, determination, and a "why." **This is your why.** The desire to express yourself. The hunger to build something truly of your own. The need to connect with other humans. ### d. Universalism Let me be clear: this is not about "IndieWeb" specs, it isn't about the "Small Web" or "SmolWeb." It isn't a retro-revival nostalgia trip, pining for GeoCities and AOL dial-up tones. Those are all labels, clubs, and memberships. Standards with elitism and in-group and cliques and gatekeeping as a result. What I'm talking about is universal. It's not about specific mechanics, it's about a philosophy. It is a big tent. It doesn't matter if you speak English. It doesn't matter if you don't know how to spell words right in your native tongue. It doesn't matter if you don't know a single line of JavaScript, either. And it certainly doesn't matter if you think you have "nothing interesting to say." I promise you do. All humans have value, we have our hobbies, our frustrations, our obsessions and small thoughts. Putting this in writing on a page you build with your own hands means you're contributing to a richer, stranger, more wonderful ecosystem. ### e. Those Who Came Before I stand on the shoulders of giants. I am not the first to write a web manifesto, nor the last. I myself am nobody special, nor anybody with authority. I am mere conduit for a message that desperately needs to be heard. I give credit to Tantek Çelik, Amber Case, Aaron Parecki, Crystal Beasley, and Kevin Marks for founding **IndieWebCamp** in Portland, Oregon in 2011. I give credit to Daniel Murray's **melonking.net** as a foundational "web revival" artifact. > "[The web revival] is a riff on the 20th century American folk music revival, and it implies that early personal sites, like those hosted on GeoCities, were culturally significant as digital folk art." > — Daniel Murray (Melonking), quoted in New_ Public (September 7, 2025) I give credit to webmistress **Sadness**, who has been sharing resources on web mastery for years, and was the founder of the now defunct Yesterweb, served as many people's first experience of the indie-web-crafting scene. > "In the earlier iterations of this manifesto, I made the mistake of focusing too heavily on the creation of personal websites as the main method of fighting against the exploitative capitalist hellscape that has become our Internet... For example, we can work on transforming social relations online." > — Sadness, Internet manifesto (May 2023) I give credit to **James G.**, who has been blogging about the independent Internet for over six years, who hosts the podcast Wonders of Webweaving, and who has recently founded the Web Writers' Collective, which is open to anyone. I give credit to Alexandra and Kaylee for the community and resources of 32-bit Café. I give credit to Adam Newbold for the community and services of omg.lol. There are hundreds of people who have dedicated thousands of hours in trying to make the web more human and joyous for all. ### f. Saving the World We can create a more human web right now. The world is in dire straits, and I'm reminded of the words of Carl Sagan, coincidentally written at the dawn of the webmaster: > “In our obscurity, in all this vastness, there is no hint that help will come from elsewhere to save us from ourselves.” > — Carl Sagan, Pale Blue Dot (1994) There are those who see the act of webmastery as "only" a hobby and pastime—and I say this is not mutually exclusive to world-saving. The personal is political. Our ability to maintain our joy and ourselves is, itself, resistance. Here is another falsehood I want to emphasize: **Our right to freely express ourselves is never a guarantee.** The past thirty years of the Internet have been an explosive, chaotic experiment in the commons and the human condition. But the freedom of expression we've been granted is not a given or perpetual promise, and it is extremely foolish to think we will have this for the next ten years, let alone forever. Start as you are, with what you have, while you still have time to do so. Exercise your innate human right to create. Be a developer. Be a designer. Be a writer. Be a systems administrator. Be a philosopher. Be a Webmaster. It is the most punk rock, anti-establishment, liberating thing you can do in the 21st century. And yeah, it is fucking awesome. Now, go build something. * * * ## FURTHER RESOURCES ### Getting Started * Sadness' Webmastery Resources * 32-bit Café Community Resources * IndieWeb: Getting Started: The step-by-step guide to getting your own site on the IndieWeb, covering domains, hosting, and creating pages * IndieWebify.Me: Step-by-step guidance and tools to test and validate your IndieWeb progress * MDN Web Docs: HTML Tutorial: Mozilla's HTML documentation and tutorials * HTML Dog: A classic starting point for HTML and CSS tutorials * W3Schools: Free coding tutorials for HTML, CSS, JavaScript, and more * Zonelets: A lightweight blogging engine letting you write posts directly in HTML * Neocities Template Tool: A simple three-column template for Neocities and other simple site hosts * The Boilerplate: Ransei's starter template with drag-and-drop upload instructions for Neocities * Stefan Bohacek: Making a free image gallery with Neocities.org: Tutorials for creating image galleries with Neocities, including an 11ty version * Susam Pal: Writing First, Tooling Second: A manifesto advocating for prioritizing content in simple HTML before complex tooling ### Hosting * Neocities: Free, user-friendly hosting for handmade websites * Nekoweb: Another free hosting option for personal sites * FreeDNS: Get a free domain name * omg.lol: Community and services from Adam Newbold and Neatnik * Bear Blog: A minimalist, privacy-focused blogging platform * Micro.blog: Indie microblogging with built-in cross-posting * Dreamwidth: An open-source blogging and community platform * Codeberg Pages: Free static site hosting directly from Codeberg repositories ### Web Revival Communities * MelonLand Wiki: Communities: A directory of web revival communities, forums, and message boards including 32Bit Cafe, Pixel Joint, Basement Community, Comfybox, The Midnight Pub, Pixel Lounge, The Web Raft, and Reject Convenience * Sheezy.Art: An art website recreating the highs of pre-2010 DeviantArt and SheezyArt * SpaceHey: A retro social network focused on privacy and customizability; a MySpace experience * Bitview: A video sharing site inspired by classic YouTube * Sudomemo: A revival of Flipnote Hatena with community features * Ytoo.org: A web revival community hub * Elpis.ws: Another web revival space ### Building * Sadgrl's 88x31 Button Maker: Create your own classic web button * Hekate's 88x31 Button Maker: Another excellent button generator * IndieWeb's 88x31 page: More generators plus how to hand-code your own buttons * Dither It: Make dithered images for a retro aesthetic * JS Paint: Classic MS Paint in your browser * JummBox: Chiptune-style music program for the browser * Online Color Picker: Tools for choosing and testing color palettes * Josh W. Comeau: CSS Interactive Guide to Grid: An excellent interactive CSS Grid tutorial ### Webrings & Directories * Archive Team: Webring Directory: A list of live niche webrings * Brisray's Webring List: A hand-verified list of currently working webrings * 32-Bit Cafe Webring Directory: Active webrings created by 32-Bit Cafe members * MelonLand Surf Club: An active webring with over 1,500 sites * The Smallweb Subway: A subway-style network of webrings mapping themed communities * XXIIVV Webring: An open-source initiative fostering independent personal websites * Fediring: A webring for the Fediverse * A11y Webring: A webring focused on accessibility * Low Tech Webring Directory: A directory of low-tech webrings * Fandom Webring: A general fandom webring * Transing the Internet: A trans webring with a small Discord community * HandCraftedWeb.eu: A curated, decentralized directory and webring for the "Human Web" ### Manifestos * Yesterweb's Collection of Web Manifestos: An excellent collection of manifestos written by others. * The Yesterweb Zine: collaborative zine that ran from Aug 2021 to Jan 2023 * Issue 00, "The Old Web" * Issue 02, "Websites as an Act of Creativity" * IndieWeb's "Why" page: Another list of personal-site manifestos from 1997 to 2026 * Melonking's Manifesto * A Quiet Manifesto: On text, tech, caring, the importance of existing, and cave paintings * Tracy Durnell: Guiding principles for my website: Principles including being friendly, respecting privacy, prioritizing connection over reach, and practicing imperfection * New_Public: The Handmade Internet Is Making a Comeback: A 2025 article on the web revival movement ### Archives * Wayback Machine: The Internet Archive's indispensable tool for viewing historical versions of websites * Wayback Machine Downloader: Download an entire website from the Wayback Machine * Flashpoint Archive: Preserves games and animations from the web * Escargot: A service that makes old versions of MSN Messenger and Windows Live Messenger work again * Neonaut's Cyber Mausoleum: On leaving a digital tombstone ### Searching * Wiby: A search engine for the classic web, prioritizing non-commercial content * Marginalia Search: A search engine that prioritizes non-commercial content and personal websites * Smallweb.cc: A curated collection of websites * Cloudhiker: Another selection of websites ### History * The History of the Web: An excellent collection of essays that inspired this post. * Web Design Museum: A timeline of milestones in the history of web design from 1990 to the present. * SLAC's archive of the first U.S. website built by Addis and Paul Kunz, December 1991 ## My Other IndieWeb Essays Over the past year I've written forty-two essays on this subject. Here are the ones I think are most worth a beginner's time. ### Starting Out * What I Have Learned Being on the IndieWeb for a Month: Small technical joys that turned solitude into dialogue, and treating the Internet like a personal playground and lab. * Resources for the Personal Web: A Follow-Up Guide: Blogging platforms, search engines that prioritize small sites, and directories for finding like-minded creators. * Softcore First, Hardcore Eventually: A Ladder for the IndieWeb: Why you should climb the rungs progressively instead of choosing between easy platforms and full technical independence on day one. * The 1% Rule: An Open Letter to Everyone Who Doesn't Post Anything Online: A call to action for the 99% of internet users who consume but never create. * You Don't Have to Blog: Your website can be shrines, art, or anything else. You don't need to write a single word to belong here. ### Community and Connection * Won't You Be My Neighbour?: On mycorrhizal networks, Indra's Net, and the importance of building intentional connections between independent websites. * Yes, Buy Them a Coffee: Support and Mutual Aid on the IndieWeb: Asking for support isn't commodification, it's mutual aid. * The Internet Needs More Cross-Pollinators: We need people who move between different online subcultures to seed ideas and build bridges. * The IndieWeb is Wonderfully Dionysian: A plea to write your own comments, from the heart, instead of letting genAI do it for you. ### Building It Yourself * Building an IndieAuth Comment System for Your Static Site: How to build a comment system for your static site using IndieAuth and Netlify Functions. * How Webmentions Work on brennan.day: A tutorial and walkthrough of implementing webmentions, from setup to display. * Why Make Your Website Accessible, Anyways?: Web accessibility isn't compliance theatre, it's about designing for everyone. * Phoneblogging: Why the IndieWeb must prioritize accessible, simple ways to blog from a phone. ### The Bigger Picture * Building the Good Web: What do we owe each other, and what's the distance between knowing something is wrong and doing something about it? * Trust and Faith in Our Web: What is trust in an AI-saturated internet, and how do we make independent web spaces more accessible? * Good, Standard Work: Creating the Commons: From Garrett Hardin's tragedy of the commons to Elinor Ostrom's refutation, the commons was never inevitable to fail. It was always a choice. * How Are We Preparing for the Long Web?: Digital preservation, link rot, and building for the Internet decades from now. * Free Speech and the IndieWeb: Not all harm is equal, and where we draw the lines in the sand for what's acceptable. * * * 1. You will find claims that "webmaster" originated from CERN itself across SEO and marketing blogs, but this is mere folk etymology I couldn't independently verify. Multiple independent lexicographic sources mark 1993 as the first attested year of the webmaster, such as the OED and Etymonline. ↩︎

Create and surf awesome websites for free.