←back to thread

170 points bko | 2 comments | | HN request time: 0s | source
Show context
nkh ◴[] No.43649648[source]
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.
replies(4): >>43649743 #>>43650835 #>>43651272 #>>43652007 #
jwr ◴[] No.43652007[source]
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.
replies(1): >>43652853 #
1. austin-cheney ◴[] No.43652853[source]
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.

replies(1): >>43663594 #
2. jwr ◴[] No.43663594[source]
I use React in ClojureScript and I don't have problems with state. I treat react mostly as a rendering interface of sorts: my code is a function of state, and React is just a tool that does the shadow-DOM thing. I don't see a reason to avoid React.