Quite a few people have had those thoughts. So far, it has resulted in some new libraries but nothing that would truly take off, for one reason or the other.

The changes to react (ie adding hooks) have meant that clojure wrappers around react can be much lighter weight - e.g. uix and helix are lighter weight and more aligned with react than reagent. They also allow easier interop with the rest of the react ecosystem. I do see some growing criticism of react (and virtual dom in general) around its slow performance and complexity, which makes me think that clojurescript with react could be viable for some apps. One approach to eliminating react that has some momentum is - server side rending with hiccup + clojure - then using https://github.com/bigskysoftware/htmx and https://github.com/bigskysoftware/_hyperscript to add some extra interactivity. This can be much simpler than SPA architecture and does better for SEO.

I do not think Lisp is the issue. ("LISP"? You must be as old as me! 👨‍🦯 ). I think the problem with React, ironically, is that they skimped on reactivity in the beginning, went with fake reactivity aka VDOM ("don't worry, just repaint everything, it will be fast"), and eventually came around to rejecting reactivity explicitly, so they could be in control of rendering. They jokingly proposed a name change to ScheduleJS. I digress. The immutability thing does work great with knowing when to setState or blow off rerendering (forget the lifecycle method), but then you have the other React problems anyway, so it is. a mixed blessing. The wonderful thing about CLJS is that it was "done" the day it shipped, and they did a great job with the execution. JS is doing great things lately, but churn. Back to digressing, because they faked reactivity, they struggled with inconsistent state, and to solve that they saddled the world with Flux, which became Redux, which sank the good ship productivity with boilerplate. What makes React unnecessary are truly reactive frameworks such as the original MobX (JS), SolidJS, binding.scala, and my upcoming Web/MX. (You knew there was a catch to this rant.) https://kennytilton.github.io/web-mx-quickstart/

Adding to the original thread question, I think https://github.com/thheller/shadow-grove is one example of asking the question "what if we built a React-like system, but leaning more into ClojureScript idioms". Check out the docs for some reasoning behind the design choices: https://github.com/thheller/shadow-grove/tree/master/doc I think one of the reasons why a lot of the libraries that are experimented on in CLJS-land as alternatives to React never catch on as the one true React-killer, is just due to sheer number of React-specific UI widgets available in NPM. If you build from scratch, you need to build everything from scratch.

That, and also sometimes design choices do not reflect the needs of real-life projects - for the case of shadow-grove, see https://clojurians.slack.com/archives/C03NTBBSF46/p1675812058640829?thread_ts=1675800678.926309&cid=C03NTBBSF46 and below.

(The preview makes it seem as if it's about shadow-grove itself, but they way I understood it it's about some particular pieces of it, which is nonetheless important).

re-frame is the GUI framework, figwheel.main the build tool. You can also build re-frame apps with Shadow CLJS. I will let others more knowledgable than I address the Angular question, but this looks promising: https://github.com/lynaghk/todoFRP/tree/master/todo/angular-cljs

I disagree on "re-frame is a GUI framework". It's a system to handle web application's state and user-interations, "state handling framework" maybe.

@U04R4718WAJ Good point! I always conflated the GUI with the re-frame framework, but that is wrong. And come to think of it, my Matrix-based UI wrappings likewise just manage state, passing through GUI responsibility to HTML, React, RN, Flutter...good insight!