shared a thought on reddit thats been rumbling inside for a while, https://www.reddit.com/r/Clojure/comments/bqh0z4/virtual_dom_is_pure_overhead/eohn35i?utm_source=share&utm_medium=web2x

thought-provoking stuff, @alandipert ! i can totally see how clojurescript could be thought of as almost the logical conclusion of react. like, if someone took the ideas behind react and made them into a programming language, it would probably look a lot like clojurescript this might be a good argument to sell react programmers on clojurescript 🙂

What I never understand is using react FROM clojurescript, I’m just like.... why?

it's a much better name than loop-tpl 😂

when I was telling people about hoplon originally I don't think I did a good job either, relative to how people were learning about react

partially because the important differences were not totally obvious even to me

@alandipert well put! much of the intrigue in this field seems to arise out of seeing a familiar problem from a new perspective, so i always enjoy a reading a good ah-ha!

and marketing ideas in general. i agree that clojure's value equality semantics facilitate a more systematic alternative to throwing the results of gratuitous, unnecessary computation at a dom-wrapper, before the penalty becomes unbearable to users. but i wonder if this too is a band-aid, albeit a more general/elegant one , that patches the symptom a more fundamental problem rooted in control flow.

i’m not sure if it’s a bandaid, i think of it as maybe a heuristic

because the clj equality is always going to be slow relative to comparing pointers, even with the immutable things

but programs just come out so much nicer

i agree. but what if the comparisons/equality checks can be avoided altogether? consider the typical cqrs/mvc-ish/unidirectional data flow architecture. functions on the command side, where writes to the database typically occur, can be invoked easily without performing any redundant computation in any language without anything extra; it is only on the query side where data binding frameworks, virtual doms, and other flavors of data-diffing schemes get employed.

i find it interesting to think about why this is.

a couple distinctions come to mind: first, commands are inherently differential, and contain only the transaction that should be applied to the database. the diff is already done. second, the flows of control and data are aligned on a linear path all the way down to the db. i think this is the more significant distinction, because if the control flow and data flow are in the same direction, then the function being called with a differential transaction can transform and propagate its value. the diff is already known to it.

or preserved all the way through.

i think in thta case maybe the b-tree in the db is the vdom

more generally, when writing to an object, the control and data flows are aligned. but whenever reading from an object, to include a restful http get in the large, the control and data flows are in opposing directions. this is where, on the query side, the "you call me so i can call you and you can give me all your data to include all the data i already got last time i called which i will then diff" madness.

yeah. so my conjecture is that the dom and the db should be treated the same way - that maybe reads/gets should be avoided alltogether, and that if we're always writing to the next object, whether it be the database or the dom, there's not much to diff in the first place.

do you mean like using the dom as the data model?

ie not accumulating state in any js structures

no, just that we can think of the dom/application from the perspective of the db the same way that we can think of the db from the perspective of the application.

everything can be a differential write.

when we read from a service, we've lost the control flow and by extension last diff(s) that was written. so we grab the entire thing all over again and use a vdom, or a more systematic equality checking, to sort it out. but it was already known what the diff was when the transaction was written. so why are we diffing again at all?

the click of a submit button applies a function to the arguments in a form's fields that calls a continuation/callback that eventually writes to the db. maybe the function writing to the db should similarly call its continuation, and keep writing the same transaction that was persisted to the db to all the subscribed document models on the other side of the cqrs loop.

admittedly, things are a bit more involved on the query side due to the 1:n relationship between services and client applications, and client applications to views. rather than a clean, linear path down the dependency tree to the db/root, this requires pushing up multiple branches. but this seems to me like it is more ideal that doing redundant comparison checks on data where the difference was already known.

so long as the control flow and data flow are aligned, differences can be propagated all the way through the entire graph of the system, and the dom(s) can be written to incrementally the same way writes are done to a database.

alternatively, i suppose someone could go the other way and make a "virtual db", so the actual db doesn't get overwhelmed, for an application that requires its users to reenter all their data every time they use the thing. 😄