A static site built with Hugo serves the exact same content from a CDN for nothing, loads in a fraction of the time, and has no admin URL to defend. That's not a niche case. It's most of the web.

Static generators like Hugo, Zola, and Eleventy have been the right default for brochure sites, blogs, docs, and portfolios for years. The one argument that held back wider adoption was that WordPress was easier to set up for someone who didn't want to learn anything. That argument is gone now, because an LLM can scaffold a themed Hugo site in a single prompt. What's left is the comparison on the things that always mattered: performance, cost, security, and complexity. WordPress loses all four.

01. FOUR PAGES, FORTY KILOBYTES

Load a vanilla WordPress install in a browser. The initial HTML is around 60KB before anything dynamic has happened. Add the theme's CSS and JS and the page crosses 400KB before a single image. Time to first byte on a cold request against a modest VPS sits somewhere between 400 and 700ms, because the server is booting the PHP interpreter, opening a database connection, executing the theme's templates, and rendering markup on every request that doesn't hit cache.

A Hugo site with a stock theme serves a similar-looking page in roughly 40KB of HTML and CSS combined. The server isn't rendering anything. The CDN hands over a prebuilt file. TTFB is typically under 50ms because the response is already on the edge, sitting in front of the user's network. Core Web Vitals scores fall out of this for free. LCP under 2.5 seconds is trivial when the HTML is pre-rendered and the critical CSS is inline.

This isn't a framework vs framework benchmark. It's rendering vs not rendering. WordPress decides what the page looks like on every request. Hugo decided at build time and the decision is frozen into the file you're reading. For a site that updates once a week, rendering on every request is pure waste.

02. THE HOSTING BILL

Cheapest plausible WordPress hosting is not free. Managed WordPress starts at eight to fifteen dollars a month for a single site, and that's before you hit a traffic tier, decide you want automatic backups, or add a staging environment. A raw VPS is cheaper per box, but now you own the security updates, the database backup job, and the 3am reboot when the LAMP stack falls over.

Static hosting is free until the traffic is absurd.

Cloudflare Pages, Netlify, and Vercel all have free tiers that cover roughly 100GB of monthly bandwidth and unlimited requests. For a personal site, a small business brochure, or a developer blog, you will never reach those limits. If your site gets linked on Hacker News and takes a million requests in two hours, the static bill is still zero. A WordPress site on a fifteen dollar VPS is unreachable for the entire time the link is trending, because the PHP workers are busy rendering the same homepage over and over.

The scale curve is what's interesting. WordPress costs grow roughly linearly with traffic, because you're buying CPU to render pages. Static costs are flat, then step up once you cross a free tier. Most sites never cross it. The ones that do are paying tens of dollars a month for traffic that would have cost hundreds on managed WordPress.

03. THE ATTACK SURFACE

Patchstack's State of WordPress Security in 2026 report logged 11,334 new WordPress-related vulnerabilities in 2025, a 42% jump on the year before. Ninety-one percent of them landed in plugins. Core took six in total, all low priority. And 46% of the disclosures arrived with no patch available on the day they were published, meaning nearly half of every year's findings are live in the wild with nothing to install to fix them. A typical install runs twenty plugins from nineteen different authors, each on their own release cadence, each able to execute arbitrary PHP on your server the day one of them ships a bad version.

The attack surface of a Hugo site is the CDN.

That's the whole sentence. There is no database, no PHP runtime, no admin login, no XMLRPC endpoint, no user accounts, no plugin ecosystem. Compromising a static site means compromising Cloudflare or Netlify, and if that happens, the WordPress installs on those same providers have bigger problems too.

Maintenance reduces to the same shape. WordPress asks for attention in two places. Core updates, which are usually fast and safe. And plugin updates, which are neither. A plugin abandoned by its author turns into a silent liability that nobody on the support forum is going to fix for you. You either audit the code yourself, swap the plugin for a maintained alternative, or accept the risk.

A Hugo site needs the Hugo binary updated occasionally. That's a binary swap. If a theme is abandoned, the site still works forever, because the theme has already done its job at build time. The generated HTML has no runtime dependency on anything, and nobody can push a compromised update to a file that's already sitting on a CDN.

This is the axis where the WordPress argument is weakest, and it's the one people routinely underweight. Every running WordPress install is an ongoing commitment to patch discipline. Every static site is a folder of files that will still load in ten years if the hosting account still exists.

04. WHAT YOU ACTUALLY OWN

Open the hood on a WordPress site and count the moving parts. The platform is PHP, at a specific version range that you probably didn't pick. A web server, usually Apache or nginx, configured to hand requests to PHP. A database, usually MySQL or MariaDB, tuned for whatever plugins you installed. A theme, which is itself a collection of PHP templates and a compiled CSS bundle. Plugins, typically between fifteen and thirty, each carrying JavaScript, CSS, and database tables. A caching layer, because the default rendering path is too slow to be used unaided.

A Hugo site is a single binary, a folder of Markdown, and a theme that's usually a Git submodule.

my-site/
├── config.toml
├── content/
│   ├── _index.md
│   ├── about.md
│   └── posts/
│       └── 2026-04-15-hello.md
├── layouts/
├── static/
│   └── images/
└── themes/
    └── ananke/        (git submodule)

You can list every file that contributes to the output. hugo reads the content directory, applies the theme's templates, and writes HTML to public/. That's the entire build system. There is no state outside those files.

The architect's question isn't which is more powerful. WordPress is more powerful. The question is which you can still understand in two years. WordPress drifts. Plugin versions move independently, the database schema accumulates rows from plugins you removed, the PHP version gets forced up by your host, the theme gets patched or doesn't. By year three, nobody on earth can tell you exactly what's running on the server. A Hugo project looks the same in year three as it did on day one, because it's a directory of text files and a tool that converts them.

That's what local-first means for websites. You own the canonical content as Markdown, the build tool is a single open source binary, and the output is vanilla HTML. You never bought anyone's platform.

05. WHERE STATIC ISN'T ENOUGH

Worth being honest about where the argument breaks down.

There are legitimate reasons to reach for a dynamic runtime, and WordPress is one option among several for each of them. Membership and paywalled content need server-side logic. WordPress can handle that, and so can Ghost, Memberful, or a small custom application. Busy comment sections need real-time moderation. WordPress can do it, and so can Disqus, Discourse, or hosted widgets like Giscus bolted onto a static site. E-commerce at scale needs catalogs, cart state, and payment flows, and for most storefronts Shopify is the more pragmatic answer than WooCommerce. It ships payments, inventory, and tax compliance as a managed service instead of a plugin stack. BigCommerce and Squarespace Commerce cover similar ground.

The last real pull toward a full CMS is the non-technical editor. When the person maintaining the site is going to live inside the admin panel every week and a Git workflow is the wrong abstraction for them, WordPress works. So do Ghost, Webflow, and Squarespace. Headless CMSs like Sanity, Decap, and TinaCMS sit in the middle ground, pairing a familiar admin UI with a static build pipeline so the output is still a folder of HTML on a CDN.

These are all real use cases. None of them has a single correct answer. And they're still a small fraction of the WordPress installs currently running on the internet. The rest are blogs that update once a month, brochures that don't update at all, and small business pages that were set up once and haven't been touched since. For all of those, static is enough.

06. THE LAST MOAT

Until recently, the honest answer to "why WordPress" for a non-technical user was that it shipped with a theme picker, a visual editor, and a plugin store. Setting up a Hugo site required cloning a repo, editing TOML, and understanding how templates worked. That friction was the real moat.

The moat is drying up fast. A single prompt to a capable LLM now produces a Hugo site with a chosen theme, a styled homepage, a blog index, an about page, and an RSS feed, ready to drop onto Netlify by dragging the folder into a browser. The entire setup that used to take a technical evening now takes a chat. The LLM is also the one who debugs the site when the user reports "it looks broken on my phone", and the user never needs to learn how templates work because they can ask for changes in English.

This doesn't kill WordPress outright. Plenty of people will keep using it, and the WordPress economy around themes, hosting, and agency work is not going anywhere soon. But the one argument that defended WordPress against static for most of its addressable market is gone. WordPress was easier because humans were slow. The humans aren't slow anymore.

THE LESSON

Static is enough for most of the web because most of the web is text with occasional pictures. The reasons to pick WordPress are real, but they describe a minority of the sites currently running it. Every other site is paying for a dynamic runtime to serve content that doesn't change between requests. That runtime gets paid for in hosting costs, update cycles, and a security posture that needs tending on a schedule.

If you're starting a new personal site, a blog, a docs page, or a small business brochure, pick a static generator. Ship it on a free CDN. Update it when there's something to say, and leave it alone when there isn't. That used to be the harder path. It isn't anymore.

He never planned to release it.

That changed when he kept running into the same tradeoffs in every other terminal. Speed came at the cost of features. Features came at the cost of native platform behavior. Native behavior came at the cost of cross-platform consistency. His thesis became: these are not actual tradeoffs. You should not have to pick.

01. THE ARCHITECTURE

The center of Ghostty is libghostty: a cross-platform, zero-dependency C-ABI compatible library written in Zig. It handles terminal emulation, font rendering, and GPU rendering logic. It exposes a pure C API, which means any language that can call C can embed a terminal. A proof-of-concept project called ghostling demonstrates this with a minimal host.

On top of libghostty sit platform-native UI layers, built specifically for each operating system rather than abstracted away.

On macOS, the UI layer is Swift using AppKit and SwiftUI. Not because it was the easy choice. Mitchell initially wrote it in a single Zig file, then realized Apple's new APIs are Swift-only and Objective-C is clearly being deprecated. The boundary between Zig and Swift required its own engineering work, which he documented in detail. The result is that macOS users get actual macOS behavior: native window chrome, native menus, system scrollbars, dark/light mode following system preferences.

On Linux, the UI layer is Zig calling GTK4's C API directly. This was completely rewritten for 1.2, fully embracing the GObject type system from Zig and validating every change with Valgrind. The rewrite fixed a class of memory safety bugs where Zig-owned and GTK-owned memory would get freed independently, and enabled modern GTK features including animated borders and Blueprint UI.

Rendering uses Metal on macOS and OpenGL on Linux. Each terminal surface runs three dedicated threads: one for reading, one for writing, one for rendering. As of 1.3.0, the render thread has been rearchitected to hold the terminal lock 2-5x less time, and in most frames it holds it not at all thanks to improved dirty and damage tracking.

02. WHY ZIG

The language choice is not aesthetic. Zig was genuinely useful for what Ghostty needed to be.

The build system made it trivial to compile as both an executable and a library simultaneously. This is not a given: most build systems require significant configuration to support dual output modes. For libghostty to exist, the build had to produce a .so/.dylib/.dll and an executable from the same codebase without a separate build definition.

Tagged unions with exhaustive switch statements gave the compiler the ability to report errors when a new case is added and not handled everywhere. For a terminal emulator that is essentially a large state machine parsing decades of escape sequence history, that property is directly useful.

SIMD without inline assembly allowed modern vectorized operations in the hot path of terminal parsing. No hidden allocations and explicit memory management mean predictable performance for a real-time rendering application.

And the C interop story is clean: prepend export to a function definition and it gets C calling convention. No FFI layer, no binding generator. For GTK on Linux, which exposes a C API, this is the difference between calling GTK directly and going through an indirection layer.

03. GHOSTTY 1.3.0

Released March 9, 2026. Six months of work. 2,858 commits. 180 contributors.

Scrollback Search was the most-requested missing feature from the 1.0 launch, and it shipped here. Cmd+F on macOS, Ctrl+Shift+F on Linux. Search runs on a dedicated thread concurrent with terminal I/O. When you close the search bar, that thread terminates and resources are freed.

Native Scrollbars follow the system scrollbar setting on both platforms. On Ubuntu with overlay scrollbars enabled, you get overlay scrollbars. On a system with persistent scrollbars set, you get persistent scrollbars. The behavior matches what the OS expects rather than imposing its own.

Click-to-Move-Cursor lets you click anywhere in a shell prompt to move the cursor there. This works in Fish, Nushell, Zsh, and other shells via OSC 133 shell integration. A small feature that turns out to be constantly useful.

Command Palette on macOS got custom entries via command-palette-entry, session search to jump to any running terminal by title or working directory, and tab color indicators. The Linux GTK palette has had this since 1.2.0.

Shell Integration received a much more complete OSC 133 implementation. Fish 4.1 and Nushell 0.111 support it natively. The jump-to-prompt and copy-command-output features are now more accurate as a result.

SSH Integration adds ssh-terminfo, which auto-wraps SSH to transmit Ghostty terminfo to the remote host. When you SSH into a server that does not have Ghostty's terminfo installed, things break in quiet ways: color support drops, keybindings misbehave, $TERM lookups fail. This wraps the handshake to transmit the terminfo entry automatically.

Command Completion Notifications surface a native OS notification when a long-running command finishes. Kick off a test suite or a build, switch to another window, and get notified when it is done. This sounds minor but it is the kind of quality-of-life feature that is hard to add without native platform integration.

I/O Performance is the change that does not show up in the feature list. The 1.3.0 release dramatically improved I/O processing. Replaying an asciinema dataset went from taking minutes to taking tens of seconds. These gains propagate into synthetic benchmarks too: Ghostty is now competitive with Alacritty on vtebench while running a significantly richer feature set.

04. WHERE IT STANDS

Ghostty's position in the terminal landscape is specific. Alacritty is faster at idle and lighter on RAM (~30MB vs 60-100MB for feature-rich terminals), but it has no built-in splits, no ligatures, and no image protocol. WezTerm has deep multiplexing and Lua-based configuration but runs 2-5x slower in throughput benchmarks. kitty has a rich extension ecosystem but uses a custom rendering approach that feels less native on macOS.

Ghostty is the terminal that treats native platform behavior as a first-class concern without sacrificing performance or feature depth. That is a rarer combination than it should be.

In December 2025, Hashimoto moved Ghostty to a non-profit structure, fiscally sponsored by Hack Club (a 501c3). He donated $150K personally and transferred all IP to Hack Club. The explicit goal was to make Ghostty something that outlives its creator rather than a project that stalls if he moves on to something else.

v1.3.0 is on GitHub at ghostty-org/ghostty, MIT licensed.

Starting a Go project from scratch does not work that way. You have go mod init and an empty main.go, and then a sequence of decisions: which router, which database driver, how to structure packages, where to put the server setup, how to wire in Docker, whether to use Air for hot reload. Community estimates put that manual overhead at 17 to 33 hours per new service. That is before you have written a single line of business logic.

go-blueprint collapses that to minutes.

01. WHAT IT DOES

go-blueprint is a CLI scaffolding tool that generates a production-ready Go project structure from a single command. Pick a framework, a database driver, and a set of optional features, and you get a project that compiles, connects, and handles HTTP requests out of the box.

Installation is available three ways. The npm path is deliberate: it exists specifically for JavaScript developers who may not have $GOPATH configured yet.

# If you have Go installed
go install github.com/melkeydev/go-blueprint@latest

# If you are coming from the JS ecosystem
npm install -g @melkeydev/go-blueprint

# If you use Homebrew
brew install go-blueprint

Running go-blueprint create without flags launches an interactive TUI that walks through every option. Fully non-interactive:

go-blueprint create \
  --name my-api \
  --framework chi \
  --driver postgres \
  --advanced \
  --feature docker \
  --feature githubaction \
  --git commit

02. WHAT GETS GENERATED

The base structure is consistent across all configurations:

my-api/
├── .github/
│   └── workflows/
│       ├── go-test.yml
│       └── release.yml
├── cmd/
│   └── api/
│       └── main.go
├── internal/
│   ├── database/
│   │   ├── database.go
│   │   └── database_test.go
│   └── server/
│       ├── server.go
│       ├── routes.go
│       └── routes_test.go
├── .air.toml
├── docker-compose.yml
├── Dockerfile
├── go.mod
├── Makefile
└── README.md

The package layout follows Go conventions: cmd/ for the entrypoint, internal/ for packages that should not be imported externally. The database.go file includes connection setup, a ping-based health check, and environment variable loading. The routes.go file has the framework wired up and ready for your first route. Air is configured for hot reload. The Makefile includes targets for running, building, testing, and linting.

The generated code is intentionally minimal. There is no deep framework abstraction layer, no opaque generated boilerplate. You can read every file and understand exactly what it does.

03. FRAMEWORK AND DATABASE OPTIONS

Seven router options are supported:

Database drivers: PostgreSQL, MySQL, SQLite, MongoDB, Redis, and ScyllaDB via GoCQL.

Advanced features via --feature: HTMX with Templ templates, GitHub Actions pipelines, WebSocket setup, Tailwind, Docker, and a React frontend option. The React option generates a full TypeScript Vite frontend alongside the Go backend. For TypeScript developers wanting a Go API without abandoning the frontend tooling they know, this is a useful starting point.

04. BLUEPRINT UI

The web interface at go-blueprint.dev lets you compose your project configuration visually. Toggle framework, database, and features via dropdowns and checkboxes, watch the file tree preview update in real time, and copy the exact CLI command to run. This is the equivalent of Next.js's create-next-app web playground: a low-friction way to explore what you will get before committing to running anything.

05. THE CREATOR

go-blueprint was built by Melkey, a Senior ML Infrastructure Engineer at Twitch who has been writing Go professionally for several years. He streams live coding at twitch.tv/melkey and teaches on Frontend Masters: a complete Go for professional developers course and a follow-up on building Go applications that scale on AWS.

The creator profile matters for understanding why the tool exists. Melkey bridges the gap between JavaScript ecosystem thinking and idiomatic Go. He is familiar with create-react-app, with npm publish, with build tooling that prioritizes developer experience. go-blueprint was partly a teaching tool, partly a community utility. The npm install path, the Blueprint UI web app, the React frontend option: these are all nods to developers who are coming from the JavaScript world and need a lower-friction entry point into Go.

The project is listed in awesome-go, has roughly 8,800 GitHub stars, and is actively maintained with regular releases.

06. HOW IT COMPARES TO STARTING FROM SCRATCH

The honest comparison is not about what go-blueprint generates versus what you could write by hand. A senior Go developer can set up a clean project structure in a couple of hours. The comparison is about what you skip: the research time, the framework evaluation, the decision fatigue about package layout conventions, the Docker Compose boilerplate you have written a dozen times before.

go-blueprint's value is the same as any scaffolding tool: it handles the decisions that have already been made well enough so that your first commit contains something meaningful rather than infrastructure setup.

The source is at Melkeydev/go-blueprint, MIT licensed.

Getting there required a specific set of architectural decisions, and each one has consequences that run all the way down the stack.

01. THE PLATFORM CHOICE

The modern web is a capable runtime, but building a privacy-first application on top of it introduces a structural tension. Browser-based apps implicitly reach toward the network for authentication, for sync, for storage quotas that assume cloud backup. Even with service workers and IndexedDB, the model assumes connectivity.

Tauri resolves this tension by using the OS webview as a rendering surface while the application logic runs in Rust. The result looks like an Electron app from the outside: a native window, file menus, OS-level shortcuts. But without the 150MB Chromium bundle. A production Tauri binary ships under 15MB.

// src-tauri/src/main.rs
fn main() {
    tauri::Builder::default()
        .plugin(tauri_plugin_fs::init())
        .plugin(tauri_plugin_dialog::init())
        .invoke_handler(tauri::generate_handler![
            read_project,
            write_document,
            search_fulltext,
            export_manuscript,
        ])
        .run(tauri::generate_context!())
        .expect("error running Loomdraft");
}

The invoke handler pattern is the boundary between worlds. React components call invoke("write_document", { path, content }) and Rust handles the actual filesystem I/O. The frontend never touches the disk directly. All file access goes through typed Rust commands that validate paths, handle errors, and enforce the application's data model.

02. THE DATA MODEL

Every Loomdraft project is a directory tree. Open the project folder in Finder and you see exactly what you'd expect: folders named manuscript/ and kb/ containing .md files with YAML frontmatter.

my-novel/
├── manuscript/
│   ├── chapter-01.md
│   ├── chapter-02.md
│   └── scenes/
│       ├── opening.md
│       └── inciting-incident.md
├── kb/
│   ├── characters/
│   │   ├── protagonist.md
│   │   └── antagonist.md
│   └── locations/
│       └── city.md
└── .app/
    ├── index.db        ← SQLite FTS5 index
    └── backups/        ← Auto-saves (up to 20 per file)

The frontmatter on each document carries just enough metadata to reconstruct the tree:

---
type: chapter
title: "The First Night"
order: 1
created: 2026-01-12T09:14:00Z
wordcount: 4823
---

Fourteen document types are supported: chapters, scenes, acts, characters, locations, factions, items, lore, timelines, notes, outlines, templates, references, and miscellaneous. The type determines the icon in the sidebar, the default fields in the frontmatter, and where in the tree the document is permitted to nest.

03. THE FRONTEND LAYER

The UI is React 19 with TypeScript, built by Vite. Component architecture follows a straightforward split: layout components (sidebar, editor shell, toolbar), feature components (document tree, search overlay, theme picker), and editor primitives (the CodeMirror instance and its plugins).

The sidebar tree is the primary navigation surface. It maintains a flattened representation of the project hierarchy, supports drag-and-drop reordering, and updates optimistically on any write operation. The Rust backend confirms asynchronously, and the tree reconciles if there's a discrepancy.

State is managed locally, no Redux, no Zustand. Each feature area owns its state through React's useReducer and context, kept shallow enough that prop drilling is rarely a problem. The editor is the sole exception. It maintains a complex internal state covering cursor position, selection, and undo history that lives entirely within the CodeMirror instance and is never surfaced to React's state tree.

04. THE IPC BOUNDARY

Every filesystem operation crosses the Tauri IPC bridge. The bridge is typed end-to-end: TypeScript interfaces on the frontend match Rust structs on the backend, with serde handling serialization.

// src/lib/tauri.ts
interface WriteDocumentArgs {
  projectPath: string;
  relativePath: string;
  content: string;
}

export async function writeDocument(args: WriteDocumentArgs): Promise<void> {
  await invoke<void>("write_document", args);
}

// src-tauri/src/commands/documents.rs
#[tauri::command]
pub async fn write_document(
    project_path: String,
    relative_path: String,
    content: String,
) -> Result<(), String> {
    let full_path = Path::new(&project_path).join(&relative_path);
    fs::write(&full_path, content)
        .map_err(|e| e.to_string())?;
    Ok(())
}

Auto-save fires every ten seconds from a React useEffect that diffs the current editor content against the last persisted snapshot. If there's a change, it calls writeDocument, updates the word count in the sidebar, and queues a FTS index refresh.

CodeMirror 6 is the right foundation for this, but not for the obvious reason. It isn't chosen because it ships as a React component you drop into a form. It's chosen because it's an extension system first and an editor second. That distinction determines everything about how Loomdraft's writing modes work.

01. WHY CODEMIRROR 6

Version 5 was a monolith. You got a feature set and customized around the edges. Version 6 was a full rewrite organized around a composable extension model. Every capability, syntax highlighting, keybindings, autocomplete, decorations, line numbers, is an extension. You assemble the editor you need from small pieces.

For a writing application, this matters because the feature set required for a novelist is genuinely different from the feature set required for a programmer. Loomdraft needs real-time word counts, not line numbers. It needs paragraph-level soft wrapping with a maximum prose width, not horizontal scrolling. It needs wiki-link hover previews, not LSP completions.

// src/editor/extensions.ts

  EditorView,
  keymap,
  lineWrapping,
  drawSelection,
} from "@codemirror/view";


export function buildExtensions(config: EditorConfig): Extension[] {
  return [
    lineWrapping,
    markdown({ base: markdownLanguage }),
    syntaxHighlighting(proseTheme),
    drawSelection(),
    keymap.of(proseKeymap),
    wordCountField,
    wikiLinkPlugin,
    config.typewriterMode ? typewriterScroll : [],
    config.focusMode ? dimSurroundingParagraphs : [],
    config.readingWidth ? maxProseWidth(config.readingWidth) : [],
  ].flat();
}

The buildExtensions function returns a fresh array whenever the writing mode changes. CodeMirror's EditorState.reconfigure accepts a new extension array without destroying the document or losing cursor position. Switching from standard mode to typewriter mode is a state transaction, not a remount.

02. WRITING MODES

Loomdraft ships four modes. Each is a composition of extensions added or removed from the base set.

Standard is the default. Syntax-highlighted Markdown, document outline in the right gutter, word count in the status bar.

Focus activates dimSurroundingParagraphs, a decoration extension that applies reduced opacity to every paragraph except the one containing the cursor. The active paragraph renders at full opacity and everything else at 25%. The effect is subtle but immediate. It collapses the peripheral visual field and anchors attention.

// src/editor/plugins/focus-mode.ts
const dimSurroundingParagraphs = ViewPlugin.fromClass(
  class {
    decorations: DecorationSet;
    constructor(view: EditorView) {
      this.decorations = this.compute(view);
    }
    update(update: ViewUpdate) {
      if (update.selectionSet || update.docChanged) {
        this.decorations = this.compute(update.view);
      }
    }
    compute(view: EditorView): DecorationSet {
      const cursor = view.state.selection.main.head;
      const activeLine = view.state.doc.lineAt(cursor).number;
      const builder = new RangeSetBuilder<Decoration>();
      for (let i = 1; i <= view.state.doc.lines; i++) {
        if (i !== activeLine) {
          const line = view.state.doc.line(i);
          builder.add(
            line.from,
            line.to,
            Decoration.mark({ class: "cm-dim-paragraph" })
          );
        }
      }
      return builder.finish();
    }
  },
  { decorations: (v) => v.decorations }
);

Typewriter keeps the active line vertically centered in the viewport regardless of scroll position. It's implemented as a scrollIntoView that fires on every selection change, offset to the viewport midpoint.

Manuscript removes all chrome. No sidebar, no status bar, no toolbar. The editor fills the window with a constrained prose width (65ch by default, configurable), large line height, and no syntax decoration. Just text on the page. It's the mode you switch into when you're not optimizing the tool, you're using it.

03. WIKI-LINKS

The wiki-link system is a hover preview plugin. Type [[character-name]] anywhere in a document and the bracketed text becomes a clickable link. Hovering shows a popover with the first 200 characters of the linked document and clicking navigates to it, adding a backlink entry to the target's frontmatter.

The plugin works in two layers. The first is a syntax extension that teaches CodeMirror to parse [[...]] patterns as a distinct token type within the Markdown grammar:

// src/editor/plugins/wiki-links.ts
const wikiLinkSyntax = new MarkdownExtension({
  parseInline: [
    {
      name: "WikiLink",
      parse(cx, next, pos) {
        if (next !== 91 || cx.char(pos + 1) !== 91) return -1; // [[
        const end = cx.slice(pos, cx.end).indexOf("]]");
        if (end < 0) return -1;
        return cx.addElement(
          cx.elt("WikiLink", pos, pos + end + 4)
        );
      },
    },
  ],
});

The second layer is a decoration plugin that applies a cm-wiki-link class to all WikiLink nodes, enabling CSS hover effects, and registers a hoverTooltip that fetches document previews from the Rust backend on demand.

04. WORD COUNT AND AUTO-SAVE

The word count is a CodeMirror StateField, a piece of state stored in the editor state object and recomputed whenever the document changes.

const wordCountField = StateField.define<number>({
  create(state) {
    return countWords(state.doc.toString());
  },
  update(count, tr) {
    return tr.docChanged
      ? countWords(tr.newDoc.toString())
      : count;
  },
});

function countWords(text: string): number {
  return text.trim().split(/\s+/).filter(Boolean).length;
}

React reads the word count from the editor via EditorView.state.field(wordCountField) in a useEffect that subscribes to view updates. This keeps the count in sync without requiring React re-renders on every keystroke. The state field computes inside CodeMirror's own transaction system, and React is only notified when the component needs to display a new number.

Auto-save runs in a useEffect with a 10-second interval. It reads the current document string, diffs it against the last saved snapshot using a simple hash comparison, and invokes write_document only if something changed. On every save, a backup copy is written to .app/backups/[filename]-[timestamp].md and the oldest backup is pruned if the count exceeds 20.

05. THE LESSON

CodeMirror 6 rewards the investment in understanding its extension model. The early hours of learning StateField, ViewPlugin, Decoration, and Transaction pay back directly in capability. Features that would require hacking the DOM in most editors are first-class extension points here.

For a writing application, that means the editor grows alongside the requirements. New writing modes, new document annotations, new keyboard behaviors, they're all extensions, not patches.

Loomdraft makes those tradeoffs consciously. This post is about the specific technical decisions that implement the local-first model, and where they required more work than the cloud alternative would have.

01. PLAIN FILES AS THE CANONICAL FORMAT

The project directory is the database. This is a deliberate choice with a specific failure mode in mind: vendor lock-in through proprietary format.

Scrivener stores projects in a binary .scriv bundle. Notion's export is lossy. Obsidian's format is close to plain Markdown but depends on specific plugin behaviors for some features. If any of these companies shut down tomorrow, recovery ranges from difficult to impossible.

Loomdraft's canonical format is a folder of .md files with YAML frontmatter. The application reads and writes this format directly. The SQLite database at .app/index.db is explicitly a derivative artifact, a cache built from the source files, always rebuildable from scratch.

# .app/index.db is a derived index, not source of truth
# Proof: delete it and run:

SELECT count(*) FROM documents;  -- 0, it's gone

# Run rebuild:
invoke("rebuild_index", { projectPath })

SELECT count(*) FROM documents;  -- 47, back

The practical consequence: you can open a Loomdraft project in VS Code, edit the Markdown directly, and the next time you open the project in the app, your changes are reflected. The app detects file modification timestamps on startup and reconciles any external edits.

02. THE SQLITE FTS5 INDEX

Full-text search across a long-form project requires an index. Scanning every file on every keystroke would be too slow, and a proper search engine like Elasticsearch would be absurdly heavy for a desktop app. SQLite's FTS5 extension is exactly the right size.

The schema is minimal:

CREATE TABLE documents (
    id TEXT PRIMARY KEY,        -- relative path from project root
    title TEXT NOT NULL,
    type TEXT NOT NULL,
    content TEXT NOT NULL,
    modified_at INTEGER NOT NULL,
    wordcount INTEGER DEFAULT 0
);

CREATE VIRTUAL TABLE documents_fts USING fts5(
    title,
    content,
    content='documents',
    content_rowid='rowid',
    tokenize='unicode61 remove_diacritics 2'
);

The content= parameter makes documents_fts a content table, which means it stores tokens but retrieves actual content from documents on query. Storage is more efficient and the index stays automatically in sync when the base table is updated via triggers.

Search queries use BM25 ranking (FTS5's default) with a boost on title matches:

// src-tauri/src/search.rs
pub fn search(conn: &Connection, query: &str) -> Result<Vec<SearchResult>> {
    let sql = "
        SELECT
            d.id,
            d.title,
            d.type,
            snippet(documents_fts, 1, '<mark>', '</mark>', '...', 20) AS excerpt,
            bm25(documents_fts, 3.0, 1.0) AS rank
        FROM documents_fts
        JOIN documents d ON documents_fts.rowid = d.rowid
        WHERE documents_fts MATCH ?1
        ORDER BY rank
        LIMIT 50
    ";
    // bm25 column weights: title = 3x, content = 1x
    let mut stmt = conn.prepare(sql)?;
    let results = stmt.query_map([query], |row| {
        Ok(SearchResult {
            id: row.get(0)?,
            title: row.get(1)?,
            doc_type: row.get(2)?,
            excerpt: row.get(3)?,
        })
    })?
    .collect::<Result<Vec<_>, _>>()?;
    Ok(results)
}

The snippet() function returns context around the match with configurable highlight markers. The frontend renders these as styled HTML, with <mark> elements picking up a blue background from the design system.

03. THE BACKUP SYSTEM

Every save writes a backup. The backup path is derived from the source file path and a timestamp:

// src-tauri/src/backup.rs
pub fn write_backup(
    project_path: &Path,
    relative_path: &str,
    content: &str,
) -> Result<()> {
    let stem = Path::new(relative_path)
        .file_stem()
        .and_then(|s| s.to_str())
        .ok_or("invalid path")?;

    let timestamp = SystemTime::now()
        .duration_since(UNIX_EPOCH)?
        .as_secs();

    let backup_name = format!("{}-{}.md", stem, timestamp);
    let backup_dir = project_path
        .join(".app/backups")
        .join(relative_path)
        .parent()
        .unwrap()
        .to_owned();

    fs::create_dir_all(&backup_dir)?;
    fs::write(backup_dir.join(&backup_name), content)?;

    // Prune: keep most recent 20, delete the rest
    prune_backups(&backup_dir, stem, 20)?;
    Ok(())
}

Backups are browsable from the UI as a version timeline. Each entry shows a timestamp and the word count delta since the previous version. Restoration replaces the current document content with the backup version and triggers a new save. The restored version becomes the new head, and the restoration is itself backed up.

04. WHAT LOCAL-FIRST ACTUALLY COSTS

The honest answer is index management.

In a cloud-first application, the server owns the index. Full-text search, backlinks, word counts, document relationships are all computed once and served to all clients. The application developer writes a few API calls.

In a local-first application, every client builds and maintains its own index. Loomdraft handles several failure cases that a cloud app would never encounter.

Stale index after external edits. A writer opens the project folder in their text editor, edits three files, then returns to Loomdraft. The app compares modification timestamps on startup and rebuilds index entries for changed files. For large projects (200+ documents) this adds about 300ms to project load time.

Concurrent writes. On some platforms, the OS may deliver file change notifications while the app is writing. Loomdraft serializes all writes through a Tokio async runtime with a single-writer mutex on the project directory, avoiding races.

Index corruption. SQLite is remarkably resilient but .app/index.db can be corrupted by a force-quit during a write. The app checks database integrity on startup with PRAGMA integrity_check and offers to rebuild from source files if corruption is detected.

None of these problems are hard. But they're problems you own entirely, with no support from a platform.

The application is open source under MIT. The full source is at github.com/H3kk3/Loomdraft and the live demo runs at h3kk3.github.io/Loomdraft.

01. THE PROBLEM

The browser's layout engine is both your best friend and your worst enemy. Functions like getBoundingClientRect(), offsetHeight, and scrollHeight return accurate answers, but at a steep cost: they force a synchronous layout recalculation of the entire page, a process called layout thrashing.

// This looks innocent. It's not.
for (const el of elements) {
  const height = el.offsetHeight;  // forces reflow
  el.style.top = height + "px";    // invalidates layout again
}

Each read-write cycle triggers a full reflow. In a tight loop or animation frame, this cascades into dropped frames, jank, and UI that visibly struggles to keep up. The standard workarounds like debouncing, batching reads before writes, ResizeObserver, reduce the damage but don't eliminate it.

For anyone building fluid editorial layouts, real-time text editors, multi-column magazine grids, or interactive typography, the DOM is simply the wrong tool. The measurements come too late and cost too much.

02. THE APPROACH

Pretext sidesteps the DOM entirely. Instead of asking the browser "how tall is this text?" after rendering it, Pretext computes the answer through pure arithmetic, the same way a typesetting engine would.

The key insight: browsers already expose fast, non-reflow-inducing font metrics through the Canvas 2D API (context.measureText()). Pretext uses these measurements as ground truth, then implements the full CSS text layout algorithm, word wrapping, line breaking, overflow-wrap, word-break, bidirectional text, in pure JavaScript.

// One-time analysis per text + font combo (~19ms for 500 texts)
const handle = prepare("The quick brown fox...", {
  font: "16px Inter",
  lineHeight: 1.5,
});

// Zero-reflow height calculation at any width (0.09ms)
const { height } = layout(handle, { width: 640 });

The prepare() call does the expensive work once: it measures all the individual glyphs and builds internal lookup tables. After that, layout() is pure math, no DOM access, no reflow, no waiting.

03. THE NUMBERS

The performance gap is not marginal.

At 0.09ms per layout call, you can reflow 10,000 text elements inside a single 16ms animation frame and still have 9ms left over. The library itself is 15KB, smaller than most icon fonts.

04. WHO BUILT IT

Cheng Lou is not a newcomer. He was a core contributor to the React team at Facebook, the creator of ReasonML (a typed functional language targeting JavaScript), and later a founding engineer at Midjourney where he worked on real-time UI at scale.

When he posted Pretext on GitHub in March 2026, the reaction was immediate. Vercel CEO Guillermo Rauch called it "so good." The repo hit trending within hours. Engineers who had spent years fighting DOM reflow in production applications recognized the problem instantly and recognized that this was a real solution, not a workaround.

Lou described the motivation bluntly: text layout had become "hellish infrastructure" that nobody wanted to own. Pretext is his attempt to make it infrastructure you don't have to think about.

05. LIVE DEMO

The demo below shows what Pretext's layoutNextLine() API makes possible: text reflowing around a moving shape in real time, at 60fps, with no DOM involvement. Move your cursor over the canvas and the circle follows it, and the paragraph reroutes itself around the obstacle on every frame.

This kind of interaction was previously impractical in a browser. The moment the circle moves, every line must be re-measured and re-laid-out. With DOM-based measurement, that's hundreds of reflows per second. With Pretext's approach, it's arithmetic that completes in under a millisecond.

06. WHAT THIS UNLOCKS

The performance headroom Pretext creates isn't just about speed, more importantly it's about what becomes possible for the first time.

• Fluid multi-column editorial layouts that reflow live as the user resizes the window, with no observable lag
• Text-around-shape wrapping at interactive framerates (as shown above)
• Server-side text layout, run the same code in Node.js to pre-calculate column heights before the page renders, eliminating layout shift
• ASCII particle systems where thousands of characters are individually positioned using calculated typographic metrics
• Variable-width text streams for typographic animations that would otherwise require a canvas renderer and a custom font parser

The library also handles everything the web throws at text: RTL and bidirectional scripts, platform-specific emoji width quirks, white-space: pre-wrap semantics, and the full CSS word-breaking algorithm.

Text layout has been a solved problem in desktop software for thirty years. On the web, it's been a recurring nightmare. Pretext is the first library that treats it as the infrastructure problem it actually is and solves it properly.