Clojurians Log v2

This framework embodies my feelings on the subject: https://github.com/oakes/odoyle-rules

Sorry, can't answer your question, but was there a specific article/video/lib that opened your eyes about doing things "the react way" vs doing things "the htmx and datomic way"?

Honestly @flauwekeul, the experience of working in with these two technologies in anger has been the main thing for me. But I'd say these two resources pretty well cover a lot of the benefits, at least from an HTMX perspective: • https://hypermedia.systems/hypermedia-a-reintroduction/#_single_page_applications • https://htmx.org/essays/a-real-world-react-to-htmx-port/ The first is an excerpt from Hypermedia Systems, written by the HTMX team, on why the "thick client" came into existence in the first place, the very real problems that thick client frameworks like React and Angular sought to solve, and the drawbacks that they introduce to the nuts and bolts process of building client-server applications. The second is a talk from a CTO who transitioned his app away from React to HTMX, and his experiences of the "before" and "after" when it comes to development effort, speed, complexity, and bugs.

I had to stop reading at there reasons for JavaScript fatigue which didn't match my experiences at all in the last seven years of on and off front end spa development. First off, all work ends up causing fatigue, it's kinda part of the job. Secondly, the reason you get fatigued is because you can't rest enough, which happens when you get pushed harder than you can rest. Trust me, htmx won't solve that, cljs won't either. And yes, a lot of the reasons people defaulted to react and spa was because it was popular, but that's no reason to use sse because everyone else is doing the opposite. The reality is, it probably doesn't matter if you use react or sse/htmx. So flip a coin and do as little of either as possible in solving your problem. I'll try to finish it later, I'm curious what else there is to say here but my experience is that you join a team and they tell you the picked a solution 6 months to a year ago and regardless of that you think that's gonna be the way it goes and if you fight that your gonna have a bad time.

That's not to say we can't try to plan, but you have to plan around a problem, and so far in my reading this solution is still searching for one.

Check out the talk from this link @drewverlee https://htmx.org/essays/a-real-world-react-to-htmx-port/ Yeah, all work is hard, but some work is harder than others. David Guillot makes some really incisive and excellent points about the effort to get a React solution to "work" vs a simpler server rendered RESTful HTMX app. I wouldn't say I'm "fatigued" of React per se, I've actually had quite good experiences working with it. It makes hard frontend problems easy. But it makes simple frontend problems so damn hard, slow, and brittle.

A couple of years ago I switched over from "React is the only correct answer for frontend" to "React might be the correct answer but first look at HTMX". In my Experience HTMX can get you further then you would expect and it makes live a lot easier to just deal with the server instead of basically build two application at the same time, a backend and a frontend. Even react recognised that with server components. Reading the docs and articles of HTMX helped me a lot to understand how to work with restful server applications together with the book Restful Web API Patterns and Practices Cookbook from Mike Amundsen We even went as far as working with hyperview for our mobile apps and although sometimes it takes a bit more effort to have to build something that is not standard in the end the benefits outweigh the negatives. The feeling of releasing a bunch of new mobile app features by making a new build for the server never gets old.

Even react recognized that with server components.I have lost the ability to not rant it seems.. I feel the react team and ecosystem is basically eating themselves alive at this point, and a lot of the complexity that people associated with it are orthogonal to the core principles of react which made it interesting: the virtual dom diffing. My wider point is that where I do the computation (server vs client) is a business level decision that a framework can't decide for me. If i feel happy about an arbitrary choice in that domain it's not because one is better, but just an personal preference. Doing work on the client compared to doing work on the server compared to the DB. How those artifacts are split up geographically impacts my customers, how the artifact construction site looks on my computer impacts me. So basically, it's fine, but it's strange to see it praised as a solution without explaining the customer problem. (SPA frameworks suffer the same issue)

I used to work on web apps that were entirely back end managed, then UX expectations moved us to use JavaScript on the client, then we ended up with an architecture that was difficult to test, then I used Wicket which could test the entire stack in a component, then eventually react gave me real reuse and testability using stateless services. The Django video gives me PTSD.

Having said that https://github.com/starfederation/datastar/blob/main/sdk%2Fclojure%2FREADME.md looks really interesting, and if the codebase can be organized into reusable components under test I can certainly see the appeal of dropping the build steps and dependency hell of SPA development

Ha! Which part of the React-to-HTMX part of that video gives you PTSD @p14n? The before or after of that transition? Datastar is definitely a library that's been on my radar.

The bit where there was a separate JavaScript file handling the front end search.