Skip to content

The Websites We Deserve

Our lives run on websites. From banking apps to recipe notes, we have entrusted the web with virtually everything we care about. In exchange for our trust, the creators of the internet made us a promise: if you want to, you can create your own website and put it on the internet.

Sam Littlefair
Sep 29, 20266 min read

September 29, 2026

Our lives run on websites. From banking apps to recipe notes, we have entrusted the web with virtually everything we care about. In exchange for our trust, the creators of the internet made us a promise: if you want to, you can create your own website and put it on the internet.

But that hasn't really turned out to be true. We create data on the internet every day — in the form of Google Docs and Instagram posts and calendar invites — but we rely on large corporations to create and store virtually all of that information. No one takes the alternative path — doing it themselves — because making websites is difficult or expensive, and often both.

If you want to pay a corporation to build and manage your website for you, it'll cost you at least $100/year.

On the other hand, if you do it yourself, you can publish a website for as little as $5/year*, but you will need an adept understanding of networking protocols and at least two programming knowledges.

We are missing the in-between piece: a tool that makes it easy to publish your own website. I think we deserve that tool. We deserve a tool that fulfills the promise of the web:

  • Sovereignty
  • Portability
  • Compatibility
  • Privacy
  • Creativity
  • Community
  • Inclusivity
  • Stability

I spent about fifteen years waiting for someone to create that tool. Then, two years ago, I decided to make it myself. That's how Vowel was born. It's a website generator based on standard practices and common assumptions:

  • A markdown file is a webpage
  • home.md is your homepage
  • If the page starts with a # heading, that's the page title
  • If there is a date at the start of the page, that's the page's date
  • Pages with dates should appear in an RSS feed
  • Pages without dates should appear in the website menus
  • Every page should have three navs:
    • A global nav that shows all important pages
    • A local nav that shows siblings and close relatives
    • A breadcrumb nav that shows ancestors
  • The active page should be identified in the navs
  • If there is a #hashtag in the page, there should be a /tag/hashtag page
  • If there are headings in the page, there should be a linked list of the headings
  • All common markdown conventions should render as expected
  • A lone URL (https://example.com) should render a thumbnail
  • A lone relative path (/blog/hello-world) should render a thumbnail
  • A lone glob pattern (/blog/*) should render a list of thumbnails
  • An image ([cat](cat.jpeg)) should be optimized
  • A styles.css file should style everything in its folder
  • Basic CSS boilerplates (including reset and typography) should be available
  • No one should need to write an HTML boilerplate
  • In fact, no one should need to write any templates whatsoever
  • A relative path (./hello-world.md) should resolve to the published path (/blog/hello-world)
  • A page should list its incoming links
  • a 404.md file should be the 404 page
  • In lieu of a breadcrumb property, the file name should be the breadcrumb
  • All pages should appear in a sitemap
  • The sitemap, RSS feed, and post lists should omit pages that are hidden
  • The site should have a robots.txt that the author can customize
  • The site should be performant and accessible

Some of these rules, such as what pages appear in menus, should have overrides. Other rules, such as how to create a 404 page, probably should not have overrides.

Vowel also tries to anticipate user needs by offering some useful features:

  • If the website has an atproto_did and atproto_lexicon, Vowel will publish conforming pages on AT Protocol
  • A user can add a hash salt to a file or folder name (/blog/secret##fuzzy-jog/hello-world.md) to hash that URL segment (/blog/<hash>/hello-world) and hide that section of the website
  • A glob pattern accepts standard query and formatting parameters (/blog/*?limit=10&view=table)

On the Vowel roadmap, I have plans to publish more common data formats:

  • *.ics (calendar)
  • *.epub (ebook)
  • *.md (AI-friendly)
  • podcast.xml (podcast feed)
  • llms.txt (AI instructions)

These features will be opt-in globally or per-folder via a settings.md file.

Outside of these assumptions, Vowel defaults to simplicity and permissiveness. A date set to December 32 2026 should fail, but a date set to December 31 2226 should pass. Vowel attempts to render websites in any shape, whether the file is nested forty folders deep or one folder has 4000 files. Vowel also blocks escape hatches and overrides like custom templates and script tags. All pages have the same template and minimal JavaScript (for now, minimal means none, though that could change if needed for something like client-side search).

Vowel accomplishes all of this with common conventions and human-readable data formats.

Moreover, Vowel does all of this very quickly. I am targeting cold starts under one second and warm starts and live-reloads under 100ms. Vowel renders so quickly that the webpage preview that you see on localhost is actually just your production-ready .html file. When you run the publish command, the HTML is ready to go and Vowel just sends it all to Cloudflare.

Vowel manages this speed by caching file data and dependencies in an SQLite database and saving fetched data to the file system. So far, Vowel seems to hit the targets up to 1000 pages, though I need to do more testing to see how well it works for websites with large volumes of pages, which is important if Vowel is going to handle large repositories like social media profiles or Zettlekasten projects.

Where does it stand? After writing two prototypes, I decided to write my own compiler to bundle Vowel. Last year I wrote Votive, a general-purpose file handler with caching and a dependency graph. Then I wrote Vowel as a Votive plugin.

Over the past month, I have been using Claude to stress-test Votive and Vowel and they have held up surprisingly well. I've added a number of features and improvements over the past week that are currently distributed under the beta tag on npm. I am developing Vowel as a CLI, but I plan to package it as a Desktop app with a WYSIWYG editor in the near future.

Most importantly, I've been using Vowel myself, and it feels like the website builder I've always wanted. I'm hopeful that maybe it can become the website builder we deserve.

*That's the price of the most affordable domain renewals and assumes free hosting on a service like Cloudflare.

Did you enjoy this article?

Recommend it — Standard Reader surfaces well-loved writing to more readers across the network.

Across the AtmosphereDiscussions