This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (69)
- # babashka (21)
- # beginners (246)
- # calva (49)
- # chlorine-clover (19)
- # circleci (3)
- # clj-kondo (38)
- # cljsrn (1)
- # clojure (52)
- # clojure-australia (2)
- # clojure-europe (41)
- # clojure-nl (5)
- # clojure-spec (4)
- # clojure-taiwan (2)
- # clojure-uk (28)
- # clojurescript (12)
- # cryogen (6)
- # cursive (6)
- # datahike (3)
- # deps-new (5)
- # fulcro (2)
- # garden (1)
- # graalvm (3)
- # hoplon (48)
- # jackdaw (6)
- # jobs (3)
- # kaocha (6)
- # malli (3)
- # off-topic (51)
- # rdf (1)
- # reagent (40)
- # reitit (32)
- # remote-jobs (1)
- # reveal (24)
- # shadow-cljs (21)
- # startup-in-a-month (5)
- # xtdb (8)
@euccastro Thanks, you've touched on the very point that I'm trying to wrap my head around: If the programming models are more similar than different, what's Hoplon's selling point? Reagent's is, of course, wider adoption.
btw, I'm not trying do diss Hoplon... just trying to understand how it is different from Reagent since, in my limited experience, they seem almost the same thing but with different apis.
i don't know a whole lot about reagaent, but afaict the (abiding) main difference is the separation between javelin and HTML. the manner in which changes propagate through cell networks is decoupled entirely from how or where those values are consumed by UI components
another way to describe this is, dereferencing a javelin cell is not a side effect. whereas in systems like reagent, dereferencing has the side-effect of publishing liveness
one tradeoff here is that javelin cells can "leak" in ways ratoms can't, because the connections between cells endure even without usage
one advantage is that you can rely on the values of cells when you dereference in non-UI contexts, such as in e.g. ajax callbacks or other handlers for events that originate on the server
another advantage of the ratom way, that couples nicely with react, is that the equality semantics of the values contained in ratoms are immaterial
that is, any attempt to cause a change will cause the change to propogate. which in reagent works out fine because react ultimately de-dupes
hmm, reagent might actually leverage clj data equality to dedupe internally, i can't remember. but i know meteor.js used a similar system and it paired well with the lack of structural equality in native JS data
but to (finally) answer your question, i think maybe hoplon's main selling point is javelin, and javelin's main selling point is its total separation from UI concerns. its a pure data management library. with one known application, HTML management 😆
thanks for the thoughts @alandipert... I think I do understand it a little better now... because of javelin, hoplon's model is maybe more decoupled from the ui.
hoplons model could really be used with any UI generating thing, we just have an implementation for HTML Elements
javelin is completely decoupled from the UI, really.. things built on it are suggestions of how to couple
but there are attractive efficiencies of coupling, and so that space is inhabited by lots of other libraries too
efficiencies like limiting the shape/size of data you want to map to the dom, different ways of naming relationships between data and UI elements, etc
TBH, I've watched a few Hoplon presentations and i feel somewhat stupid because I can almost grasp where the presenter is getting at but not really.
100/100 times they are always over complicating the logic, and it comes down to poor abstractions
it makes sense. so you start with modeling javelin cells and formulas before writing the UI?
@guswill yeah the real secret to how this works is that we implement IFn for HTMLElement, you could do that with any UI generating thing, then the second piece of magic is wiring the attributes to events/jcells and BAM 💥 you reimplemented Hoplon
it's funny because a few fellow clojure programmers recommended I check reagent out because it's more popular. I posted the same question in #reagent and got a ton more responses here.
I think reagent is popular because of react being popular in JS land -> the more you move to CLJS land the less you want to deal with JS Libs
@guswill questions are always welcome, clearly there is a learning curve and getting it explained well and educating devs is a bit more difficult
but it’s worth it - we have a huge app written in Hoplon exclusively and it’s awesome 🙂
it makes sense... as an outsider, it feels like reagent is more popular because react is popular but there's not a lot of enthusiasm for the paradigm. not the same I'm seeing for hoplon here, at least.
one activity that might be illuminating is starting with just javelin, you'll encounter all the fundamental problems on the road to what hoplon is
afaict the wider clojurescript community considers the matter of UI more or less settled, and in favor of reagent and derivatives, and this works for most people because nowadays nobody ever gets fired for choosing React
but javelin is still interesting, being separate from UI and not having a react dependency. in some sense, anyone who uses it has more leverage. but also, fewer things to google and fewer friends to help