How to structure a non-trivial interactive application (100+ lines of JS, multiple UI states, user interactions) in a single HTML file without it becoming an unmaintainable mess. Single-file apps are ideal for personal tools, demos, prototypes, and utilities because they have zero build step, zero dependencies, work offline, and can be shared by email or dropped into any web server. But without structure, they quickly become spaghetti: DOM reads mixed with business logic, state scattered across DOM attributes and global variables, event handlers that directly manipulate other parts of the UI, and no clear flow of data.

As a web application grows, colors, spacing, typography, and shadows become inconsistent across components. Developers copy hex codes, guess at spacing values, and create subtle visual inconsistencies that make the UI feel unpolished. When a design change is needed (e.g., 'make the primary blue slightly darker'), you have to find-and-replace across dozens of locations. Dark mode becomes a nightmare of duplicated styles. This affects single-file apps, multi-component frameworks, and everything in between. The core issue is: no single source of truth for design tokens.

When building bookmark managers, link grids, speed-dial pages, dashboard link sections, or any UI that shows a collection of website links, you need icons for each site. Options: (1) Manually download and host icons — tedious, doesn't scale. (2) Use a big icon library like FontAwesome — doesn't have website-specific logos. (3) Use each site's /favicon.ico — unreliable, CORS blocked, inconsistent sizes, some sites use .png or .svg. (4) Use a favicon proxy service — the right answer. Without icons, link grids look bland and are hard to scan visually. Users rely heavily on favicon recognition for quick navigation.

When building single-file web tools, personal dashboards, or local-first applications that don't need a backend server, the question of where to persist state comes up immediately. Options include: localStorage, sessionStorage, IndexedDB, cookies, Cache API, File System Access API, and even embedding state in the URL hash. Each has different size limits, APIs, and tradeoffs. The wrong choice leads to either over-engineering (setting up IndexedDB for 10KB of data) or hitting walls later (localStorage 5MB limit when storing images). This applies to: personal note-taking apps, bookmark managers, habit trackers, configuration tools, code snippet managers, and any tool where data lives on one device in one browser.