Fork me on GitHub
#hoplon
<
2021-01-18
>
GusWill15:01:59

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

GusWill15:01:22

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.

alandipert16:01:29

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

alandipert16:01:24

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

☝️ 1
alandipert16:01:20

one tradeoff here is that javelin cells can "leak" in ways ratoms can't, because the connections between cells endure even without usage

alandipert16:01:54

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

alandipert16:01:46

another advantage of the ratom way, that couples nicely with react, is that the equality semantics of the values contained in ratoms are immaterial

alandipert16:01:05

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

alandipert16:01:54

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

alandipert16:01:26

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 πŸ˜†

GusWill22:01:11

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.

flyboarder22:01:32

hoplons model could really be used with any UI generating thing, we just have an implementation for HTML Elements

flyboarder22:01:50

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

alandipert22:01:21

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

πŸ‘ 1
alandipert22:01:57

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

GusWill22:01:33

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

alandipert22:01:34

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

GusWill22:01:11

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.

flyboarder22:01:41

That seems to be the common learning curve

GusWill22:01:43

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

flyboarder22:01:08

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

GusWill22:01:16

thank god I'm not the only one @flyboarder

flyboarder22:01:35

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

flyboarder22:01:54

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

GusWill22:01:01

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

flyboarder22:01:02

when you fix the abstractions it all falls into place

GusWill22:01:52

it makes sense. so you start with modeling javelin cells and formulas before writing the UI?

flyboarder22:01:19

@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

GusWill22:01:51

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.

GusWill22:01:09

so, thanks everyone for being so friendly.

GusWill22:01:33

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

flyboarder22:01:48

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

flyboarder22:01:48

@guswill questions are always welcome, clearly there is a learning curve and getting it explained well and educating devs is a bit more difficult

flyboarder22:01:16

but it’s worth it - we have a huge app written in Hoplon exclusively and it’s awesome πŸ™‚

alandipert22:01:03

yeah keep bringing the questions please!

GusWill22:01:33

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.

GusWill22:01:19

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

πŸ‘ 1
alandipert22:01:37

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

alandipert22:01:17

which are approximately the same as those react concerns itself with

GusWill22:01:31

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

flyboarder22:01:48

@guswill hoplon wiki

πŸ‘ 1
flyboarder22:01:01

this channel

flyboarder22:01:27

good ol’ fashioned trial and error

πŸ™ƒ 1
flyboarder22:01:17

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

alandipert22:01:57

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

alandipert22:01:48

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

GusWill23:01:11

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.

πŸ‘ 1