Research PWA-first frontend with local backend

[IgorWarzocha]

Research question

Should Howcode move toward a PWA-first architecture where the frontend is a browser/PWA client and the local backend is the product boundary, instead of treating Electron as the main frontend shell?

Deliverable

• Map what we gain and lose by making headless/browser mode the primary UI path.
• Compare two options:
  • keep Electron as the packaged backend/runtime but remove or de-emphasize the Electron window
  • remove Electron entirely and run a stock Node/backend service with a PWA frontend
• Identify the hard blockers, especially startup, install/update UX, local API security, native OS integrations, and browser/PWA limitations.
• Recommend whether this should become an epic, a small prototype, or a dead end for now.

Acceptance criteria

• The decision is explicit: keep Electron-first, move to PWA-first gradually, or prototype before deciding.
• The required backend/frontend API boundary is described well enough to estimate follow-up work.
• The risks are documented, especially local HTTP/WebSocket security and backend lifecycle/startup.
• Any follow-up work is split into concrete issues rather than one giant rewrite ticket.

Notes

This came out of discussing a possible product shape:

launch headless → add/install PWA → use normally

The interesting part is not “pure PWA”. The assumed shape is a real local backend that still owns files, terminals, git, agents, SQLite, native modules, etc. The PWA would be the face, not the runtime.

Potential upside:

• one canonical browser frontend path instead of Electron/preload vs browser bridge parity
• cleaner split between backend and frontend
• easier mobile/remote use
• possible future custom frontends against a stable local API
• less UI-shell complexity if the Electron window goes away
• much bigger packaging/runtime simplification if Electron eventually goes away entirely

Known likely costs:

• PWA cannot reliably start the backend by itself
• first-run/install/reconnect UX needs real product design
• native shell features get weaker or require a small helper/tray/launcher
• local API security becomes the primary security boundary
• updates split into backend and frontend/service-worker concerns
• browser differences become part of QA