You can't drink Reagent/Reframe

re-frame is more elaborated, and Rum, as advertised, is simpler. I have not used Rum in anger, but its mix of atom watches and react hooks is a bit scary. It seems quite popular, so I guess it works out fine. The re-frame win is having that more elaborate framework. The downside is that it can be frustrating to fit into said framework, and I have yet to find a shop that uses it correctly. RTFM! 🙂 tl;dr: If those are the only choices, if we think we can handle the state management freedom, use Rum.

It's interesting to hear you say Rum seems popular. I've been having issues with it the past few months and the channel has been completely dead unless I directly ping the creator. I like the idea of freedom in state management, but the last straw for me has been trying to pass in a default value to a rum components local state. You can set a default value, but you can't do it from the args list because mixins can't access symbols in the function definition. They are written before the definition. So I'm trying to write my own mixin that can be passed an index of which arg is the default argument for local state and it's just... odd. This seems like a basic, important thing in React that's difficult to do in Rum. Makes me wonder if I should switch to re-frame. Yes state is opinionated, but local state can just be a local ratom defined in let, not some specialty mixin that loses access to basic language functions.

Sorry, @U042LKM3WCW, I was speaking from 30k feet and, worse, a wayback machine, a manager who once was quite high on Rum. Ignore me. Do you have Helix in your solution search space?

Looking at it now, I've heard it brought up a few times

I wasn't trying to get too into the weeds, I think my point was more that these kinds of "wrapper" issues can be tricky to solve and there's not a big Rum community I can interact with for help. Everyone I've talked to just says use Reagent or something else.

I feel your pain. 🙂 I was horrified long ago when I ran into ReactJS the Original and found myself immediately fighting the framework to get trivial data for a widget from a neighbor widget. Then they came up with the Flux model as a work around. Not a fan. By the time they got to hooks I realized the programme was just a thrashfest. I digress. You will certainly have a bigger community of help with re-frame. And if a small but very active community of original authors sounds OK, you might consider #C03A6GE8D32 and be done with React altogether. Happy hunting.

Are people using flutter with clojuredart for frontend? Or is there some other dart solution they are using?

I think Flutter is the name of the game. I even see rumblings about Dart existing only to support Flutter. It's an OO hell, but we Clojurians are easing that pain with CLJD, but by offering a nicer layer atop Flutter.

I can't say that's been my experience with React. I have a lot of experience with it and after the churn through state management libraries and context solutions, I think the ecosystem has settled into a really easy to use set of battle tested libraries. I feel very comfortable in react. On the flip side, I feel wrappers around react are a difficult extra layer and I haven't been having a good time in Clojurescript. I have been making a full stack clojure app as an experiment, but I find myself liking it as a backend language more and wondering about the value add of clojurescript in the process. I keep thinking I'd be able to do this faster in React, and the opportunities for "code sharing" are few, so that value add is questionable. And when it comes time to interop with React for animation libraries like framer-motion, the warts of not using React are more obvious

So if you are also happy with JS, which I quite like in its modern form, you may not need CLJS at all. I guess Helix is a nice middle ground. 🤷

I do like JS, but for learning purposes I will continue with ClojureScript to see if I get any insights. But I may switch from Rum cause I'm annoyed at how hard it is to do this local state thing. Reading through helix. Is the idea that it's easier to directly interact with the javascript than it is in other React wrappers?

I just like that Helix is more bare bone than re-frame. Well, I also prefer (div ...) over [:div...]. Meanwhile, I have to say re-frame seems like a better Redux, so that is nother plus for CLJS.

I'm not a huge fan of Redux, although I understand why it exists. I'm a big fan of react-query which solves a lot of state problems since most apps use state management as a way to manage server state.

Oh, so if the re-frame better Flux is not of value, Helix may be perfect.

You could have a look at https://cljdoc.org/d/rewrite-clj/rewrite-clj/1.1.45/api/rewrite-clj.paredit

1. The client uses PixiJS, and learning that (and modern browser-dev for that matter), as well as using clojurescript (which I'd obviously prefer) seemed like a non-starter. I'm using typescript for now, bundled by webpack. I've seen impi and phlox, but they're out-of-date and/or incomplete (if updating them appeals to anyone else, I'd lend a hand, but doing it alone is too big a tangent right now) 0. Also multi-channel: I have three fairly intertwined questions, with the first two seeming most appropriate for #C03S1L9DN and the third firmly in #C03S1KBA2 territory. Apologies for not managing to decomplect them, but I don't see how, without losing important context.

you can use https://shadow-cljs.github.io/docs/UsersGuide.html#target-esm to emit code that webpack can bundle together with the typescript

just set :js-options {:js-provider :import} so that webpack bundles all the npm packages you use https://shadow-cljs.github.io/docs/UsersGuide.html#_third_party_tool_integration