re-frame-10x: a dashboard for looking inside a running re-frame app

One epoch at a time, because a re-frame app is a chain of dominoes

re-frame-10x lets you instrument, and then inspect, the inner workings of a running re-frame application, presenting itself as a programmer's dashboard.

The design idea underneath it is the epoch. The README describes re-frame applications as computationally regular: first an event happens, and then a series of known computational steps, the dominoes, follow in a known order, and when the chain reaction completes the app enters a quiescent state waiting for the next event.

Each re-frame event and its consequent computation forms a bounded epoch which can be inspected, analysed and understood independently of other epochs. The tool is epoch-oriented, and it shows you one epoch at a time.

There is a time travel debugger aspect, since you can go backwards and forwards through epochs, and the README is clear that this is not the most interesting or powerful part of what the tool delivers. That is a fair piece of self-assessment. Being able to step back through a chain reaction is useful, but the real value is in seeing one epoch in full detail: what triggered it, what ran, and what the data looked like on the way through.

The audience is a developer inside the ClojureScript and re-frame ecosystem, and the topics tag names the tools it sits alongside: re-frame, reagent and tracing. The primary language is Clojure, the licence is MIT, and the current release is 1.12.3 from 2026-05-05 with the last push on the same day.

It is a consumer, a processor and a presenter of trace data

The README describes the tool in three layers, and they are worth taking in order because each answers the one before it.

At the most basic level, re-frame-10x is a consumer, processor and presenter of trace data. As it runs, re-frame logs trace as data, and the README calls that an x-ray of the app's inner functions.

The second layer is the data flow. re-frame is a functional framework, but its design is data oriented: it flows data, in a loop, through the functions you provide. To understand what is happening in a re-frame app you have to understand what data is happening, and that framing is what the tool is built around.

The third layer is the dashboard. Observing the raw trace is interesting and valuable, but it is not enough on its own. The first thing you want is insight derived from the data, and the second thing is that there is often too much data, so you can drown in the detail. The dashboard is the answer: it curates raw data into information through various kinds of analysis and roll ups, delivering insight at a glance while still letting you drill down into the detail.

That is a well-judged design, and it is the reason the tool is more than a trace viewer. The data is already there because re-frame produces it; the contribution is in curating it and in putting a UI on it.

One further argument in the README is about why data matters more generally. Every time you put a println into a program you are printing data to fuel your debugging investigation, and when you write unit tests you represent your expectations as data too, because code is proved correct by the data it produces. The conclusion is that for debugging and understanding, more data more easily is the winning approach, and if the tool does its job you should not need to add printlns. The data you need should be captured and presented, and if further experimentation is needed it should be available in your REPL too.

Learning, codebases, debugging and performance are four different jobs

The README lists four ways the tool helps, and the ordering is deliberate.

It helps you to learn re-frame. Simply looking at the raw traces provides insight into how it operates, and the author notes that even experienced re-framians have learned a lot this way.

It helps you to explore and learn an unfamiliar re-frame codebase. The example given is specific and is the feature that distinguishes this from a generic trace viewer: clicking an X button shows what event is dispatched and in which namespace the associated event handler is registered, and then a note about four subscriptions being recalculated. The information about where a handler lives is the sort of thing that is genuinely hard to recover by reading source, and it is what makes a codebase navigable.

It helps you with debugging, giving an x-ray of the app's functioning, and in particular it helps you write and debug event handlers, which is useful because event handlers hold most of the logic in re-frame apps. The README says this point is primary.

It helps you find performance problems or detect where unnecessary computation is occurring, which follows from the subscription recalculation counts being visible.

The second point is called almost as important as the third, on the grounds that a lot of time is spent grokking unfamiliar codebases. Being able to observe the inner workings of a running app is a way to bring code to life, reveal key features and build a cognitive map of the structure.

There is a caveat in the README that any adopter should read before anything else, because it qualifies all four claims. Some of the claims above are aspirational, and the project remains a work in progress, with a link to the discussion where that is tracked.

Configuring it is per project, and three prerequisites are not optional

The configuration is per project, and the README makes a point of the social dynamics involved: only one person in your team needs to configure a project to use it, and then everyone else can benefit.

That is a meaningful operational claim. Instrumenting a re-frame app is not a per-developer preference like a REPL alias, it is a project-wide change to the build, and the note tells you the intended adoption pattern.

The installation section then gives hard requirements, and they are not suggestions.

You must have a :main specified in your :compiler config, or an entry in :modules for shadow-cljs, for the :preloads and :closure-defines to take effect. You must be running with the Closure define goog.DEBUG as true, which the README says is the default under :optimizations :none. And there is a third requirement that the visible README text truncates mid-sentence, so the full list is worth reading in the repository.

The goog.DEBUG point is the one that catches people. A production ClojureScript build uses advanced optimisations, and in that mode the define is false, so there is no trace data to display. The tool therefore only works in a development build, which is correct for a debugging dashboard but means you cannot inspect a deployed application.

The project supports both Leiningen and shadow-cljs, and the README suggests looking at a sample project.clj when puzzling over the configuration. The repository carries both project.clj and shadow-cljs.edn alongside deps.edn, plus source-deps.sh, so all three build paths are represented.

The package.json in the repository is only the test runner configuration, and it says so explicitly: the library itself ships via Clojars, not npm. The npm side has shadow-cljs as a dev dependency along with React and React DOM, and the Clojars coordinate is day8.re-frame/re-frame-10x.

The repository is set up for both Clojure and ClojureScript contributors

The top level listing shows a repository with a full development setup rather than just a library source tree.

There is a src/ directory and a gen-src/ directory, which together suggest that part of the source is generated rather than hand written. There is a test/ directory and a test-resources/ directory, and an examples/ directory whose one entry is a todomvc application, which is the conventional reference app for a ClojureScript library and therefore the obvious first thing to run when you want to see the dashboard populated with something real.

The tooling configuration is thorough. There is a .clj-kondo/ directory for the ClojureScript linter, a .claude/ directory and an AGENTS.md at the root, a .beads/ directory, a CHANGELOG.md, a DEVELOPERS.md and a docs/ directory with the images the README embeds. The docs/images/ directory holds the screenshot of the subscriptions view that the README shows as its main illustration.

The project builds on multiple toolchains, and this is worth noting for a contributor. project.clj for Leiningen, shadow-cljs.edn for the shadow-cljs build, deps.edn for the ClojureScript tooling, and a package.json for the npm side of the ClojureScript test runner. The CHANGELOG.md and the three releases published on 2026-05-04 and 2026-05-05 suggest a project in active day to day work rather than a dormant library.

The README also carries a long, self-aware account of how the project got its name, which is a good sign about the maintainer's attitude to the project even where the documentation is informal. The name went through re-frame-trace, vox-datum, -insight and -illumination before landing on -10x, on the argument that a 10x programmer starts by having ten times more knowledge and insight.

Where re-frame-10x is the wrong tool

The first wrong-tool case is a production incident. The goog.DEBUG requirement means the instrumentation only produces trace data in a development build, so a dashboard that can show you what happened in a running application is not something this tool can do. If your need is post-mortem analysis of a deployed system, you need tracing that survives the optimised build, and that is a different design.

The second case is a project that is not using re-frame. Everything the tool presents, epochs, event dispatch, subscription recalculation, handler registration namespaces, is specific to re-frame's architecture. In a plain React or a Reagent app with no re-frame layer, there is no epoch to show.

The third case is a team that needs a supported, documented tool. The README says plainly that some of the claims are aspirational and that the project remains a work in progress, and it links the discussion where that is tracked. That is honest, and it is also a statement about the maintenance commitment. A team shipping a product on top of it should read that discussion before deciding.

There is a fourth consideration that the tool itself raises. The README argues that the data you need should be captured and presented, and that you should not need to add printlns. That is a good goal, but a dashboard that shows you every trace in a large application is not free either, and the cost of collecting and holding that data in a development build is something the project does not quantify in the visible documentation.

For a learning or exploration context, though, the trade is clearly worth it. The README's own first use case is the one with the lowest bar: looking at raw traces to understand how re-frame operates. Nothing about that requires the tool to be complete, only to show the data, and it does that.

Editorial conclusion

re-frame-10x suits a ClojureScript developer working in re-frame who is either learning the framework, taking over an unfamiliar codebase, or chasing a performance problem, because the trace data it already collects replaces scattered print statements and shows recalculations you would otherwise have to infer. It does not suit a team that needs a stable, documented tool, because the README says outright that some of the claims are aspirational and that the project remains a work in progress. Before adopting, check the three prerequisites in the installation section, in particular that your build runs with goog.DEBUG as true, since without that the instrumentation has nothing to work with.

Frequently asked questions

Official sources

1. day8/re-frame-10x on GitHub
2. Issues
3. License: MIT
4. README
5. Releases