A front end that survives redesigns: CSP-safe patterns that work

The pages on this site's family run on a few kilobytes of hand-written ES5. No framework, no bundler, no jQuery — and, because the sites ship a Content-Security-Policy, no inline scripts anywhere. These are the patterns that make that livable.

1. One entry point per page, found by attribute

Every page that needs behaviour carries a <script src=... data-tool="name"> tag. The shared script file reads document.currentScript.dataset.tool at load time and dispatches to that module. It is dependency-free page-to-script wiring that survives any redesign of the HTML around it.

2. IDs are the contract

Scripts address the DOM by element ID and data attributes, never by styling classes. Styling classes belong to CSS and change constantly; IDs are semantics and change rarely. When a redesign came through recently, the entire JavaScript audit was "grep for getElementById" — every hook held.

3. Progressive enhancement, for real

Filters, editors and calculators here all render their no-JS state first and enhance if the script loads. The test: disable JavaScript and the page must still be a complete, readable document. This is also the cheapest accessibility audit there is.

4. localStorage with a versioned envelope

Anything a user creates in the browser (drafts, trackers, tool state) is stored as {"v":1,...}. When the shape changes, bump the version and migrate on read. The day accounts arrive, local data upgrades instead of breaking.

The reward for all this discipline is boring: pages that load fast on hotel Wi-Fi, zero console errors, and redesigns that touch CSS files rather than JavaScript.