What if serverless meant no backend servers?

Original Article ↗ Hacker News Discussion ↗

A blog post proposing “serverfree” web apps—where all logic and data live entirely on the user’s device—prompts comparisons to classic desktop software, Electron-style bundles, and the broader “local-first” movement. Commenters weigh the appeal of privacy, offline capability, and simpler billing against practical issues like sync across devices, backups, conflict resolution, and updates, often concluding that some form of optional cloud or peer-to-peer sync is still needed. Many also criticize the “serverfree” label as confusing, noting that static hosting is still required and that similar ideas have been explored for years under other names.

Scope of “serverless” / “serverfree”

  • Many read “serverless” as shorthand for Lambda-style, per-invocation billing; some argue this is just rebranded shared hosting.
  • Several dislike “serverfree” as a term because a static host is still a server and logical “app/database servers” still exist, just moved client-side.
  • Some prefer “local-first” as clearer: device-first, server-optional, versus “offline-first” or “serverfree,” which sound more limiting.

“Isn’t this just a desktop app / Electron?”

  • Multiple comments say the proposal largely recreates desktop apps, or Electron-style bundling, but via browser + SQLite-in-WASM.
  • Critics note we’ve circled back to heavy, slower stacks to regain capabilities desktop apps already had.
  • Supporters counter that web distribution (“go to this URL, no install, no app store, no code-signing”) is a big practical win.

Data storage, backup, and sync

  • Core model: data lives entirely on the local device (e.g., browser SQLite + OPFS).
  • Concerns:
    • No built-in sync across devices; users often rely on 3–4 devices and expect seamless sharing.
    • Data loss risk on device failure/theft; manual export/import is seen as a “usability dead end.”
  • Suggested mitigations:
    • Use generic cloud storage (Dropbox/Nextcloud/iCloud/etc.) to sync local files, optionally encrypted.
    • Optional encrypted sync to a central server, or peer-to-peer sync (WebRTC, Bluetooth, LAN, P2P protocols).
    • Distinguish between “dumb” storage vs. application-specific conflict resolution logic.

Local-first / sync technologies

  • The idea aligns with “local-first software”: primary storage on the device, sync as an add-on.
  • Commenters reference emerging tooling (e.g., CRDT-based systems, SQLite sync layers, alternative sync protocols) and maintain comparison lists.
  • There is interest in OS-level generic sync, but also recognition that conflict resolution is often application-specific and complex.

Implementation questions

  • Questions raised about:
    • How SQLite+WASM+OPFS compares to localStorage in performance and durability.
    • Overhead and benefit of using a web worker that mimics HTTP to a local DB vs. direct DB access.
    • Schema migrations and breaking changes in a purely client-side DB.
    • Practicality of avoiding any backend when API keys or third-party services are involved.

Overall sentiment

  • Many find the experiment intellectually interesting and aligned with privacy/local-control goals.
  • Significant skepticism remains about terminology, lack of sync/backup, operational robustness, and whether this truly improves on well-designed desktop or hybrid local+cloud apps.