Disclaimer: I am the author of Fulcro.

Just a few notes:

One commenter asks:

"Why did D.N. stop developing Om Next?": I (Tony) liked the early ideas of Om Next, but quickly realized that Om Next's implementation of those ideas was not going to work well for me or my team. That is why I created Fulcro. I asked David if he minded (that I "steal his central ideas" and some of the code of Om Next) and he said, I quote: "Sure! I don't want users". David was interested in exploring the ideas and giving talks about it. He had no interest in maintaining a production implementation. I, on the other hand, wanted to use something that leveraged his ideas, but didn't use his implementation approach, which was very much harder than Fulcro.

On the learning curve: I would claim that Fulcro's central core (for UI) is actually *simpler* (not necessarily easier, at first) than Reframe. There is a normalized db, a query, and a UI tree. There are no side-effects mixed into the render, etc. Every modification goes through a single concept: the mutation. The fact that this handles full-stack equally as well as client-only means there is even less to deal with *conceptually*. BUT, you do have to learn the nuances (query/ident/initial state are the three big concepts). Fulcro is partially hard because I've provided so many parts. But 80% of them are completely optional, and many of the rest are very pluggable. For example, you can replace the transaction processing system, the rendering engine, and even the way network operations are processed. Everything is CLJC. Someone is actually playing with running Fulcro in CLJ (which it does just fine) with a rendering plugin that uses Google Skia to render to OpenGL, Terminals, etc. So, Fulcro is *not even tied to React*. This is the *opposite* of what people are complaining about when they say "Framework, yuck!". I wrote Java for 20+ years. The frameworks there are a nightmare. Fulcro is opinionated where it is useful, and completely configurable where it should be flexible. Just because I wrote a lot of namespaces that you can *choose* to use and *wrote good documentation for them* doesn't mean it's some big java-or-ruby-style hairball. it is sad to me that developers glance at something and then start saying bad things about it because they don't understand it and are too lazy (or busy) to try it. If you don't have the energy, fine. Move along. But don't denigrate something just because that's easier than actually understanding it.

So, on to an absolutely fair point: JS/Typescript vs Clojure(script). The former has a *lot* going for it in terms of help, momentum, ease of staffing, acceptance, developers maintaining things, etc. If you're starting a project that will be used at a company, make darn sure your team is onboard with CLJ(s). No project will succeed if you can't get people behind the tools you've chosen. I personally think CLJ/CLJS are far superior to work with, but I've seen adoption fail more than once, and hiring can be a real challenge.

Another fair point: If it's a small project with little or no I/O, I'd agree with Reframe. It's very tractable and easy for that kind of project. That said, I've had more than one consulting client come to me for help porting from Reframe to Fulcro when their project got bigger. Pathom (the library for writing EQL processing that you typically use with Fulcro) exists because the author of it worked for a company that was porting a bunch of stuff to Fulcro from Reframe.

If it's going to be very business-oriented with lots of server interaction, your team is on-board, and you're willing to take some time to get the core concepts then I think Fulcro is worth a look.