# Electric Clojure: letting the compiler find your frontend and backend boundary

> A ClojureScript and Clojure system that compiles one program into a client and a server target by analysing the dataflow graph, so the network boundary is inferred rather than hand written.

**hyperfiddle/electric** — Electric Clojure: full-stack differential dataflow for UI

- Repository: https://github.com/hyperfiddle/electric
- Stars: 2,141 · Forks: 56
- Language: Clojure
- License: not declared
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/hyperfiddle-electric

## One program, two compiled targets, no hand written boundary

Electric starts from a problem with request and response frameworks: interactive products end up with frontend and backend network plumbing written by hand, and that plumbing only gets worse as the codebase grows. The stated symptoms are specific. Request waterfalls, over-fetching and under-fetching, large payload deserialization, all of it scaling badly with the size of the database behind the app.

The approach is to not write the boundary at all. In Electric, client and server expressions compose directly, in the same function, and the compiler macros infer the implied frontend and backend boundary at compile time and generate the full-stack app. The README describes the mechanism as a custom ClojureScript and Clojure compiler performing deep graph analysis of your unified program to determine the implied network cut, then compiling that program into separate reactive client and server target programs that cooperate and anticipate each other's needs.

That is the whole thesis, and it is worth being precise about it, because it is not the same claim as end-to-end type sharing. Nothing here says the compiler verifies that both halves agree on a schema. It says the compiler finds where the cut belongs and choreographs the two sides around it. Whether that is what you need depends on whether your pain is boundary bookkeeping or contract safety.

## Reactivity built into the language instead of a library

The second headline feature is that reactivity is part of the language rather than something you add. The README lists reactive-if, reactive-for and reactive lambda, and makes a point of there being no observables and no async types. The line the README uses is that when everything is reactive it feels like nothing is reactive.

Compared with a JavaScript framework, the difference is where the knowledge lives. In a JavaScript app, reactivity is a runtime library you import, and the boundary between reactive and imperative code is a discipline you maintain by hand, which is why the README frames the alternative as goodbye functional core imperative shell. Electric's claim is that the entire system is a function, with lambdas, recursion, higher order functions, closures, dynamic scope and macros all intact.

Composition is the part that actually matters day to day. An Electric function that crosses the network boundary is still a real function rather than a serialisable descriptor, and closures can close over bindings from either side. If you have written a Lisp before, this is the property that would make you consider the project, because it is the property most cross-boundary frameworks give up in order to move data.

## Depending on Electric v3 and the JavaScript test harness

The dependency coordinate at the top of the README is the whole install story, and it is worth reading carefully:

```clojure
com.hyperfiddle/electric {:mvn/version "v3-alpha-SNAPSHOT"}
```

That is a snapshot dependency. There is no stable version to pin, the repository publishes no GitHub releases, and there is no tagged artifact in the usual sense. Everything downstream of Electric, including your own lockfile, is tracking a moving commit. For a library that rewrites how your program is compiled, that is a serious operational consideration rather than a footnote.

The JavaScript side of the repository is small and test-focused. package.json carries four dev dependencies, all of them test infrastructure rather than runtime code:

```json
"karma": "6.4.0",
"karma-chrome-launcher": "3.1.1",
"karma-cljs-test": "0.1.0",
"puppeteer": "15.2.0"
```

Karma drives a headless Chrome through puppeteer to run ClojureScript tests in a real browser. There is a karma.conf.js at the root and a shadow-cljs.edn, which is the standard ClojureScript compilation setup, plus a .node-version file pinning the Node version. The build directories are split into src for the library, src-build and src-dev, and the tree also carries .cljfmt.edn, .cljstyle, .clj-kondo and .projectile, so linting and formatting are configured rather than left to convention.

## Where the documentation actually lives

The README is unusually candid about this. It has no project website, no documentation site, and no badge row. Instead it links four things at the top: a Google Doc for the mission statement, product overview, license and community, a second Google Doc for the tutorial and reference, a starter app repository, and a Twitter account for updates.

That is a real constraint on evaluation. Two Google Docs are where you would go to learn the syntax, and they are documents rather than a versioned, searchable, linkable documentation site. The starter app at hyperfiddle/electric3-starter-app is arguably the more useful of the two links, because a working example of a compile-time system teaches you more than prose does.

The README does point at two external explanations of the dataflow model: a 2022 post called UIs are streaming DAGs, which the README describes as a ten minute video explainer of how the system works, and two recorded talks, a five minute lightning talk and a thirty minute explainer at reClojure 2025. The DAG framing is the one to sit with, since it is the mental model behind the whole design.

## Licensing, project age, and who should not use it

Two facts decide this for a lot of teams before any technical question gets asked. The first is licensing. The README has a License section that says Electric v3 is free for bootstrappers and non-commercial use but is otherwise a commercial project, and it gives the reason, that this funds payroll for a team of four. It links a license change announcement as well. There is no LICENSE file in the repository tree and no SPDX identifier in the metadata, so the operative terms are the ones described in that README section and in the linked announcement, and anyone using this commercially needs to read both rather than infer terms from the repository.

The second is project age. The default branch is master, the last push recorded is 2026-03-28, and there are no releases to speak of. Alpha stage is stated plainly by the snapshot version itself. None of that makes the project bad, and the ideas have been public long enough to have talks and a paper trail, but it does mean you are adopting a compiler whose interface may still move.

The wrong reader is someone who wants a stable, documented, widely adopted framework with a conventional API and a licence they already understand. The right reader is a Clojure shop with a genuinely dataflow-shaped UI problem, enough patience to read a tutorial in a Google Doc, and a product decision that does not require open source licensing.

## Conclusion

Electric makes sense for a team that already lives in Clojure or ClojureScript and has hit the wall where the frontend and backend have to agree on a network protocol by hand. If that is you, the appeal is real: one expression, one function, one file, and the compiler slices it. If you are choosing a framework from scratch in another language, the compiler you would be adopting is a custom ClojureScript macro compiler, and the documentation for it lives in two Google Docs rather than on a docs site. Verify three things before committing: that the license terms suit you, since the README describes Electric v3 as free for bootstrappers and non-commercial use and otherwise commercial; that the artifact you depend on is the v3 alpha snapshot rather than a stable release, since the repository publishes no GitHub releases at all; and that you are prepared to track a project whose last push was on 2026-03-28, because that is the most recent commit the repository records.

## FAQ

### What is Electric Clojure?

It is a full-stack differential dataflow system for building interactive web UIs, where client and server code is written together and a custom compiler infers the network boundary at compile time. The compiled output is a reactive client program and a reactive server program that cooperate.

### How do I add Electric to a Clojure project?

The README gives the dependency coordinate `com.hyperfiddle/electric` at version `v3-alpha-SNAPSHOT`. Note that it is a snapshot, so there is no released version to pin and your build tracks the latest commit of that branch.

### Is Electric Clojure free to use in a commercial product?

The README states that Electric v3 is free for bootstrappers and non-commercial use, and is otherwise a commercial project which funds payroll for a team of four. Commercial terms are covered by a linked license change announcement.

### How does Electric avoid the request waterfalls a normal frontend and backend split would cause?

Because the cut between client and server is found by static graph analysis rather than declared by hand, the two compiled halves can anticipate each other's needs. The README points to a short explainer on UIs are streaming DAGs for the mechanism and argues the waterfalls do not appear even with deep nesting, loops and control flow.

### Where are the tutorial and reference for Electric?

The README links a Google Doc for the tutorial and reference and a separate one for the mission statement and product overview, plus a starter app repository at hyperfiddle/electric3-starter-app. There is no documentation website; the docs are these documents and two recorded conference talks.

## Sources

- [hyperfiddle/electric on GitHub](https://github.com/hyperfiddle/electric)
- [Issues](https://github.com/hyperfiddle/electric/issues)
- [README](https://github.com/hyperfiddle/electric/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hyperfiddle-electric