FWIW I don't remember a survey like that. You would also be able to find it here via the search if it existed at some point. Also, I would question the usefulness of such a survey anyway. How popular something is is a rather poor metric when deciding whether to use something or not.

If we gave a cabbage about popularity, we would all be on the Python forum.

There might well be metrics about the prevalence of React (in the JavaScript world). Then, having chosen a Popular path at the host level, you could choose a Clojure wrapper based on merits. (And the right answer would be Reagent or Re-Frame)

I don't want to choose a library based on popularity. I'm already using re-frame. I wanted to know if a survey because I'm thinking of giving a talk on UIs, and if most people use re-frame, that simplifies certain aspects.

Depending on what those aspects are, perhaps GitHub stars are a reasonable proxy.

re-frame is not a UI library. it's a state management library

besides ideas in re-frame are outdated. i wouldnt recommend using re-frame in 2023

What would you recommend instead?

I would use React with Vite + TypeScript and skip using ClojureScript. • TailwindCSS + Shadcn for UI Library. • React Query for server state management • Zustand / Recoil for client side state management

Speaking from the experience just re-writing a ClojureScript Reagent/re-frame based app to TypeScript/NextJS in the last 6-7 months

> skip using ClojureScript Definitely hard disagree. > TailwindCSS + Shadcn for UI Library That's beside the point - you can use those with re-frame and Reagent just fine. > React Query for server state management Again, beside the point. > Zustand / Recoil for client side state management AFAICT judging by a few presentations from its author, Recoil has borrowed pretty much all its ideas from Reagent. Haven't heard of Zustand at all, but on the surface it seems to be pretty much identical to a subset of re-frame's features. Of course the implementation and the syntax are different, but that's a minor thing. With all that, I'm quite curious what you mean by "ideas in re-frame are outdated". Which ideas exactly? What each outdated idea, what has superseded it and why is it better?

I am not here to debate bro

He was asking for opinions, i gave mine.

The OP has never asked for an opinion though. And the context is specifically CLJS, the way I can understand their post. So coming in with "my tech stack is better" without any substance is definitely asking for a debate. To corroborate my own claim on Zustand specifically. They have https://github.com/pmndrs/zustand?tab=readme-ov-file#first-create-a-store in their README about bears - that very same example can be recreated in re-frame with the same amount of lines that do exactly the same things. They also have a global store - same exact thing re-frame has had since 2014. They give a separate ability to slice it - which is trivially implemeted in re-frame with layered subs and interceptors.

"my tech stack is better" why are you putting your words in my mouth

when did i say that

i simply said clojurescript ecosystem is lagging behind

Not those exact words of course, but that's the way I interpret "i wouldnt recommend using X" and "I would use Y". > i simply said clojurescript system is lagging behind (edited) I don't know all the details but I know that it might be lagging in some very specific aspects. The whole CLJS and/or its whole ecosystem are most definitely not lagging behind.

Well if you are asking them here is my reason after using ClojureScrpt for 5+ years (1+ years in prod). Why ClojureScript: 1. REPL 2. Code sharing between client and server Why not ClojureScript: 1. Lack of talent (hiring becomes a pain) 2. Since we have lack of ClojureScript talent, we have too many Backend Clojure developers writing frontend code 3. Ecosystem lagging behind / hard to keep track with JS. (Example #1: Re-frame - designed in the pre hooks era, does poor job handing server state - not designed to solve that problem. Example #2: Hooks Interoperability is a pain in reagent based apps) 4. Pain in the ass to deal with importing CSS etc 5. No framework for Re-reagent. Reagent itself is very unopinionated. Which means developer have to think about routing, folder organization etc 6. Don't let me even get started with pain updating dependences with shadow-cljs. Probably one of the worst experience 7. shadow-cljs is slow compared to other build tools 8. How do you handle environment variables in ClojureScript without using shadow-cljs.edn hacks I mean, for your personal pet projects, go head. But if you were writing an enterprise level app, then I would over this list (esp point 1).

Again not here to debate/hurt your feelings. Just sharing my experience

All of those points except for 3 are, well, beside the point (which was about re-frame in particular), so I won't address them even though there are definitely things that could be said. And regarding point 3 - IMO, hooks are a yet another showcase of the churn in the JS ecosystem, and so far I haven't seen a proof to the contrary. They have been introduced in 2019, just 4 years ago, and now most people are on their bandwagon. It's true that they make some things more convenient. They also make other things quite bad. Arguably, it stems mostly from particular praxes, but those are inevitably dictated by the design. (Debugging a component with a few custom hooks is probably the least enjoyable dev-ex). I am yet to see a scenario where I would be better off using a hook instead of something else. And I'm not talking about personal pet projects. Just noticed that you've added point 7 and 8. Again, beside the point, but I'll address them simply because doing that might immediately benefit you. 7 - You might be using it incorrectly. There has been a similar claim not too long ago, it turned out to be a configuration issue IIRC. In my experience, hot code reloading almost always takes much less than a second, unless I change some namespace on which most of other namespaces depend. 8 - Why "hacks"? Those are proper approaches employed by a proper build tool. And AFAICT at least the vanilla compiler can be made aware of env vars if you use its CLI to its full extent. I'm 70% certain that something can be done with env vars with Figwheel and Figwheel-main as well, since it's a pretty common desire, but I don't know myself since I've stopped using them years ago.

Oops, forgot to address this part of the point 3: > does poor job handing server state - not designed to solve that problem I assume you mean SSR (if not, them I'm not sure why this point would be brought up at all since backend and frontend have utterly different concerns). You have said it yourself - it's not designed for it. Although it's not because of re-frame, or even Reagent, but rather because of React and the fact that its SSR works only with JS. You can use SSR with re-frame just fine if you use NodeJS for your backend and don't rely on any UI library that can't be used there (Reagent and re-frame are not in the list of such libraries, they can be used even on Java). But not everybody needs SSR. Hell, not everybody needs even React for that matter. Plenty of enterprise-grade apps can be written using other approaches, and plenty are.

Oh, also noticed point 6, which I'm mentioning only because it's in the same scope as points 7 and 8. I struggle to understand it. You mean the fact that you have to manually write the version number into the file? Or the fact that it doesn't tell you that a dependency has a newer version? On the former - IMO it's not a problem since doing that automatically is about 1% of all the things you need to do in order to handle a dependency update properly. On the latter - plenty of reasons for that. But you can use things like antq to check for you. It can even address the former point! To summarize and tangentially address some other points as a bonus - the tools are there, the approaches are there, the solutions are there. For pretty much every problem, concern, desire. It's rare that a tool can do everything you want, and one of the reasons is that CLJ culture is different, it's by and large framework-averse. But you can most definitely compose the tools you like to fit any approach that you might prefer. And they don't have to be CLJ[S]-only tools - you can often use tools designed for Java or JavaScript as well.

Okay. Anyways, back to old discussion use tailwindcss + chadcn for your ui needs lol

Which you can use with re-frame just fine. :) I myself prefer MUI, which is a preference dictated not in small part by how they handle numeric inputs.

MUI has been a pain for us in the past. Constant breaking changes when upgrading. Plus bigger problem with MUI and other design library is that you don't own the source. Meaning you still use via npm. With chadcn, you get the whole source of the component. Plus great DX

> breaking changes when upgrading That's a bummer, I haven't experienced them myself, or at least don't remember. But I also don't upgrade all that often - don't see the need when everything is working on my end, and MUI is not a thing that can cause security concerns. > Meaning you still use via npm Personally, I don't have any problems with that, but I can see how it can be less than comfortable.

yeah, you normally see in long lived enterprise apps, not in personal toy projects. For example one of my previous companies used v4 and wanted to upgrade to v5. It was big breaking change. Almost took 3 months. https://mui.com/material-ui/migration/migration-v4/

As I've mentioned, I'm not a stranger to enterprise apps, on the contrary - most of my career revolves around them. But if it's v4 vs v5, then I can see the issue. I treat it as a different library altogether. They've even changed the NPM coordinate, and branding, at least partially.

Yea, not a fan of mui after this

🤷 One of the apps I maintain still uses v4. I don't see a need to change to v5 there, so no problems. :) Same was the case with Angular - if v1 worked for you, there was no reason to change it to v2, to a completely different library essentially.

Its not that simple

Sometimes you have one dependency that uses one version of node and another that uses another version

Also not upgrading packages can lead to security issues

That fits just fine into the "works for you" criterium. If something relies on an incompatible version of something else or has security issues that you care about, then it doesn't work for you, I agree.

Exactly. We were forced to upgrade because a new dependency was using new node version.