| Thanks for responding. I'm in the Clojure slack already actually. > If I don't know where the problem is, I'll look at the Java stack trace and start adding `tap>` calls to see the flow of data. Since Clojure programs are data-oriented, inspecting the state that's flowing through the function arguments is usually all that's needed. It's a bit different process, though. Can you elaborate on your issues with the Java stack traces? This, to me, is the equivalent of placing console.logs everywhere and running the request. Which isn't a terrible thing. Yes, I know Clojure is immutable and I can eval the function in a comment with `tap>`, and run it over and over again without affecting my system. But if I'm just using my site and all of a sudden something happens unexpectedly, I have no idea what function is the problem and what arguments were passed to it. It's often a nil that got passed 5 functions down. I have tried setting it up in a way that I can easily find where the problem is, and I have failed. So in reality, the debugging experience for webapps doesn't feel unlike what it would be for using react and a random backend. > This doesn't really ring true for me even if a lot of docs are written for emacs. At work people use vim, emacs, VSCode, and IntelliJ. As I alluded to earlier, I think IntelliJ is the one that "just works". If you haven't tried it, I recommend giving it a shot I'll have to try IDEA. Not pumped about the subscription. My personal experience with Calva, just asking multiple times over multiple weeks for help with a fullstack setup, is that people don't use it and don't care to use it. I got several "I don't use Calva" and "just use emacs" from prominent people in the community. > Reagent works with React 18, function components, Suspense, React.lazy, hydrateRoot, etc... Honest question: what do you feel like you're missing out on right now by using Reagent? I got my wires crossed on this one and was confusing it with something else, I apologize. > Can you share what libraries you're talking about and/or what issues you ran into? In general, the claim that a library doesn't need to be updated as it wraps around another library is dubious to me. But on my end, Secretary is a very popular client side routing library that was recommended in a lot of places. I wrote a lot of code for it before finding out a key piece of it was broken and nobody seemed to care. > In my opinion, Biff is the future for server-side apps. It works really well out-of-the-box and the pieces are there to improve it over time. After using om.next and getting burned by it, I haven't had much interest in Fulcro. I'm interested in Biff, but after trying it a bit, it seemed like I would benefit from it more if I had a grasp on fullstack Clojure development first. In general, the Clojure slack has been a mixed bag. People are very helpful and nice, but sometimes it seems like I'm asking something simple like "What should I be using for client side routing" and nobody has an answer. |
For me, there are many ways to approach the problem of "I'm just using my site and all of a sudden something happens unexpectedly" which are not necessarily specific to Clojure. That said, one unique feature of Clojure is that you can literally inspect data and change the code as its running in production, which is not possible in most other languages. Once you're connected to a prod REPL, you can redefine functions to include `tap>` if you want.
> I'll have to try IDEA. Not pumped about the subscription. My personal experience with Calva, just asking multiple times over multiple weeks for help with a fullstack setup, is that people don't use it and don't care to use it. I got several "I don't use Calva" and "just use emacs" from prominent people in the community.
I know that some people on the core Clojure team use IntelliJ for development. I feel your pain about the subscription cost.
> I got my wires crossed on this one and was confusing it with something else, I apologize.
All good, thanks for clarifying.
> In general, the claim that a library doesn't need to be updated as it wraps around another library is dubious to me. But on my end, Secretary is a very popular client side routing library that was recommended in a lot of places. I wrote a lot of code for it before finding out a key piece of it was broken and nobody seemed to care.
I think stability as a cultural value is the most important thing about this, but yeah, it's more of a goal than a rule. I'd suggest using reitit these days. It's well-maintained in 2023 and we use it in production for our Ring apps with no issues. It has a CLJS namespace (`reitit.frontend.easy`) which would replace secretary for you. Plus you get the benefit of routes-as-data and the same interface for both server and browser. I think the chance of this library falling by the wayside any time soon is unlikely.
> I'm interested in Biff, but after trying it a bit, it seemed like I would benefit from it more if I had a grasp on fullstack Clojure development first.
If you need help with Biff, post on the #biff channel. I think people (including myself) would appreciate the fresh perspective. If you don't want to use a framework, try creating a Ring app from scratch with Reitit and Hiccup. Use HTMX to start if you want interactivity. If you can do that first, you'll have a solid foundation to build a full-stack Reagent/Re-frame app on top it because you won't have to change routing libraries or templating languages.
> In general, the Clojure slack has been a mixed bag. People are very helpful and nice, but sometimes it seems like I'm asking something simple like "What should I be using for client side routing" and nobody has an answer.
Just use Reitit. I think you'll see it becoming more common as time goes on.