The static renaissance — Markdown, static site generators, Gemini protocol
The application web that the previous part of this book described — JavaScript-heavy, framework-driven, server-mediated, platform-embedded — produced, by the mid-2010s, a counter-movement among web developers and writers who wanted something less. The counter-movement has been called the static renaissance, the Jamstack revival, the small web, the slow web, depending on which sub-community is speaking. Its various subgroups disagree about specifics, but they share a basic stance: that the web’s complexity has grown out of proportion to what most web pages need, that a generation of basic publishing has been swallowed by the application-platform model when it did not need to be, and that the appropriate response is a deliberate retreat back toward simpler tools, simpler protocols, and a more direct relationship between the writer and the page. The retreat has produced Markdown, the static site generator ecosystem, the Gemini protocol, a small but growing community of “smol web” projects, and a renewed culture of personal publishing that bears more resemblance to the web of 1997 than to the web of 2017. This chapter is about what the static renaissance has produced, why, and what its limits are.
Markdown
The substrate of the static renaissance is Markdown, created by John Gruber with input from Aaron Swartz in 2004. Markdown is a plain-text formatting syntax that uses light, mostly-invisible punctuation to indicate document structure: asterisks for emphasis, hash marks for headings, square brackets and parentheses for links, hyphens for lists. The design goal Gruber stated in his original specification was that a Markdown document should read like plain text, with the formatting being intelligible to a human reader without any parser. The syntax was, accordingly, kept light: most readers can read a Markdown document and understand the formatting without having seen the conversion to HTML.
Markdown’s adoption has been one of the quieter successes of the past two decades. The format is, by 2026, the dominant lightweight formatting language across a wide range of tools: README files on GitHub, GitLab, and Bitbucket; notes in Obsidian, Notion (partial), Bear, and most modern note-taking apps; technical documentation; static-site source files; chat messages on Slack, Discord, and Microsoft Teams; comments on Stack Overflow, Reddit, and various forums; and many other contexts. The format is not standardized in a strict sense — there are multiple Markdown variants, with different extensions and edge cases — but the CommonMark specification, released in 2014 by Jeff Atwood, John MacFarlane, and others, has provided a common baseline that most implementations now follow.
The cultural significance of Markdown’s spread is that it has recovered, for the writing layer of the web, the property of plain-text portability. A Markdown document is a text file. It can be read by any text editor. It can be edited by any text editor. It can be saved on any machine, in any directory, in any storage medium that supports text files. The format does not depend on any particular application’s continued existence. A user who writes in Markdown owns their text in the strong sense that HyperCard users had owned their stacks: as files, on their disks, in a format they can read regardless of what happens to the tools they used to make them.
This is, in retrospect, a non-trivial recovery. The platform decade had moved most writing into the proprietary back-ends of various services: Google Docs, Notion, Evernote, the various social-media platforms. The data was held by the platform; the format was proprietary; the user’s access to their writing was contingent on the platform’s continued existence and continued willingness to provide the service. Markdown has not displaced these tools, but it has provided an alternative for the users who want one, and the alternative has been adopted widely enough that it has become a stable cultural fact rather than a niche preference.
Static site generators
The next layer of the static renaissance is the static site generator. A static site generator is a tool that takes source files (usually Markdown for content, plus various configuration and template files) and produces a directory of HTML files, ready to be served by any web server. The output is, by construction, static: there is no application logic at serve time, no database, no JavaScript needed to render the basic content, no server-side rendering on each request. The pages are HTML files that the web server serves directly.
The pattern is old. Early web sites were, by default, static files. The dynamic-application web replaced this with database-backed content management systems through the late 1990s and 2000s, and the static-files pattern fell out of fashion. The revival began around 2008 with Jekyll, written by Tom Preston-Werner (a GitHub co-founder), which combined Markdown content with Liquid templates and a build step to produce static sites. Jekyll’s adoption was accelerated by GitHub’s introduction of GitHub Pages in 2008, which provided free hosting for static sites built from GitHub repositories. The combination of Jekyll plus GitHub Pages plus Markdown content gave individual developers a frictionless way to publish a personal site, and the pattern spread quickly through the developer community.
The static-site-generator ecosystem grew through the 2010s. Octopress (2011) was a Jekyll wrapper aimed at non-developers. Hugo (2013), written in Go by Steve Francia, was a substantially faster generator that could process large sites in seconds rather than minutes. Hexo, Pelican, Middleman, Nikola, and various others occupied adjacent niches. Eleventy (2017) provided a more flexible JavaScript-based alternative. mdBook (the system this book is written in) provided a generator specifically for documentation and books. The various generators differ in their template languages, their performance characteristics, and their cultural preferences, but they share the basic pattern: source files in, static HTML out.
A natural extension of the static-site pattern came with what was, in the mid-2010s, called the Jamstack: JavaScript, APIs, and Markup. The Jamstack idea was that a static site could still have dynamic features by adding JavaScript that called external APIs from the browser. The static HTML would be the substrate; the dynamic features would be layered on top through JavaScript and third-party services for the dynamic parts (forms, comments, search, authentication). The pattern was popularized by Netlify (founded in 2014, with the term “Jamstack” coined around 2015), which provided a hosting service tailored to this architecture, with build automation, deploy previews, and integrated APIs for the common dynamic features.
The Jamstack approach has been, depending on perspective, either a real recovery of the static pattern with practical extensions or a slippery slope back into the application-web complexity it was supposed to escape. In practice it has been both: many Jamstack sites are simple personal sites with one or two minor dynamic features; others are full applications with extensive client-side JavaScript that incidentally use static HTML for their initial render. The boundary between Jamstack and application-web has, since 2018 or so, blurred substantially.
The hosting platforms
The static-renaissance hosting platforms — GitHub Pages, Netlify, Vercel, Cloudflare Pages — have been a significant enabling factor. Each provides free or low-cost hosting for static sites, with continuous deployment from Git repositories, custom domains, HTTPS, and various other amenities. The combination has made it cheap and easy to run a static site, to the point where a developer can set up a personal site in an hour and have it live on a custom domain with TLS within minutes after the first commit.
The hosting platforms have their own consolidation issues. Each is operated by a specific company with its own commercial interests; the platforms can change their pricing, their policies, or their products; a static site hosted on Netlify is, in a meaningful sense, hosted by Netlify, with all the platform-dependency that implies. The static-renaissance ethos of “you own your site” is somewhat undermined when “you own your site” means “your site lives on Vercel until Vercel decides otherwise.” The site’s source files are portable; the operational dependency is on the hosting platform.
The dependency is partial. A static site’s source can be hosted on any static-file server; the platforms provide convenience and amenity rather than essential infrastructure. A user who moved from Netlify to a different host could do so relatively easily. The portability is a real property, even if most users do not exercise it. But the consolidation of static hosting into a small number of platforms is a quiet pattern that parallels, at a smaller scale, the broader platform consolidation discussed in chapter nineteen.
The Gemini protocol
The most ambitious recovery in the static renaissance is the Gemini protocol, designed by a developer known by the pseudonym Solderpunk beginning in 2019. Gemini is a deliberate retreat from the web. It is not a layer on top of the web; it is an alternative protocol that runs over its own port (1965 by default), with its own document format (gemtext), its own URL scheme (gemini://), and its own clients. Gemini is, in its design intent, a Goldilocks protocol: more capable than Gopher but much less capable than the web, with the lower complexity ceiling being a deliberate constraint.
Gemini’s specification fits in a few pages. Requests are a single line: the URL of the requested resource, followed by a carriage return and line feed. Responses begin with a two-digit status code, a space, optional metadata, and the response body. The body is, for documents, gemtext: a plain-text format with a small number of formatting conventions (lines starting with # are headings, lines starting with > are quotes, lines starting with => are links, lines starting with ``` open or close preformatted text). The protocol requires TLS for all connections; there is no unencrypted Gemini. The protocol does not have cookies, scripts, or any of the various features that the web has accumulated. The protocol is, structurally, a hard ceiling on what Gemini can do, by design.
The Gemini community is small. There are perhaps a few thousand Gemini servers (called “capsules” in Gemini terminology) operating in 2026, with a total user base in the low tens of thousands. The content is dominated by personal blogs, journals, philosophical writing, technical notes, and the kind of thoughtful long-form material that Gemini’s aesthetic encourages. The community’s voice is articulate, often political, and deliberate about what it has chosen to retreat from. The most visible Gemini sites — at the time of writing the SourceHut Gemini portal, various individual capsules, the gemini.circumlunar.space hub — provide a real working alternative to the web for the small audience that cares about it.
The Gemini protocol has not, and is not intended to, replace the web. The community’s position is that the web is too big, too complicated, and too commercialized to be reformed; the alternative is to step away from it, into a smaller and quieter network that has been designed to remain simple. The reasoning has both technical and political components: technically, that simple protocols are more resistant to commercialization and to the kind of complexity escalation that the web has experienced; politically, that a community that controls its own infrastructure can maintain values that the broader web cannot.
The Gemini community has its critics, including from within the broader small-web movement. Some have argued that Gemini’s hard simplicity ceiling is too restrictive — that the lack of inline images, of richer link types, of even basic dynamic features makes the protocol unsuitable for many uses that simple HTML could handle without committing to the full complexity of the modern web. Some have argued that Gemini’s separation from the web is a kind of secession that limits its reach to people willing to install dedicated clients. The arguments are real and the Gemini community responds to them with the position that the trade-offs are deliberate. The community is not trying to be the next web; it is trying to be a different thing.
The longer trajectory of the static renaissance
The static renaissance has been growing slowly and steadily through the past decade. Some of its specific markers:
The IndieWeb’s “you should have a website” position has reached a wider audience. The number of personal websites in 2026 is, by various estimates, growing for the first time in many years, after a long period of decline during which writing migrated to platforms. The cultural turn toward personal sites has been visible in the various “blogroll” revivals, the renewed interest in RSS feeds, the various commentary about the relative quality of personal sites versus platform content.
Static site generators have become a default for technical documentation. Many open-source projects, many companies, many academic groups use static-site-generator-based documentation as their primary publication mechanism. The pattern is, in this domain, dominant.
The “small web” community — a constellation that includes Gemini participants, IndieWeb practitioners, personal-site enthusiasts, and various others — has acquired a sense of itself as a community. The terminology, the conventions, the events, and the sense of shared purpose have grown to the point where the community is a recognizable participant in the broader conversation about what the web should be.
Substack and Ghost and other independent publishing platforms — while not strictly static in the renaissance sense — have provided a path for writers who want something between a platform and a full personal site. Substack in particular, founded in 2017 and growing through the 2020s, has been a substantial venue for writers who want to publish independently with platform-like distribution. The Substack model has its own issues, particularly around the platform’s commercial interests and its decisions about which content to support, but it has been part of the broader cultural shift toward more independent publishing.
What the static renaissance is responding to
The static renaissance is, at its core, a response to a set of specific problems with the contemporary web. It is worth being explicit about what those problems are.
Web bloat. Modern web pages are, by historical standards, extraordinarily large. A typical web page in 2026 downloads several megabytes of JavaScript, CSS, fonts, and trackers before showing the user any content. Pages that consist primarily of a single article of a few thousand words routinely require tens of network requests and hundreds of milliseconds of processing on modern hardware. The bloat is a quality-of-experience problem for users on slow connections or older hardware; it is also an environmental problem (data transfer and processing have energy costs); it is also a structural problem (sites that depend on heavy JavaScript are fragile in ways simpler sites are not).
Tracking and privacy. The advertising-supported model of the web has produced extensive tracking infrastructure: cookies, fingerprinting scripts, third-party trackers, pixel beacons, and the various other technologies that collect user behavior data. Modern web pages routinely send data to dozens of third parties on each page load. The static renaissance’s preference for sites without third-party JavaScript is, in part, a response to this tracking infrastructure.
Algorithmic mediation. The platform decade put algorithms between the reader and the content, with the algorithms optimizing for engagement and the consequences described in chapter nineteen. Static sites that are read directly, through RSS feeds or bookmarks or links, are not algorithmically mediated. The reader controls what they read; no platform is choosing on their behalf.
Long-term durability. Web applications that depend on continuing maintenance, continuing API access, and continuing platform support are, in a real sense, ephemeral. A piece of static HTML on a stable hosting platform may continue to be readable for decades. The static renaissance prioritizes this kind of durability over the dynamic features that the application web provides.
Authorial control. The static renaissance’s writers have, in many cases, deliberately moved away from platforms specifically to have more control over what they publish, how it is presented, and who can see it. The platform decade had produced specific instances of writers being deplatformed, being shadow-banned, being subject to engagement-algorithm decisions that hurt their reach without explanation. The static-site alternative has the property that the writer controls the publication absolutely, with the limits being the writer’s own technical capabilities and the willingness of readers to find the site.
What has been recovered
A summary of what the static renaissance has recovered:
The document as a first-class object. A static-site page is a document. It has a URL. It can be linked to, archived, quoted, transformed. The various properties that documents had in the early web have been recovered for the parts of the web that operate this way.
The author’s direct relationship to the page. The static-renaissance author writes a file, runs a generator, deploys to a host. The author can see, inspect, and modify the entire production process. The continuum between writing and publishing has been substantially recovered.
The user’s relationship to the content. A reader of a static-renaissance site is reading a document, not using an application. The relationship is more like reading a book than like interacting with a service. The reader’s data is not being collected, the reader’s attention is not being optimized for, and the reader’s experience is roughly what the author intended rather than what an algorithm has decided.
Long-term durability for the parts of the web that adopt it. The Internet Archive captures static sites well. Static sites continue to work for decades. The various long-running personal sites of the static-renaissance era have demonstrated that the pattern produces durable artifacts.
What has not been recovered
The mass audience. The static renaissance is, in user-count terms, much smaller than the application web. Most internet users in 2026 spend most of their online time on platforms; the static-site web is a small minority by traffic.
The economic model. Static sites do not, in general, have an obvious business model. The most successful static-renaissance writers either have other income, run subscriptions through services like Substack or Ghost, take patronage through Patreon and similar, or simply write as a side activity. The platform decade’s model — advertising-funded engagement at scale — is not available to static-site writers, and the alternatives are smaller-scale.
The discovery problem. A static site has, by default, no built-in way to be found. Readers find static sites through links from other sites, through search engines, through RSS subscriptions, through direct word-of-mouth. Each of these mechanisms is less efficient than the platforms’ algorithmic distribution, with the consequence that static-site writing reaches smaller audiences than equivalent platform writing would.
The interactive features that platforms provide. Comments, likes, sharing, group messaging, live updates — these are the platforms’ bread and butter, and the static-site equivalents (when they exist) are usually rougher. Some static sites have very good comment systems (mostly through Webmention, ironically tying back to the IndieWeb’s work). Most do not.
Where this is going
The static renaissance is not on a trajectory to displace the application web. It is on a trajectory to coexist with it, occupying a specific niche of the web that operates by older conventions, serving readers and writers who prefer those conventions. The niche is real, has been growing, and seems likely to continue growing.
The broader question is whether the static renaissance’s values — durability, authorial control, reader sovereignty, minimal complexity — can spread back into the broader web through the various recoveries discussed in this part. Local-first software can give application users some of these values. ActivityPub can give social-network users some of them. Personal knowledge tools can give note-takers some of them. The static renaissance is, in this sense, one node in a broader recovery whose various nodes share a sensibility even when they don’t share implementations.
The book ends with a chapter on personal knowledge tools, which has been mentioned in passing throughout and which is the recovery with the most direct lineage to the knowledge-base systems of chapter nine. The chapter after that is the assessment: what’s permanent in the losses this book has chronicled, what’s recoverable but only partially, and what we should expect the next layer of the web to be able to do that the current layer cannot.