Clojurians Log v2

I appreciate the discussion and hints! Thanks. Currently I'm trying out uix and see how far I come. To me it seems like I need to spent some time with vanilla React first to get a better understanding of the interactions with the cljs libs. Also spent some time researching and am now wondering if I I'd rather adopt Squint for compatibility with js. Whats your guys experience with that?

@martinklepsch hallo, this was really helpful, too. How come you'd recommend claude over gpt in this case?

In you want to go with uix I’d definitely recommend to study React docs while playing with the library. I don’t know much about Squint, can’t recommend anything unfortunately

Re-frame stands somewhat separately - you can compare Reagent to UIx/Helix, but not re-frame. You can compare it to something like Redux though, probably with a few other Redux-related libraries.

FYI this also sounds like a perfect use case to build for with LLMs like Claude or GPTEngineer - probably not gonna be Clojure then but if you just want the tool…

Yeah... Just an hour ago I tried building a small thing in Clojure by using an LLM and asking it to write Java code (I asked it to convert that code to Clojure initially but quickly gave up and decided to do it manually). Of course, it was one particular LLM, but the experience was positive only in the sense that I've learned the correct package to use. That is it. Everything else I had to rewrite by hand, which was incomparably quicker than to ask the LLM to fix the code for me, since basically every other line was wrong to some extent.

I tried the same experiment around half a year ago, that time it was with multiple different models and in JavaScript. Same result - it's great for pointing you in the right direction when you don't know the direction, but then landing on the right spot is much faster by just doing it yourself.

Fulcro is great for small projects, too. Too much is made of its learning curve- it's conceptually quite simple and complexity doesn't grow super-linearly like that with Re-frame.

That's the first time I hear about super-linear complexity with re-frame. :) And certainly not something I've experienced.

I mean it in the literal sense of complexity– how many things need to know about how many other things that you wrote in your code. Fulcro is a simple one-way dataflow where all the data is normalized by identity and always read from local app-state. Loads/mutations change that state and components w/ identities+queries for the changed data are re-rendered. Adding components that render app-state data doesn't require "wiring" anything up / subscribing to anything, implementing any weird reducer pattern, etc.

I think the scope ofwhat Fulcro is offering versus the scope of what re-frame is offering are very different

I think it's very much the same scope.

"build potentially complex SPAs"

same domain, different scope of tooling

there are things I like about both but I do not think they compare well

perhaps

re-frame is less opinionated about data format, server interaction, etc.

fulcro does let you change its default opinions though

middleware, etc.

Granted I was not an experienced developer when I came to Clojure but I feel that both libraries required me to have an "aha" moment where they just sort of clicked for me, so in that sense I find them alike. but I think Fulcro is both pluggable and comprehensive, whereas re-frame is more about the "bricolage"

I think you're right that Fulcro's learning curve is overemphasized though

"bricolage" is a new word to me. I like it!

definitely one of my favorite words I have personally loaned from the French, even if no one else is doing so

I'll help popularize it.

Putting it up there with "complect" and "indelible".

I've worked in a handful of re-frame codebases (my own, not my own) and my conclusion is that re-frame requires you to make more decisions earlier on in the process. anecdotally, every person has their own defevent macro or something like it, there's a different way of managing the app-db, etc. lots of knobs to twist, which is both a benefit and a drawback

Yeah- that's a good description of it. I prefer the Fulcro approach, but have built big things in both.

I am brand-new to Fulcro (just started learning it in my free time) and it has less of that manual configuration (up front), it seems.

The Fulcro book is fantastic, if verbose.

agreed

> I mean it in the literal sense of complexity– how many things need to know about how many other things that you wrote in your code. > Fulcro is a simple one-way dataflow where all the data is normalized by identity and always read from local app-state. Heh, maybe then I've invented my own kind of Fulcro by writing a set of functions for re-frame that I use to predominantly work with normalized data.

> Heh, maybe then I've invented my own kind of Fulcro by writing a set of functions for re-frame that I use to predominantly work with normalized data.

this is what I mean by making more decisions up front

bc presumably you aren't going to start writing an app using un-normalized data and then decide you want to normalize it later on. sounds like a bad time

> this is what I mean by making more decisions up front not a value judgment tho, this flexibility is good for some

Indeed. The only thing that prevents me from actually sitting down and learning Fulcro to see if I can use it in my projects is still occurring breaking changes. In Fulcro itself and in Pathom, which Fulcro seems to expect you to use, at least in some or most cases. Every time I see an announcement about either of those and see the word "breaking" either there or in the corresponding changelog, my virtual TODO item for learning all that stuff gets shifted forward by a couple of years or so.

I don't think you are tied to Pathom by any means, but it does complement the frontend data model of Fulcro. I like the idea of the single API endpoint, and the unified data fetching. But I agree, Pathom seems to have a lot of breaking changes

> the single API endpoint, and the unified data fetching Yeah, that's also something I've landed on relatively early on in my Clojure career. :) So I'm also definitely biased towards the tools I've written myself and have been using for years.

I think both uix and helix are conceptually very similar, they are thin wrappers on top of react. Which means you’ll have to pile up a couple of libraries on top and figure out yourself what works best for you. There’s a template project from Metosin folks, pretty sure this library selection should be enough for a simple app https://github.com/metosin/example-project/tree/master

@adelberg re squint: I built a nontrivial Figma plugin with squint and when interop with the rest of the JS ecosystem is important to you it’s a great and lightweight option. re claude: claude just has a good generate code to interactive UI flow. I think v0 by Vercel is similar in that way. And Townie by val.town is also interesting. I just used Claude the most so far. But play around!

The Claude model is best for generating code as of now.