For the most part, the CLJS bits of RN development are way more stable and don’t require the constant updates the JS parts do.

Krell, Figwheel-Main, and Shadow-CLJS all work with the latest React/Native

For the most part, these libs are just ways of arranging CLJS to be bundled into the RN build pipeline and connecting to a REPL. Once that’s working, you’re just writing normal CLJS.

In Clojure world, a lib not changing just means that it is Still Working Very Well: https://github.com/candera/causatum#liveness-advisory

Yeah, lots of viable solutions out there. I have played with Krell and rn-rf, and came up with a Matrix layer. That got sidetracked by the Easter Bunny bringing https://github.com/Tensegritics/ClojureDart. That might be ideal given the FB team's thrashing with React.

Thank you all for your input. @U0PUGPSFR What do you mean by "FB team's thrashing with React"?

ReactJS? Callbacks everywhere? Lifting, lifecycle, don't use context...wait! Do use context! Did we say classes? Sorry!!! Use hooks! WTF are hooks? That's how we save React. We are just the view, you handle the state. Wait, that is almost impossible the way we effed things -- use Flux! But do not use Flux, we apologize, use MobX or Redux, they are completely different but state is your problem, not ours. Wait. Suspense! Now React needs to manage ALL state. We are talking to the MobX and Redux people, they have hooks on the way. Oh, and we reject the reactive model, ReactJS has to control all state so we can do suspense. Correct, our name should not include "react", our bad. It should be ScheduleJS... too late now! hahahahahahaha.... aka, "thrashing". They have not a clue what they are doing, they are just lurching from half-baked solution to twice-baked solution and sinking fast. Every technology other than Lisp and third normal form has an arc, and React has long since passed its apogee. The CLJS community needs to move on from its ReactJS dependency. ClojureDart is a beautiful path forward, as is straight HTML, altho then we do not get mobile native or desktop apps.

"The CLJS community needs to move on from its ReactJS dependency." Actually, I see encouraging signs of this already. May it continue.

For all that React community thrashing, I don’t notice it in my Clojurescript code. The reagent/re-frame code I wrote five years ago still runs just fine. That’s one of the reasons I picked CLJS in the first place.

I’m not sure Dart and Google are any better, and IMO Flutter is strictly worse than React Native because it draws on its own canvas rather than using native components. Styling and responsiveness are noticeable.

" The reagent/re-frame code I wrote five years ago still runs just fine." Full marks to FB on backwards compatibility, and on not requiring folks to convert to each new cockamamie scheme they adopt. I meant that as a compliment, and still do. 🙂 Full marks as well to CLJS and reagent/re-frame for providing sane worlds for dealing with JS/React. But I am talking about the madness illustrated here: https://github.com/reactwg/react-18/discussions/64 The good news was their backing off throwing the switch to concurrent mode. Instead we see three modes by which we can migrate to their latest kool-aid. So they had this uninvited great idea about achieving blinding performance, trotted it out, found out they were being too pushy and backed off. Meanwhile the community is left with three dialects -- oh, and it seems they recommend complete rewrites to switch modes. That is all I meant when I said "thrashing". I am glad for you they avoid breaking changes, and that is indeed a huge asset. ps. Them changing the semantics of onChange to be that of onInput to suite ReactJS was the ultimate thrash. :)

Krell has so far been the nicest for me to work with, bar some difficulty with the Expo integration. Figwheel-main seems to break on the latest release with the current React Native, at least OOTB (I haven’t figured out the magic settings to make it work, and the documentation unfortunately didn’t have anything resembling my issue). Ironically reverting to an older version of Figwheel seemed to work somewhat. Shadow-cljs has a weird gotcha about refreshing to load any fresh REPL-evaluated code, then deloading it with another refresh, then reloading it again when you submit another change. There’s a variety of fast-refresh-disabling tricks you need to remember to enable across a few different tools in order to get around it, but again, I didn’t find a way to do it consistently.

With Shadow, you kinda also are marrying yourself to Shadow’s way of doing things—I somewhat struggled with its build syntax and relationship to NPM, and find the approach supported by the default CLJS compiler (supported mostly by Krell and Figwheel) to be more natural. YMMV, though, and there’s a reason rn-rf-shadow is still the most popular project template.