When not to use Fulcro?

Applications that do not have a backend, or where you only care about rendering data you already have, or where the operation is very limited. You can very well still build it with Fulcro, and if you know it well and are comfortable with it, it will still be the best choice for you, but you won’t benefit from most of what Fulcro has to offer. You can perhaps consider a simple React wrapper, such as Helix.

If you don’t want a Single-Page Application, then perhaps you should rather explore something like htmx or a DIY simple app.

If you do not control the backend but are given a REST or GraphQL API, you will need to do extra plumbing to use Fulcro. It doesn’t necessarily make Fulcro a worse choice then other solutions, because those will likely also require plumbing to fit the given API to their model. But it is more work and you are less productive and efficient then if you control the backend and can build it with Pathom.

(Remember that you can also use Pathom on the frontend, and it has been used to adapt both REST and GraphQL APIs.)

Fulcro’s assumption is that there is a general data store (such as an SQL database or Datomic) and that the UI decides what data it needs. If it is the reverse, and the backend has a fixed idea of what data and in what form should displayed, then Fulcro’s component queries are a pointless duplication. You could simply make every query ['*] i.e. "give me everything", but you likely also don’t need normalization (see the next point) and it is a question of what value provided by Fulcro still applies.

Fulcro’s data normalization is great to make finding and modifying data trivial, and to ensure that a change is visible everywhere. If this isn’t relevant for your application then a lot of the value of Fulcro is wasted.

A key assumption in Fulcro is that the UI is somewhat static and we can code a compile-time tree of components and their queries. If your UI, or a significant part of it, cannot be defined at compile time but only at run time, probably because it is heavily data-driven, then again you only leverage a portion of the value that Fulcro offers. You can still build pretty dynamic UIs, with recursive queries, dynamic queries, and React hooks (primarily use-component), but you really need to know what you are doing and be sure that Fulcro is still a good tool for the job.

Fulcro’s author has actually used it to build a 3D game board platform leveraging three.js, but not everybody is Tony Kay. Let me quote him, because it is interesting:

That said, if you have only small parts that are dynamic (only defined at run-time), then Fulcro has you covered. See e.g. Fulcro RAD’s ToOnePicker for related entities or the Fulcro cookbook’s recipe Solving mutually recursive elements with lazy loading with hooks and dynamic components and its DynamicRecipe component.

If most of your job is putting together existing React components, and especially if those are higher-order components, then the accumulated price of ClojureScript’s JS interop and Fulcro’s React interop may not be worth the benefits anymore. You might be better of writing your app in TypeScript.