The real question: who maintains this, and is that anyone’s job?
Museum interactives are typically specified for eight to twelve years of operation. Every mainstream software stack was designed for a different world than that — consumer software assumes a continuous team shipping updates, and its tooling, dependencies, and platforms all assume the same. The stack question is really this: every technology choice allocates an ongoing obligation to some part of your institution — someone has to apply updates, chase deprecations, and rebuild when a dependency dies. If that obligation isn’t attached to a staffed role, it defaults to no one, and the stack quietly picks its own failure date.
So judge every option by its decay curve, not its launch velocity. The demo on opening day looks identical in every stack. Year six does not.
The web stack (JavaScript/TypeScript, Chromium)
The web stack’s strengths are real: the largest talent pool in software, fast iteration, mature UI tooling, and inexpensive developers everywhere. That last point is exactly the trap. Cheap to build is not cheap to own, because the web ecosystem is designed to change monthly or quarterly — browsers update themselves, frameworks reach end-of-life mid-exhibit, dependencies rot, and the kiosk-browser update treadmill never stops. That churn is a virtue in consumer products, where a team is always on duty. On a gallery floor, it is a standing liability.
Security is part of the same bill. Patches are real, and an exhibit connected to a network — which exhibits increasingly are — is running a changing attack surface: every unpatched month widens the gap between what you deployed and what the threat landscape assumes. And the web stack carries a structural exposure of its own. A typical JavaScript application stands on thousands of small packages, many maintained by one volunteer, used everywhere and then abandoned — the ecosystem’s most famous lesson was an eleven-line package whose removal in 2016 broke builds across the software industry overnight. Every one of those packages is a dependency someone must keep patched, and a rebuild that no longer works when one of them disappears.
The blunt version: a museum without permanent technical staff whose job is to maintain exhibit code has no business running JavaScript exhibits. Not because the technology is bad — because the institution has no seat for the obligation the stack creates.
When it’s right: content-heavy, CMS-driven experiences at institutions with a genuinely staffed digital program. If you go this way, insist on pinned runtimes, minimal dependencies, and offline-first builds — every mitigation is about slowing the ecosystem’s clock down to yours. Running offline is the strongest of these: it collapses the attack surface to the gallery floor. Be honest about its cost, though — an offline exhibit is safer to run but harder to rebuild, because when you finally do reconnect to the ecosystem, it has moved on without you.
Desktop-native code (C++ / openFrameworks / Cinder)
A compiled, self-contained desktop application is the binary that still runs in year ten. Desktop-oriented stacks survive operating-system churn far better than browser-based ones — Windows updates rarely break a self-contained executable, and when they do, the fix is a rebuild, not a re-architecture. The trade-offs are honest: a smaller talent pool, slower iteration, and interface work built from scratch rather than inherited from the web platform.
When it’s right: sensing-heavy, real-time, long-lived installations — especially where on-site technical staff is minimal and the software needs to be an appliance, not a service.
Game engines (Unity, Unreal)
Game engines bring real-time 3D and sensor integration that neither of the other stacks matches, and a compiled desktop deployment inherits most of the desktop stack’s durability. The risks are different in kind: licensing exposure (Unity’s 2023 runtime-fee episode taught the whole field that an engine’s business model is part of your dependency tree), editor lock-in, and version-migration cost. The mitigations are also different: engine versions can be pinned for the life of an exhibit, so the migration cost is scheduled and controllable in a way web-ecosystem churn is not.
When it earns its place: real-time 3D, projection, and computer-vision-driven work where the engine’s capabilities are the point.
What we actually do
Our default for the gallery floor is compiled, desktop-class software — most of it built on Unreal Engine through Fusion, our toolkit for public computing. We use web technology where the deliverable is genuinely of the web — virtual tours, remote experiences — or where an institution operates a staffed digital program that can own it.
The structural decision that matters most: we separate the layer that changes often from the layer that shouldn’t. Content lives in a content-management system (Galaxy) that museum staff edit directly; the exhibit software underneath is stable, pinned, and boring on purpose. Curators change what the building says without anyone touching code — which means the fast-moving layer is staffed by the people who already own it. And when content updates are genuinely nobody’s job, we say so and build fixed content instead — a CMS no one will log into is pure ownership cost (we take that argument up in the ownership guide).
What this costs us, honestly: interface iteration is slower than a web team’s, the hiring pool is smaller, and we build UI primitives ourselves that a browser would have given us for free. We pay that bill at design time because the alternative is your staff paying it every quarter for a decade.
If you’re the museum: what to demand
Ask every firm bidding your project one question: who applies the operating-system update in year four, and what happens when it breaks something? The answer tells you whether they’ve thought past opening day.
Then write the maintainability requirements into procurement: source code and documentation handoff, a dependency inventory, pinned-version builds, content that your staff can update without a developer, and an explicit statement of what maintenance capacity the bid assumes your institution has. The decade-scale consequences are the subject of our companion guide, What does an interactive cost to own?