What it does
HyperCard Revival brings back Apple's HyperCard (1987-2004) — the tool Bill Atkinson wrote that let non-programmers build software by drawing cards and writing HyperTalk. It runs in the browser: a 1-bit 512x342 Macintosh card renderer plus a HyperTalk interpreter written from scratch, no dependencies.
The interpreter
src/hypercard.js is a real language implementation, not a script runner: a tokeniser, a recursive-descent parser and a tree-walking evaluator. It implements put ... into, go to next card, repeat, if/then/else, chunk expressions (char 2 to 4 of line 3 of field "name"), user handlers with parameters, and the HyperCard message hierarchy — a click walks part script, then card script, then background script, exactly as the original did.
It is deliberately DOM-free: the interpreter talks to the browser only through a host object. That is what makes a 1987 language testable in 2026 — node --test tests/ runs 49 tests, all passing.
Three stacks that prove it works
- Guided tour — the classic HyperCard first-run experience.
- Calculator — every key is a HyperTalk button; the arithmetic is done by handlers.
- Game of Life — Conway's Life computed entirely in HyperTalk, cell by cell.
How we built it
Built with Kiro. The .kiro/ directory at the repo root holds the spec (requirements, design, tasks), the steering documents, and a test-on-save hook that runs the interpreter suite whenever a source file changes. For a language implementation this is the right shape: the requirements, the design and the task list live in the repo next to the interpreter they describe, and the hook keeps the 49-test suite green while the grammar grows.
What we learned
Resurrecting a discontinued platform is mostly about the parts nobody demoed. The renderer is easy to make look right; the hard part is the message hierarchy and chunk expressions, because those are where HyperTalk's semantics actually live — and where every bug the demo stacks found was hiding.
