Fork me on GitHub
#off-topic
<
2019-08-18
>
theeternalpulse01:08:16

Any good topic on creating effective data-driven websites that aren't riddled with complex javascript or abundance of xhr calls. I've know serverside may be an option but was wondering if there's any extensive information on reducing how much websites can and should be doing.

myguidingstar10:08:32

Fulcro web framework is what you're looking for. It's effectively data-driven (not just event driven) and will liberate you from handling http code/status/response again and again

theeternalpulse05:08:14

I was generally thinking less clojure specific, and more on the topic of the web in general.

dominicm07:08:14

the re-frame model is kinda interesting. the idea of punting around data.

markgdawson13:08:42

I'm reading the paper "Out of the tar pit", which I've heard recommendations in Clojure talks. It's a really lovely paper that to me helps motivate some of the philosophies I see in Clojure, I'd highly recommend it. There is a section that I'm not understanding, has as anyone read the paper and can explain it maybe? It's a section on what they call "essential derived data - mutable", it says: "Mutability of derived data makes sense only when the function (logic) used to derive the data has an inverse (otherwise - given its mutability - the data cannot be considered derived on an ongoing basis and is effectively input)." I'm stuggling with this. Can anyone enlighten me with what this might mean? My first through here is that inverse mean an inverse function that takes the outputs to produce the inputs? But that doesn't make sense, any lossy transformation to the data has no inverse but is not reversible, and neither would it be classifiable as input.... I think I must be really missing the point here, anyone who might have pointers, I'd very much appreciate them! simple_smile

andy.fingerhut19:08:49

So in that paper, derived data means it was produced via some function from some other data. If the derived data is immutable, and/or rederived via re-applying the function whenever its inputs changed, then no problem.

andy.fingerhut19:08:11

If the derived data is changed, on its own, independently of its inputs, then there might be a problem of it losing its status as derived data.

andy.fingerhut19:08:11

If you can take the derived data after it has been changed, and run a "reverse function" to get back the updated version of what it was derived from, and update what it was derived from, then the mutated data can still be considered derived from that updated input data.

andy.fingerhut19:08:37

If you cannot do that, now you have some data that is no longer derivable by calling a function from some other data you have, so it is no longer derived data.

andy.fingerhut19:08:57

Sorry, that might not be clarifying at all, but figured I'd give it a shot.

markgdawson18:08:14

Sorry for the delayed response @U0CMVHBL2! That's very clear thanks. I definitely had to read it a few times, and think a bit before I convinced myself, but got there in the end. That's super helpful, thanks again for the clarifications!