I wrote a static web page and accidentally started a community (2023)

Original Article ↗ Hacker News Discussion ↗

Minimalism vs richer local data layers

  • Some argue that truly “local-first” static sites shouldn’t need embedded SQLite, React, or heavy libraries; plain JS data structures and tiny DOM helpers can suffice and load instantly.
  • Others counter that tools like TinyBase or PGlite add only kilobytes for powerful features (reactivity, queries, embedded DBs, potential vector search) that plain Maps can’t replicate.
  • Various local search strategies are discussed: prebuilt static indexes queried with JS, lunr.js for full-text, WASM databases (PGlite) for more advanced scenarios.

Old-school simplicity and static workflows

  • Several commenters celebrate workflows where sites run identically locally and remotely: static files, simple configs, manual sync of files/DBs, minimal or no frameworks.
  • There’s nostalgia for early-2000s web practices, and the view that if you “keep it simple,” the web has only gotten easier.

Browsers, file://, and local servers

  • A major pain point is that browsers restrict file:// pages from loading other local resources or remote JS due to CORS, which undermines “local-first” HTML-on-a-USB-stick style usage.
  • Workarounds: toggling insecure flags (e.g., in Firefox), running a tiny local HTTP server (python -m http.server, Caddy, etc.), Safari/extension options, or future standards like Web Bundles.
  • There is debate over local HTTP servers vs pure file-based apps, and ideas for better local service discovery, port/DNS mapping, and even Unix socket support.

Local-first vs SSR and cloud-centric design

  • Some wonder why “data near UI” (local-first) gets less attention than “UI near data” (SSR).
  • Others note SSR’s motivations: SEO, performance on low-end devices, and protection against scrapers. SSR is seen as resource-expensive on servers but still justified in many cases.

Native apps, VMs, and what computers are for

  • Multiple comments express dislike for the browser as the universal app platform and long for native or lighter VMs (JVM, UXN, DOS, emulators) instead of Electron-scale runtimes.
  • There’s a philosophical thread: local-first as a way back to file-centric, user-controlled computing, with sync as an optional layer.

Sync, CRDTs, and business reality

  • Local-first is framed not as “offline-only” but as combining local UX with cloud-like sync and collaboration (often via CRDTs).
  • Commenters emphasize that sync/conflict resolution is hard and poorly tooled, and that many paying users in well-connected regions rarely demand offline support, making it a tough sell early in a product’s life.

Browser storage and data portability

  • IndexedDB is criticized as slow, awkward to use, and unsynced across devices, undermining the “no spinners” promise.
  • Some wish for a simple, secure, cross-device roamingStorage primitive; others point to cryptographic access control or platform services (e.g., CloudKit) as partial answers.

Self-hosting, longevity, and security

  • A recurring ideal is: local-first apps plus an optional, easily self-hostable sync backend, with simple “eject” paths (e.g., export ZIP + single executable server).
  • Security concerns surface around relaxing file:// restrictions, naïve local servers, Python’s http.server defaults, Docker port bindings bypassing firewalls, and AV false positives on referenced domains.

Examples, tools, and experiments

  • Commenters share projects aligned with the philosophy: notebook-in-one-HTML-file, offline-friendly PWAs, browser-based SQL tools and ffmpeg via WASM, localStorage-based apps, and task/note IDEs with planned self-hosted sync.
  • There’s also discussion of using Syncthing, CRDT-based systems, and local bookmark scripts instead of SaaS, plus links to talks and essays on local-first and “file over app” thinking.