Frontend Architecture: Modularize vanilla JS MVP without framework rewrite

[achildrenmile]

Context

The frontend is currently implemented as a vanilla JavaScript MVP with a large, monolithic app.js file.

While this approach is suitable for early development, it introduces risks regarding:

• Maintainability
• Readability
• Testability
• Future feature growth (auth, BUAK, compliance, notifications)

A full framework rewrite is not desired at this stage.

---

Goal

Refactor the existing vanilla JavaScript codebase into a modular structure while:

• Keeping vanilla JS
• Avoiding any framework introduction
• Preserving existing behavior and functionality

This refactor is a structural improvement only.

---

Scope

Modularization

Split the current monolithic frontend logic into clear responsibility-based modules, e.g.:

• app.js – application bootstrap only
• api.js – backend / fetch calls
• auth.js – authentication & session handling
• state.js – shared application state
• ui.js – DOM rendering logic
• events.js – event listeners and handlers
• config.js – constants and configuration
• rules.js – business and validation logic

(File names are indicative; exact structure may vary.)

---

Technical Requirements

• Use native ES modules (type="module")
• No build step required
• No framework or library introduction
• No change in user-facing behavior
• No functional refactoring beyond separation of concerns

---

Architecture Requirements

• Business logic must be separated from DOM manipulation
• No direct backend calls inside UI rendering code
• Shared state must be explicit and centralized
• Future migration to a build step or framework must remain possible

---

Acceptance Criteria

• app.js is reduced to bootstrap logic
• Code is split into responsibility-focused modules
• All existing features continue to work unchanged
• No framework dependencies added
• Codebase readability is significantly improved

---

Out of Scope

• UI redesign
• Framework migration (React, Vue, etc.)
• Build tooling introduction
• Automated testing (separate issue)

---

Notes

This issue prepares the frontend codebase for future growth while keeping development speed high.
It is a prerequisite for later improvements such as bundling, minification, and testing.