[nkh]

One thing I've always liked about the Clojure community, is that they are obessesed with state. I think they have correctly identified, that when things go sideways, it is because state management was involved in some way. This is a cool front end approach using datastar to put all of the state on the backend and side step front end state management entirely. There are some other really interesting things happening with electric clojure and a new "framework" called Replicant. Of all of them, Replicant seems the most intriguing to me personally. If it didn't exist, I think I would be trying to use datastar as this article outlines.

[jwr]

Based on my 30 years of experience building software systems, state really is the biggest cause of problems and bugs in systems. The less state you can have, the better. If you can compute something instead of storing it, do so. Obviously you always eventually end up needing state, but it's good to minimize its use and treat it very, very carefully.

[austin-cheney]

There is a direct correlation between complexity of the state model and the risk it imposes. State doesn’t have to be risky at all. If in an application there is only a single state object and it’s only a single dimension in depth it is never the pain point. In fact it helps to identify where the actual pain points are elsewhere in the application.

This is why I will never touch something like React, a self inflicted wound.

[knallfrosch]

I agree with state management being the culprit. But the most-hyped solution nowadays seems to be: "We'll just ignore frontend state, whatever the consequences for user experience. We'll just say this is how HTML/CRUD was always supposed to work and that will make it fine. [Appeal to authority]"

[fancyswimtime]

single minded react user signing in. When dealing with state in react theres generally a good incentive not to model state exactly like the database model. Does Clojure removing this abstraction improve the application? I can see many pros but not knowledgable enough to see the potential shotgun

[nkh]

The Clojure ecosystem embraced react early and built on top of it (with OM, Reagent and Re-Frame (for SPAs). The UI = f(applicationState) is definitely viewed as the correct approach. In other words, gather all your application state in one place. Whenever it changes, pass all of it to a single function to produce the next version of your UI.

Replicant takes this idea and runs with it, narrowing it down even further: The function is a pure function that returns the new UI as data. Replicant uses this representation to update the DOM accordingly.

That’s it. No partial updates, no mutable objects, no network activity from UI components. It’s basically a templating system. You give it data, and it returns a view. Whether that data comes from a DB or any other place, it's just a clojure data structure. Here is the article that most of this comment is lifted from: https://replicant.fun/top-down/