#C0459PCHLTW

I don't get it

That feels very much on-topic for #C03S1L9DN (and I'd certainly like to hear answers to this question!).

For a WIP personal web-targeting hobby project I went the diametrically opposite way and decided to take a look at #biff (it has zero javascript!). Looks great for what I need to do so far; not sure how it would fare in larger apps. The tech stack is quite unusual: htmx (very interesting), xtdb, custom code for dependency injection (inspired by component) and in the tutorial it suggests hyperscript for minimal client-side scripting (kinda weird). Setting up the example project takes 5 seconds and you get a live REPL in a working web application, so it manages to take away a lot of the complexity of figuring out which pieces to pick (it just makes that decision for you!), as well as how to combine them. edit: For SPAs, my impression is that react (reagent/re-frame) is still where it's at

Recommend htmx too. (There's a lib ctmx which is on top of htmx for clojure. I haven't used it though.) I've tried my hand at small scale re-frame apps before. Nothing substantial. But I really disliked having to code two apps (backend and frontend) to get something simple done. Clojure + htmx is a win in this regard. The dev experience is greatly improved. It's pure Clojure again. One other interesting point is that some of the htmx philosophy seems close to Clojure's. Here's a sample read from the htmx creator: https://grugbrain.dev/

I never had to do something serious with biff/htmx. My feeling is that it's great for normal webpages with interactive elements. But as @UEQPKG7HQ said, for writing SPAs, you'll probably want to prefer something that manages the whole page, like reagent/re-frame. That said, relying on pages with interactive elements is much more stateless and close to functional programming on the one hand and Clojure on the other. Still, my job is writing complex business applications that just happen to live in a browser and coordinate via a server, so I have more experience the SPA way.

At All Street we primarily have two Web UI types: • Less interactive: We use server side rendered hiccup + HTMX + _hyperscript • Highly Interactive: We use #uix which is relatively quick to learn (just a few React hooks) and gives access to full ecosystem of React (e.g. we use antd library seamlessly). We use integrant on the fronted for dependency injection/decoupling. From what I've seen, re-frame can be a bit heavy on ceremony without always solving tight coupling for some of the projects that use it.

What’s interesting about htmx is that I’ve discovered that it does a lot more than I thought it could. The htmx crowd has been busy showing that in their community. There are definitely reasons one would need to do things client side… but it’s starting to look like a shorter and shorter list. I’m very grateful for Biff as it allowed me to realize this much more quickly than I would have.

I need to check out htmx, I've never heard of it till this thread

I'm no HTMX expert, but I find devs to be pleasantly surprised by what HTMX and hyperscript (aka hypermedia) are capable of. Here's a few examples of hypermedia driven frontends: https://www.youtube.com/watch?v=zHoAwVcSLdE https://twitter.com/Telroshan/status/1482034786621394951?s=20 A deeper dive into a React to HTMX rewrite: https://www.youtube.com/watch?v=3GObi93tjZI When is HTMX not a good fit? Here's a good read on its use cases and drawbacks: https://htmx.org/essays/when-to-use-hypermedia/

+100 on #biff , I've found it to be the simplest approach to web dev by a wide margin, coming from Elixir Phoenix, some node and React. NB: I'm an amateur dev, with a strong preference for writing datalog and working with #xtdb over SQL and relational db's