Case study · pioneered 2016
A web interface for control systems, before control systems had one.
In 2016, almost no scientific facility ran a browser-based interface to its control system; operators sat at native desktop clients wired to the hardware. Waltz was among the first to put that interface in a browser, for accelerators, synchrotrons, and neutron sources running Tango Controls and other middlewares. Building it early meant solving problems the ecosystem had no patterns for yet, and three of those solutions outlived the application itself.
What outlived the app
A web application is rarely the durable part of an engineering effort. The durable parts of Waltz were the libraries underneath it, each one a solution to a problem that had no off-the-shelf answer in 2016, each published and reusable independently of the host application.
A reliable Server-Sent Events source
Control systems push a continuous stream of attribute changes; an operator UI that
polls for them does not scale and does not stay current. The browser's native
EventSource reconnects, but it does not recover missed events, dedupe
across reconnects, or multiplex many logical subscriptions over one connection.
The SSE event-source library solved those gaps so the rest of the application could
treat a live hardware stream as a dependable feed rather than a best-effort one.
An event-bus SPA middleware
Rather than adopt a heavyweight framework, Waltz runs on a thin middleware built around a central event-browser object: an internal bus that routes messages between independently developed components. Components never call each other directly; they publish and subscribe. That decoupling is what later made framework-agnostic plugins possible, because a plugin only needs to speak the bus protocol, not share the host's component model.
A framework-agnostic plugin model
Widgets register against the bus at startup and resolve at render time. Because the contract is the message protocol rather than a shared component base class, widgets written in different frameworks coexist in one running application: the production build ships Webix widgets, CodeMirror, and Plotly side by side, and the same model accommodates React or Angular widgets without changing core code. A facility adds its own instrument widget without forking the platform, and that widget survives the next upstream release because nothing in core imports it.
The boundary contract
Underneath the plugin model sits the Tango REST API specification, written as a formal
document before the server code that implemented it. Any conforming server worked with
Waltz; any conforming client worked with any conforming server. The spec was adopted
across the Tango Controls community as the standard interface between web clients and
control systems. This is the same instinct as the strategy_spec.json in
the trading platform: when components deploy independently, the boundary is a
documented data contract, not shared code.
Leaving the method behind
Three workshops at DESY in 2019 brought developers from multiple facilities together to build extensions collaboratively. The goal was not adoption metrics; it was making sure maintainers elsewhere could diagnose and fix issues without routing everything through the original author. The architecture made that possible because the libraries and the plugin contract were independently documented and independently versioned.
Numbers
Stack
JavaScript · RxJS · Webix · CodeMirror · Plotly · webpack · Server-Sent Events · REST · Docker · Tomcat · Tango Controls · EPICS · TINE · DOOCS