Administration
A fictional institute, built to teach real mechanisms.
The world-building is a device. The engineering is the point: everything here is meant to survive being checked against a specification.
- Experiments
- 22
- Laboratories
- 10
- Dossiers
- 05
- Artifacts
- 12
Why it exists
The gap between building something and being able to explain it.
Most frontend material optimises for getting something working. That is a reasonable goal, and it produces engineers who can build almost anything and explain almost nothing. The failure shows up later: a layout that breaks in one locale, a page that is fast on the developer's laptop and unusable on a three-year-old phone, a component that re-renders a thousand nodes because state was placed two levels too high.
None of those are exotic. They are all consequences of models, the cascade, the event loop, the rendering pipeline, reconciliation, that are documented in public and taught almost nowhere. This institute exists to close that gap by making the models operable: not described, not diagrammed, but pushed until they break in front of you.
The second reason is tone. Technical writing about the web tends to be either a tutorial or a lecture. A laboratory is a better metaphor, because it admits that the interesting part is the experiment you were not expecting to run.
Who it is for
The developer who ships it anyway
You fixed the bug by adding a z-index and moving on. It worked. You still do not know why the first fix failed, and that gap is going to cost you again next quarter.
The engineer between levels
You can build the feature. The interview asks what happens between a keypress and a pixel, and you realise the answer you have is a slogan rather than a mechanism.
The senior who wants the primary source
You already know the rules. You want the specification text, the engine behaviour behind it, and an honest note about where the simplification stops being true.
Anyone teaching this
Every bench here is a demonstration you can operate in front of someone. Copy the idea, steal the framing, argue with the conclusions.
Who made it
One engineer, writing in the open, and happy to be corrected.
The institute is written and maintained by a single frontend engineer, with the content, benches and interface all built in the open as one project. There is no editorial team behind the nameplate, the departments, hazard labels and personnel files are set dressing, and the research notes are one person's reading of the specifications.
That matters for how you should treat it. Where a claim is a documented fact, it is cited. Where it is a simplification, the bench says so. Where it is an opinion about engineering practice, it is written as an opinion, and you are welcome to disagree with it, preferably after running the experiment.
Corrections are the most valuable contribution anyone can make. A specification changes, an engine ships a new heuristic, a measurement stops being representative: all of that ages the content, and none of it ages the method.
Standard of evidence
- Documented fact
- Stated in a specification, in an engine's own documentation, or reproducible in every major browser.
- Simplified model
- A teaching abstraction. Directionally correct, deliberately incomplete, and labelled as such wherever it appears.
- Interpretation
- The institute's reading of the evidence. Reasonable engineers disagree here, and saying so is part of the method.
Where a simulation approximates a browser, the bench says so in its own footer. Nothing here claims to be how every engine is implemented, because no such single answer exists. Chromium, Gecko and WebKit disagree in the details, and all three change between releases.
How it is built
Next.js App Router, TypeScript, Tailwind CSS. All research content is structured data kept separate from the components that render it, so the archive can move to a content pipeline without touching the interface. Every bench is code-split and client-only, so a page of reading pays nothing for a simulation you never scrolled to.
A site about frontend performance that was slow would be the funniest possible failure, so the constraints are taken personally.
Accessibility
- Every bench is operable by keyboard, with visible focus and labelled controls.
prefers-reduced-motiondisables reveals, ambient drift and every animated transition.- Sound is off by default and never plays without an explicit interaction.
- No information is available only through colour, motion or animation.
Open source
MIT licensed, corrections welcome, evidence required.
The whole institute is public: the interface, the benches and every word of the research content, which lives as typed data rather than as markup. Nothing in the content layer imports React, so the archive can move to a different pipeline without touching a component.
Corrections are the most valuable contribution. A specification changes, an engine ships a new heuristic, a measurement stops being representative: all of that ages the content, and none of it ages the method. Proposals for new experiments are reviewed on whether there is a mechanism underneath and an instrument that lets somebody discover it, rather than be told.
Start here
Run one bench before you decide whether any of this is worth your time.
Every experiment states a question, hands you the instrument, and only then explains what you observed.
Experiment of the day
The invisible DOM
There are two trees. You wrote one of them. Assistive technology reads the other.
engineer10 min