Posts Tagged ‘DustinGetz’
[reClojure2025] Electric Clojure: Differential Dataflow for User Interfaces
Lecturer
Dustin Getz is the founder of Hyperfiddle and the primary architect behind Electric Clojure. His professional mission is to “collapse to zero” the cost of internal frontend development for business applications. With a background in distributed systems and concurrency, Dustin has spent years researching how to apply these low-level technical concepts to higher-level UI infrastructure. He is a frequent speaker at Clojure conferences, where he demonstrates how rethinking the computational structure of web applications can eliminate the complexities of traditional client-server architecture.
Abstract
Electric Clojure represents a paradigm shift in web architecture, moving away from the traditional separation of frontend and backend towards a unified, cloud-connected model. This article explores how Electric frames the user interface (UI) not as a series of manual network requests and state updates, but as a concurrency problem solvable through “differential dataflow”. By applying process supervision and structured concurrency, Electric achieves a UI = f(state) model that remains consistent across the network boundary. Through an analysis of Electric’s core principles, this article highlights how it addresses the “supervision problem” and optimizes network traffic through automatic differential updates, ultimately simplifying the development of complex, data-heavy applications.
Rethinking the Computational Structure of UIs
The fundamental premise of Dustin Getz’s work is that modern UI development is hindered by an incorrect computational structure. Most web applications rely on a manual bridge between the client (browser) and the server, involving REST or GraphQL APIs, manual state management (like Redux), and complex error handling for network failures.
Electric proposes a different structure based on differential dataflow. While React introduced the idea that the UI is a function of state, it is typically confined to the browser. Electric extends this concept across the entire network. In an Electric application, the code is written as a single, continuous program where the compiler automatically determines which parts of the code should run on the server and which should run on the client.
Solving the Network Boundary Problem
The “network boundary” is where most web applications fail or become overly complex. Electric addresses this by treating the connection between the client and server as a reactive data stream. Key innovations include:
1. Automatic Differential Updates: Instead of sending entire data objects over the wire, Electric only transmits the “diffs”—the specific changes in state. This high-frequency, high-fidelity communication is essential for maintaining a responsive UI in data-intensive environments.
2. Process Supervision: Electric applies Erlang-style supervision trees to UI components. If a server-side process fails or a network connection drops, the system can automatically recover and resume the UI state, solving the supervision problem that plagues traditional distributed web apps.
3. Reactive Back-pressure: By integrating differential dataflow, Electric manages the speed of data flow. If the client cannot keep up with the server’s updates, the system applies back-pressure to ensure the application remains stable and doesn’t “clobber” the browser’s resources.
Code Sample: Unified Frontend/Backend
(e/defn MyComponent [id]
;; This part runs on the server (accesses DB)
(e/server
(let [user (db/find-user id)]
;; This part runs on the client (renders UI)
(e/client
(dom/div
(dom/h1 (str "Hello, " (:name user)))
(dom/p "This data came directly from the DB!"))))))
Implications for Internal Tools and Enterprise Scaling
Dustin identifies a massive opportunity for this architecture in internal enterprise applications. Companies with thousands of microservices often struggle to build scalable UIs that can aggregate data from multiple sources. By placing an Electric “agent” in each microservice, developers can call backend Java or Clojure functions directly from a UI as if they were local calls.
This “UI Spreadsheet” model, as Dustin describes it, allows for native navigation of backend data structures. During his demonstration, he shows how a UI can query a git repository using the Java Git API (JGit) in real-time, displaying a git log through a scalable data browser without a single manually-written API endpoint. This approach collapses the traditional tiers of web development into a single, cohesive abstraction that composes across microservice boundaries.