Local First, Forever

Original Article ↗ Hacker News Discussion ↗

Value of Local‑First vs Cloud Convenience

  • Some see little practical need for offline/local‑first: network is usually reliable, and users value real‑time, multi‑user features more than “works in airplane mode.”
  • Others strongly prefer local‑first for autonomy, cost control, and resilience to outages and price hikes; they keep data, tools, and reference material offline and see cloud reliance as brittle.
  • Several argue that “convenience is king”: as life gets busier, most users willingly trade control and privacy for push‑button simplicity.

Monetization and Business Models

  • Many builders struggle to monetize truly local‑first apps; recurring SaaS revenues are easier to justify when servers and proprietary storage are core to the value.
  • Suggested approaches: free core with paid sync/publish, one‑time licenses plus paid updates/support, or “local‑first but subscription‑gated features.”
  • Debate over whether local‑first is inherently bad for business, or if expectations were distorted by $0.99 apps, app stores, and investor preference for ARR/MRR.
  • Some note that historically, major desktop vendors thrived on local software, but continuous platform churn and user expectations now push toward subscriptions.

Technical Challenges: Sync, CRDTs, and Conflicts

  • Sync and conflict resolution are repeatedly described as hard and expensive: multi‑device edits, concurrent writers, and UX for conflicts are non‑trivial.
  • CRDTs are seen as powerful but complex; they introduce trade‑offs (state vs op‑based, performance, hidden data loss modes, migration issues).
  • Some argue CRDTs are over‑applied; for many apps, centralized reconciliation or simpler “last‑write‑wins + manual conflict UI” is more practical.
  • Mobile platforms, especially iOS, complicate generic file‑based syncing due to background limitations.

Using Generic File‑Sync as a “Dumb” Backend

  • The article’s pattern (Dropbox/iCloud/etc. + op‑log files) resonates for simple cases and single‑user or light collaboration.
  • Benefits: reuse mature sync infra, avoid custom backends, reduce lock‑in; apps can treat file sync as a commodity.
  • Critiques: poor fit for real‑time collaboration and chat, slow or buffered sync, weak conflict handling, and inability to hook into sync events.

Data Ownership, “Forever,” and Self‑Hosting

  • Strong interest in owning data in open, portable formats and being able to keep using apps if vendors die or shut down servers.
  • Proposals include zipped repositories, exportable “workspace.zip” plus downloadable backend binaries, and S3‑like encrypted storage under user control.
  • Some emphasize that “local‑first forever” also depends on software survivability: low dependency stacks, self‑hostable servers, and clear schemas.

UX, Cursors, and Accessibility

  • The blog’s animated shared cursors trigger a huge sub‑thread: some find them playful and community‑building; many find them distracting, nauseating, or creepy.
  • Suggested mitigations: site‑level toggles, honoring prefers-reduced-motion, or relying on browser reader modes and ad‑block filters.
  • Meta‑point: tension between personal, expressive web design and readers who want minimal, distraction‑free interfaces for technical content.

Historical Perspective and Cycles

  • Several frame local‑first as another turn in a long cycle: mainframes → PCs → web/SaaS → richer clients/edge compute.
  • Business incentives (lock‑in, subscriptions) are seen as major drivers of cloud‑first, often overshadowing purely technical trade‑offs.