Fork me on GitHub

@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

☝️ 3

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


there is also an implementation for JavaFx (out in the wild)


javelin is completely decoupled from the UI, really.. things built on it are suggestions of how to couple

πŸ‘ 3

but there are attractive efficiencies of coupling, and so that space is inhabited by lots of other libraries too


I will be basically doing rx programming, and the dom is just the buffer.


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.


That seems to be the common learning curve


but then I read some hoplon code and it seems so simple.


once it clicks, libraries like react and shadow dom make no sense anymore


thank god I'm not the only one @flyboarder


I have someone on my team who is also going through the learning


100/100 times they are always over complicating the logic, and it comes down to poor abstractions


so in theory I could write a Javafx buffer for javelin then? or even swing?


when you fix the abstractions it all falls into place


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.


so, thanks everyone for being so friendly.


I wil refrain from posting more n00b questions here in the meantime.


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 πŸ™‚


yeah keep bringing the questions please!


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.


thanks guys. let's hope it will sink in at some point.

πŸ‘ 3

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


which are approximately the same as those react concerns itself with


do you have any resources you could point me to besides javelin's docs?


@guswill hoplon wiki

πŸ‘ 3

this channel


good ol’ fashioned trial and error

πŸ™ƒ 3

@guswill is there anything you are currently building or evaluating hoplon for?


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


I'm evaluating it for an internal tool for my workplace. we have a legacy CRUD-y, angular 1.0-based business app that needs to be updated... at first I wanted to use reagent but we use a lot of dom-modifying libs, hence hoplon.

πŸ‘ 3