Why every experiment gets its own subdomain
The obvious way to publish a pile of small web experiments is to put them all
in one app, under one origin, at /experiments/whatever. It is one deploy, one
build, one thing to maintain.
That is also how you end up unable to touch any of them.
What one origin actually costs
Put two apps on one origin and they share more than a domain name. They share
a localStorage namespace, a cookie jar, a permissions record, and — if they
are in one bundle — a framework version. That last one is the trap. The moment
app three and app seven have to agree on which version of a library they use,
adding app eight means checking eight things.
For a collection meant to grow to tens or hundreds of unrelated experiments, built years apart, that coupling compounds until the correct move is always “don’t touch it”.
Buying isolation instead of building it
Separate subdomains make each experiment a separate browser origin. The isolation is enforced by the same-origin policy — code that already exists, that nobody has to maintain, and that cannot be accidentally refactored away.
The interesting part is what this makes unnecessary. Module federation, shared dependency negotiation, path rewriting, cookie scoping: every one of those is machinery for making things safely coexist on one origin. On separate origins there is nothing to negotiate.
Framework agnosticism, it turns out, is not a layer you build. It is a property that falls out of the hosting choice.
The part that is genuinely worse
Duplication. Every experiment carries its own copy of the design tokens, its own stylesheet, its own fonts. Change a colour and every copy is stale until something pushes the update out.
That is a real cost, and it is the right one to pay. A stale copy is a visible, local problem in one app. A shared runtime dependency is an invisible, global one — and the whole point of an archive is that opening something from three years ago should be boring.