Web apps in a single, portable, self-updating, vanilla HTML file

Original Article ↗ Hacker News Discussion ↗

What Hyperclay Is and How It Works

  • Described as a Node.js server plus frontend JS that lets an HTML page modify its own DOM and then persist document.body/outerHTML via a /save endpoint.
  • Hosted mode: each user gets their own HTML “app” on the service; edits overwrite that file on the server with versioning and backups. Apps can be forked; planned feature: pushing DOM-based schema migrations to forks.
  • Local mode: an open‑source “Hyperclay Local” server (MIT-licensed) enables the same pattern on a personal machine or self-hosted server.

Inspiration and Historical Context

  • Strong comparisons to TiddlyWiki, Webstrates, “HyperCard‑style” apps, and early web ideas where the browser was both reader and editor.
  • Several commenters recall old technologies: HTML Applications (HTA), Amaya, early Netscape Composer, and self-saving single-file wikis.
  • Some see it as aligned with a “read/annotate/write” web and small, personal, local-first tools.

Perceived Advantages & Use Cases

  • Attractive to people who like single-file SPAs, vibe-coded experiments, and personal tools that can be synced or versioned as just a file.
  • Suggested for microsites, dashboards, MVPs, internal tools, “block editing” style sites, and personal note/kanban/beer-tracking apps.
  • Compared positively to adding sync layers on top of localStorage, or to using Git/IPFS for persistence.

Concerns, Tradeoffs, and Limitations

  • Storing full HTML instead of JSON is seen as verbose and brittle: layout/template changes may conflict with user-modified copies; links and renamed sections can break.
  • Multi-user editing, conflict resolution, and templating are unclear; current model seems best for one developer + one editor, or many independent forks.
  • Some doubt scalability once data grows or includes images; others note it’s “just a server storing HTML files,” so a DB (e.g., SQLite) might be more straightforward.
  • Security and attack surface (e.g., extensions injecting code, multi-tenant hosting, permissioning) are raised but not deeply resolved.

Messaging, “Single File” Claim, and Comparisons

  • Multiple commenters found the marketing/storytelling page entertaining but confusing; a short technical summary was requested and later added.
  • Criticism that calling it “just an HTML file” is misleading since a Node.js backend is required for persistence.
  • Compared and contrasted with htmx, SvelteKit’s “inline” output, WordPress/PHP, Mavo, and fully offline data-URI or file://–based apps.

Broader Web Platform Wishes

  • Thread drifts into desires for:
    • Built‑in browser identity primitives beyond email logins.
    • Better support and APIs for local file:// apps (storage, clipboard, module imports) without needing a server.
    • An “offline/sandbox” mode for browsers to safely enable richer local applications.