Fulcro is a ClojureScript full-stack framework where the UI follows the data graph

Data-driven means the UI is derived, not authored

Fulcro is a library for building data-driven full-stack applications for the web, native and desktop through Electron. It uses React and is written in Clojure and ClojureScript.

The data-driven framing is the part that distinguishes it from other ClojureScript React wrappers. Rather than components owning their own state and passing props down, the application state is a graph and the rendered components are derived from a query over that graph. The consequence is that adding a field to a component is a change to a query rather than a change to a parent, and the same query shape serves the client and the server.

The topic tags reflect that emphasis: `data-driven`, `full-stack`, `reactjs`, `web-application-development`, `clojurescript`. One repository carries both halves, which is why the project has a `build.clj`, a `pom.xml` and a `deps.edn` alongside a `shadow-cljs.edn` and a `package.json`. It is published as a Clojars artifact under the `com.fulcrologic` group.

Fulcro's pitch is the elimination of the impedance mismatch between what the server holds and what the client renders. The cost is that your components stop being self-contained, so a component written in isolation is harder to reason about.

The 3.8 break is in your development build, not your production one

There is one notice that dominates the README, and any evaluation should start there.

Fulcro 3.8 and later use a new version of Fulcro Inspect, and it requires you to change how you build the development version of your app. The README states it directly: old versions of Fulcro Inspect Electron and Chrome will not work with Fulcro 3.8 or later. The rewrite of Fulcro Inspect is available from the releases page of the fulcro-inspect repository, and there are preliminary instructions for using it with the latest Fulcro.

The alpha status is scoped rather than general. The README says the 3.8 alpha versions are alpha purely because of this development-time change and its potential issues, and are otherwise production ready. That is a useful distinction: the uncertainty is about your dev loop, not about runtime behaviour.

There is a migration path documented for the major version jump as well. `PORTING-FROM-2.x.adoc` sits at the repository root for people coming from Fulcro 2, and the prior version of the Developer's Guide remains available for reference.

Fulcro Inspect itself is the part you will feel most if you skip this.

Running the test suite tells you what the toolchain costs

The Makefile at the root is the shortest description of the development stack, because the `tests` target runs every layer in order.

tests:
	pnpm install --frozen-lockfile
	pnpm exec shadow-cljs -A:dev compile ci-tests
	pnpm exec karma start --single-run
	clojure -A:dev:test:clj-tests -J-Dguardrails.config=guardrails-test.edn -J-Dguardrails.enabled -J-Dcom.fulcrologic.fulcro.inspect=true

Four tools in sequence: pnpm to install, shadow-cljs to compile the ClojureScript test namespace, karma to run the result in a browser, then a Clojure JVM run for the server side and ClojureScript tests. The `dev` target runs the Clojure test command with the Guardrails properties plus `--watch --fail-fast --no-capture-output`.

The JVM system properties in that command are more informative than they look. There is a separate `guardrails-test.edn` next to `guardrails.edn`, and `.clj-kondo/` plus `.cljfmt.edn` in the root cover linting and formatting. `.fulcro-spec.edn` is Fulcro's own project configuration.

The JavaScript side of the stack is small and pinned: React and ReactDOM 19.1.0, shadow-cljs 3.1.6, karma 6.4.4 with the Chrome launcher and karma-cljs-test, and transit-js for Fulcro's transit serialisation format. `karma.conf.js` holds the browser test configuration, `pnpm-workspace.yaml` and `pnpm-lock.yaml` the workspace, and `tests.edn` the Clojure test aliases. The root `package.json` is named `fulcro` with the description "Testing", which confirms it exists for the test harness rather than for distribution.

Documentation is split across a book, a template and a community site

There is no documentation directory that tells you how to use the library; the README routes you elsewhere in three directions.

The Developer's Guide at book.fulcrologic.com is the main documentation for this version, and the prior version of the guide at book.fulcrologic.com/fulcro2 is still readable if you are on Fulcro 2. The project home page is fulcro.fulcrologic.com. For a starting point rather than prose, the fulcro-template repository is a template project you can use as a beginning, which is usually faster than reading a book before your first component.

The Fulcro Community site collects resources, and there is a `docs/` directory in the repository holding the logo and site sources along with `fulcro-in-clj.md`, a note on using Fulcro from Clojure rather than ClojureScript.

Two smaller signals about how the project is run. CircleCI is the continuous integration provider, referenced from the README badge against the `main` branch, and `CHANGELOG.md` at the root is where changes are recorded. There is also a `CLAUDE.md`, consistent with the agent tooling files that have become common in actively maintained Clojure projects.

There are no GitHub releases for the project itself, so version tracking runs through the Clojars artifact and the changelog rather than through tags.

Where Fulcro is the wrong choice

The clearest case against is a team without ClojureScript experience. Fulcro assumes you are comfortable with a compile step for the client, a JVM for the server, shadow-cljs for the build and Guardrails for static checks on top. That is four tools to learn before the first component renders, and the data-driven model means the concepts you need are not the ones you would carry over from React.

The second case is a project that needs many bespoke components. Because components are derived from queries over shared state, a component that is reusable only by pulling in a slice of the application graph is not really a component. In a design system context, that is the wrong shape, and plain Reagent or React with props is a better fit.

The developer tooling dependency is also sharper than for most libraries. If Fulcro Inspect is central to how you work and you are on 3.8, you need the matching rewrite, and the README calls the instructions preliminary. A team that treats their inspector as essential is accepting a moving target.

The project publishes to Clojars and records changes in `CHANGELOG.md`, but with no GitHub releases there is no tag to diff when a build breaks, so version pinning for a production app means tracking the Clojars coordinate and reading the changelog yourself.

Licensing is the easy part: MIT, with copyright held by Fulcrologic, LLC covering 2017 through 2022.

Editorial conclusion

ClojureScript teams that want one data model spanning the client and server, with a React renderer underneath rather than a second view layer, should evaluate Fulcro against its own guide and the fulcro-template starting project. Teams on React with a different state approach have no reason to move, and anyone unwilling to absorb a cljs toolchain should stay where they are. Before starting, read the 3.8 notice, because old Fulcro Inspect Electron and Chrome builds do not work with it, and run the test target in the Makefile once to confirm the shadow-cljs and karma setup works on your machine.

Frequently asked questions

Official sources

1. fulcrologic/fulcro on GitHub
2. Issues
3. License: MIT
4. Project website
5. README