it definitely gets the job done 🙂 what's your reasoning/motivations? i think pathom is likely to be a great choice for a lot of biff projects. it's still on my list to experiment with. i might even try to include it by default if I can do it without making Biff too much harder to learn. Fulcro I think depends more on the situation. It's taken me a long time at work to get familiar/productive with it. it is a pretty principled approach to growing a SPA code base though; it does a great job of helping to prevent your app from turning into a ball of mud. I'm just skeptical that the overhead is worth it for most Biff apps--it feels like a better fit for team projects rather than solo developer projects imo. You could start out by adding just pathom and start using that with htmx--I.e. have resolvers that return html fragments. that would give you a setup that kinda feels like fulcro, but with server-side rendering instead of a SPA. and then from there you could experiment with adding in fulcro and see how you like it.

I'm designing an app featuring realtime messaging with text, audio, and possibly meetings (Amazon Chime will hopefully do the heavy lifting). It's going to get pretty interactive pretty quick, and I'm skeptical that htmx will scale to that level of interactivity, complexity, and pace on the client side.

I find pathom fascinating and promising for complexity management. Fulcro benefits are less clear to me, but I sense that it's basically pathom at the bottom of it, which would be a win for consistency if I'm all-in on pathom on the backend. Early days.

A competitor to Fulcro in my mind is helix

(I fear interop)

A third competitor is pure js react (see above). I am pretty settled on react.

got it. that sounds reasonable. I think fulcro vs. re-frame would be the main choice. It looks like helix is mostly just a React wrapper, whereas Fulcro and Reframe are both more like state-management solutions built on top of React. i.e. helix might be more of an alternative to Reagent, which re-frame uses? Of course you might not even need a big state-management solution... though in the past when I was building apps with plain Reagent without re-frame, they did seem to feel a bit disorganized fairly quickly. I'd still be a little wary of Fulcro, but it is true that pairing it with Pathom could work nicely. There is at least https://biffweb.com/p/how-to-use-re-frame-with-biff/ for integrating re-frame with Biff. Maybe try them both out for a few days.

Thanks! For state management I'm also studying this experiment which use pathom3 + datascript. https://clojurians.slack.com/archives/C87NB2CFN/p1665778058561989

(but with helix instead of reagent)

interesting! I hadn't realized pathom worked on the frontend actually, but makes sense. I think the main limitation there is that the pathom/datascript queries will have to re-run on every render; it won't compute things incrementally like re-frame does. However... I guess fulcro doesn't do that either! Actually this does seem like an approach worth exploring, as a sort of light-weight fulcro alternative. Especially since Fulcro's client-side queries have some subtle limitations that IMO make them more clunky than Pathom queries. Using Pathom on the frontend instead could potentially be really nice. And datascript certainly seems like a fine alternative to what Fulcro does (normalized data stored in a plain map).

@U3XCG2GBZ We are discussing your experiment. Very interesting. Did you end up moving towards fulcro instead of pathom-on-the-client-plus-datascript-and-rendering-framework? Interested in any thoughts on the tradeoffs.

Yes that is something I am quite interested in as well. I actually spent the last couple of days building a lightweight interface between htmx and xstate. Should be suitable for adding a bit more state complexity without dumping htmx. instead of triggering a button on click, you send the click to xstate, and let it send the ok-really-click event to the button.

sample render:

(defn progressing [{:keys [last-progress]}]
  (biff/form
   { :hidden {:last-progress last-progress}
    :hx-trigger "rk-continue"
    :hx-swap "outerHTML"
    :hx-post "/progress/progressing"
    :rk-subtype "continuing"}
   (format "progress: %d" last-progress)))

:rk-subtype of "continuing" turns into the event htmx:afterProcessNode-continuing so it's just (format "%s-%s" eventType subtype)

Interesting, I'll have to look into that