Scrollytelling and playful interactivity in the neal.fun and pudding.cool genre, which is about as far as static goes
The web moved from documents to applications without ever giving up documents, and the interesting work sits in the overlap. A page in this genre is still content — it has a thing to say, and you read it top to bottom — but you act on it as you go, and what you do changes what you see.
Assignment 1 was set here on purpose, so you arrive at this page having already shipped one.
The genre#
The reference points are neal.fun and The Pudding: explanatory pieces where the explanation is something you operate rather than read. Scroll-driven storytelling, small simulations you can poke, a slider that makes the argument concrete.
What they have in common is restraint. One idea expressed through one interaction, with no second feature competing for the reader’s attention. That is the same bar A1 set — one strong idea with a point of view, and nothing else — and it is the hardest part, because an agent will happily add a settings panel to anything.
Where to store state#
Client-side state is usually split across three places.
- the URL — the part a visitor can share and the back button can reach.
Read it with
URLSearchParams, write it withhistory.pushState, and what goes there is a design decision rather than a technical one. If a reader should be able to send someone the view they are looking at, it belongs here. - the DOM — native elements can represent their own state. An open
<details>element has anopenattribute; a checked checkbox has acheckedstate. Both work without a separate store or additional code. - a store — a plain object in your JavaScript, for state not represented in the URL or DOM. You manage it, and a reload discards it unless you persist it.
People often skip the DOM. Asking an agent to add a state variable for an open
panel when <details> already provides that state is a small instance of the
priors problem below.
Choosing an architecture#
Once a page needs enough persistent or shared state, decide whether to build it as content with enhancements or as a client-side app. Use three criteria:
- how much of the page’s meaning survives with JavaScript off
- whether a visitor would expect to link to a particular view
- whether the state outlives the visit
Use the criteria to choose the architecture. The course defaults to the simpler option, and choosing the other one requires a reason. Week 7 applies the same criteria to server-rendered pages with forms and client-rendered apps over JSON APIs.
Without a more specific brief, an agent will often produce a single-page application with a framework and a build step. Its training data contains plenty of that code. Most pages in this genre need only a few dozen lines of JavaScript over static HTML, so require a reason before adding a framework.
Making it hold together#
Treat the page as one visual system. Decide the type scale, palette and spacing once, then put those decisions in the repo for the agent to read. This applies context engineering to design.
Interactive controls require additional accessibility work. Anything you can click has to be reachable by keyboard, changes must be announced to assistive technology, and scroll-driven effects need to degrade for readers who request reduced motion. Modern web best practices has the details; the short version is that native elements get you most of it free, and div-with-a-click-handler gets you none of it.