Clojurians Log v2

@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

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

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.

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

this channel

good ol’ fashioned trial and error

@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.