|
| 1 | +# Frontend Rewrite Spec (SvelteKit) |
| 2 | + |
| 3 | +Created: 2026-02-15T03:59:21Z (UTC) |
| 4 | +Branch: `feat/frontend-rewrite-sveltekit` |
| 5 | + |
| 6 | +## Summary |
| 7 | +Rewrite `web-frontend/` from the current webpack + vanilla JS setup to `SvelteKit`. |
| 8 | + |
| 9 | +This keeps the frontend lightweight while giving us modern routing, component structure, build tooling, and deploy adapters without committing to a heavy framework runtime. |
| 10 | + |
| 11 | +## Framework Decision |
| 12 | + |
| 13 | +### Candidates |
| 14 | +- `SvelteKit` |
| 15 | +- `Astro` |
| 16 | +- `SolidStart` |
| 17 | + |
| 18 | +### Decision |
| 19 | +Choose `SvelteKit`. |
| 20 | + |
| 21 | +### Why SvelteKit for this repo |
| 22 | +- Best fit for an app-style, interactive UI (editor + run action + output panes), not a content site. |
| 23 | +- Lightweight component model and low runtime overhead. |
| 24 | +- Official adapter model is straightforward for static or Node deployment targets. |
| 25 | +- Very strong DX for small teams: fast iteration, easy state flow, clear file-based routing. |
| 26 | + |
| 27 | +### Why not Astro as primary |
| 28 | +- Astro is excellent for content-first sites with islands, but this project is a single interactive app surface where most UI is hydrated and stateful. |
| 29 | +- Using Astro here would add conceptual overhead without clear payoff. |
| 30 | + |
| 31 | +### Why not SolidStart as primary |
| 32 | +- SolidStart is a valid option and performant, but SvelteKit has broader ecosystem/docs familiarity for handoff and maintenance in this codebase. |
| 33 | + |
| 34 | +## Goals |
| 35 | +- Replace legacy webpack frontend with a modern framework architecture. |
| 36 | +- Preserve existing API behavior: |
| 37 | + - `GET /api/v1/languages` |
| 38 | + - `POST /api/v1/run` |
| 39 | +- Keep UX familiar while improving maintainability and testability. |
| 40 | +- Keep bundle size and dependencies modest. |
| 41 | + |
| 42 | +## Non-goals |
| 43 | +- Backend API redesign. |
| 44 | +- Authentication/authorization changes. |
| 45 | +- Feature expansion beyond current runner UX in phase 1. |
| 46 | + |
| 47 | +## Proposed Architecture |
| 48 | +- Framework: `SvelteKit`. |
| 49 | +- Build toolchain: default SvelteKit tooling. |
| 50 | +- Routing: |
| 51 | + - `/` main runner page. |
| 52 | +- Core UI modules: |
| 53 | + - `LanguageSelect` |
| 54 | + - `ThemeSelect` |
| 55 | + - `CodeEditor` |
| 56 | + - `RunButton` |
| 57 | + - `OutputPanel` (`stdout`, `stderr`, `error`) |
| 58 | +- API client: |
| 59 | + - Single module for `getLanguages()` and `runCode()`. |
| 60 | + - `PUBLIC_API_BASE_URL` env support for local/dev/prod. |
| 61 | + - Runtime selector for quickly switching between local and production backends during development. |
| 62 | +- State: |
| 63 | + - Minimal Svelte stores for language/theme/source/output/loading. |
| 64 | + |
| 65 | +## Migration Plan |
| 66 | + |
| 67 | +### Phase 0: Scaffolding |
| 68 | +- Create a new SvelteKit app in `web-frontend/` (or `web-frontend-v2/` if parallel migration is preferred). |
| 69 | +- Add base page layout and shared styles. |
| 70 | +- Add environment configuration for API base URL. |
| 71 | + |
| 72 | +### Phase 1: API Integration |
| 73 | +- Implement `GET /api/v1/languages` fetch and populate language select. |
| 74 | +- Implement `POST /api/v1/run` with request/response typing. |
| 75 | +- Add loading, error, and timeout UX states. |
| 76 | + |
| 77 | +### Phase 2: Editor + UX Parity |
| 78 | +- Integrate code editor component (CodeMirror wrapper). |
| 79 | +- Add theme selection and default starter snippets by language. |
| 80 | +- Preserve stdout/stderr/error rendering behavior. |
| 81 | + |
| 82 | +### Phase 3: Hardening + Tests |
| 83 | +- Add unit tests for API client and component behavior. |
| 84 | +- Add one end-to-end smoke test for "select language -> run code -> see output". |
| 85 | +- Validate production build and static assets. |
| 86 | + |
| 87 | +## Acceptance Criteria |
| 88 | +- Frontend starts locally and can run code against local API server. |
| 89 | +- Frontend can also be run locally against the production backend used by GitHub Pages. |
| 90 | +- Language list loads from server at runtime. |
| 91 | +- Running sample `bash` and `python3` code returns output correctly when runtime binaries are available. |
| 92 | +- No regression in core workflow vs current frontend. |
| 93 | +- CI includes frontend build + at least basic tests. |
| 94 | + |
| 95 | +## Local Dev Workflow (Target) |
| 96 | +- Start API server: `go run ./server/main.go` |
| 97 | +- Start frontend dev server in `web-frontend`: `npm install && npm run dev` |
| 98 | +- Configure API URL via `.env` (`PUBLIC_API_BASE_URL=http://localhost:10100`) when you want to force the local backend. |
| 99 | +- Leave `PUBLIC_API_BASE_URL` unset to exercise the production backend locally before a GitHub Pages deploy. |
| 100 | + |
| 101 | +## Risks |
| 102 | +- Runtime language availability differences (for example `python3` in sandbox rootfs). |
| 103 | +- Migration friction if we replace `web-frontend` in place instead of parallel folder rollout. |
| 104 | +- Existing styling/editor behavior parity may require incremental tuning. |
| 105 | + |
| 106 | +## Rollout Recommendation |
| 107 | +- Build in `web-frontend-v2/` first for low-risk validation. |
| 108 | +- Switch deployment/build wiring after parity is confirmed. |
| 109 | +- Remove legacy webpack frontend after cutover. |
0 commit comments