Repository navigation
Decide: frontend architecture after ending Lovable relationship #152
Description
Decision needed
The product owner decided on 2026-11-02 to end dependency on the Lovable platform (see #69). The Lovable-generated frontend code remains in csv-table-hub-main/, calls the FastAPI backend, and runs locally without any Lovable connection.
The 4 Oct 2026 decision to adopt the Lovable-generated frontend over the hand-built React one is being revisited.
Options
- Keep the current code, drop the connection.
csv-table-hub-main/stays as-is. Treat it as a plain React/TypeScript codebase owned by this repo. No further Lovable syncs. - Replace with Python-native. Rebuild in Reflex, NiceGUI, or Streamlit. Trade-off: solo-maintainer language consistency (Python everywhere) vs. rewrite cost.
- Hand-rebuild in a different frontend framework. Any JS framework the product owner prefers.
- Hybrid — keep existing code for now, migrate later. Explicitly defer.
Context
- Frontend reconsideration was discussed on 2 Nov; Reflex was leaned toward then paused on the Node-at-build caveat.
csv-table-hub-main/is currently functional against the live FastAPI backend. Shipping no change today is viable.- Rewriting in Python-native unblocks fully offline install (2026-11-15: ship air-gapped install procedure or keep interim wording #60) at a per-widget level (no npm cache to vendor).
Done when
The product owner selects an option and either:
- (Option 1)
csv-table-hub-main/stays, this issue is closed, Lovable repo stripped of any syncing/CI, no further migration work - (Option 2/3) A follow-up implementation issue is filed; this one is closed as "decision made, implementation tracked separately"
- (Option 4) This issue stays open with an explicit "deferred until " note
Related
- Decide: Supabase data behind the Lovable frontend - migrate, retire or confirm none #69 (closed): no Lovable platform dependency going forward
- 2026-11-15: ship air-gapped install procedure or keep interim wording #60 (offline install, due 15 Nov): a Python-native frontend simplifies this
- 4 Oct decision (now being revisited): adopt Lovable frontend over hand-built React
Activity
amar-python commentedon Nov 2, 2026
Closed — spike-then-decide (2026-11-02)
Decision: rebuild one representative screen in Streamlit as a 1-day spike, then decide the real direction based on what the spike teaches.
Why spike before committing
Frontend direction has shifted three times in two weeks (Lovable → PR #40 plain HTML/JS → Reflex lean → now a learning spike). When direction keeps shifting, picking the lowest-cost option to learn fast beats picking the most ambitious option to commit hard.
Streamlit is the lowest-cost Python-native option: ~1 day to rebuild one screen vs 2-3 days for NiceGUI or 4-5 days for Reflex. If it feels right, the spike's learning transfers to a staged migration. If it feels wrong, only a day is spent and the existing React code stays as the fallback.
The spike
csv-table-hub-main/src/components/review-table.tsx). Most interactive screen in the app: paging, cell edits with validation, required-reason dialogs, role-based conditional UI, history popup, inline validation feedback. If Streamlit handles it, it'll handle everything else.Outcomes at end of spike
csv-table-hub-main/as owned codebase. Option 1 from this issue wins.Tracked in
New spike issue filed as a follow-up. Timing: when the product owner picks it up (no fixed date). Pre-condition: comfortable PowerShell + Streamlit install on the dev machine.
Not changed by this decision
csv-table-hub-main/stays functional against the FastAPI backend. No code is removed.