I'm having trouble finding a good explanation for how Hoplon and Reagent/Re-frame compare. I know Hoplon uses a "spreadsheet" metaphor with Javelin and doesn't use React, and Reagent uses FRP and React, but spreadsheets are sort of FRP, aren't they? How does the metaphor diverge? I want to make an app where much of the code I could reuse for the web, my phone, and the desktop, though this will most likely be a desktop-first app via Electron. I want to make a personal knowledge base (https://en.wikipedia.org/wiki/Personal_knowledge_base), so I want to be able to query and explore a multimedia graph database rendered in canvas or WebGL (I'm not sure of the GUI side yet, but the data structures side is pretty well-defined for me). I want to have the database be immutable and versioned, so I've been looking into using DataScript as the base for my database. How would DataScript fit into Hoplon or Reagent?
Can you help me understand the pros and cons or differences between Hoplon and Reagent for someone who hasn't used React or ClojureScript before? I use JS a lot, but I don't have any real experience with the React or ClojureScript ecosystems nor even Clojure, so I don't quite know why I would want CLJS-flavored React any more than I know that I would want Javelin. I apologize for requesting such a comprehensive explanation from such ignorance. There's so much information to understand that it's difficult for a newcomer like me to make sense of it and make a good judgment on which framework/library is best for me. I have dabbled in different Lisps but haven't used any for real projects, though I've made a Lisp interpreter. I say this so you realize I'm not a complete newbie when it comes to Lisps in general, though I'm definitely a newbie to Clojure(Script).

@mhr: well hoplon is way simpler than any of the react things, i think

so if you're new to clojurescript and you're not already a react expert i think you'll probably benefit from at least prototyping something in hoplon

hoplon has far less tooling and configuration to get things going also

and the conceptual model is very small and simple

that's great to hear! I'll definitely start with hoplon and see where that takes me, then. do you have any experience with using hoplon with datascript? how hard would interop be?

thre has been a lot of work there, no issues really

cool

maybe nooe of the datascript users are in here at the moment

I could ask on #datascript

about using hoplon with it

oh yeah

if possible, I still would like to know how the reagent/react model differs from hoplon, if only for my own intellectual curiosity

hm ok

i can do a hand waving type of explanation

that would be useful

haha ok

so the idea behind react is to emulate an immediate mode rendering surface on top of the DOM

virtual dom, I have heard of that

that is to say make the DOM stateless, like pixels on a screen

yeah

so the pattern with react is appealing because you make clientside applications (applications that run in js in the client) that are organized the way you'd make a php application or something

in php you have a very simple request -> generate html -> render new page

each request results in loading new html that was generated by php program in the server

the php program is usually stateless

so this is nice in a lot of ways, easy to think about, and so on

now react makes this happen in the client by using a virtual dom

the user interacts with something in the page, triggering an event handler

the event handler makes a "request" to the "php backend"

the "request" here is a function in the client

and the "php backend" is the clientside code and state

anyway the function that the handler calls is like the rendering function

when you call it with parameters it blows away the html int he DOM and generates a new DOM from the html generated by the rendering function

just like how you'd do it with php

but if you actually blew away the entire DOM and recreated it every time anything changed, it would be a lot of work

very slow

ah so diffing comes in

so they do the virtual dom thing, where they make a diff and apply a patch

yeah

I'm familiar with some of these terms from soaking it up on HN

but I didn't know how they fitted together

cool!

sweet

ok so how you'd use this with react is like this

you might have a single mutable variable, an "atom" in cljs

any mutable thing in clojure will generally implement these interfaces

one of which is that you can add a callback to be called whenever the value in the mutable var changes

it will be called with two arguments, the previous and next values of the var

so what you'd do is keep the state of the client in a single atom

and your render function generates the html (as data) from that, as a pure function

given the contents of the atom, it returns some representation of the html you want in the dom

could be a string, whatever

then react takes that and does the diffing and so on

and updates the actual dom

so now if you update that atom, the dom is rerendered according to your render function

so this all sounds pretty amazing

tracking so far?

yes

ok cool

so there are a lot of issues that crop up once you start making a real application

naturally

thank you by the way

i mean we don't use php to make these things for a reason

like the php way seems so simple at first

but pretty soon you need sessions, and redirects, and so on

and flash messages

pretty soon you're in the weeds

imho the react way gets you right back there

with janky ways you need to manage mutable state

because just like with the stateless php server model, it's very difficult to handle mutable state in that world where everything is nice and stateless

also diffing is a difficult thing to do efficiently

some things are np complete, etc

like diffing a sequence of things

so you need to explicitly add hints so the differ can know more about the dom

like adding unique ids to elements so the differ can track them

things like that

additionally, treating the dom as a buffer you can just write to is an api inversion

it's not really a buffer at all

like a framebuffer or console, yes, because you can just overwrite things sequentially, and the things themselves are stateless

like a pixel does not contain state, it simply has a value

but the dom isn't like that

dom elements are objects with their own states

some of it is even computed by the browser itself (like the width of the element, for example, which is a property of the element, but it can change at any time when the browser decisdes to adjust the layout)

so the dom is not an immediate mode rendering surface, it's a retained mode one

and building an immediate mode thing on top of a retained mode thing is an api inversion, and that never works out well

like building a low level language on top of a high level one

you can't have a non-leaky abstraction when you do that

the leaks you see in the react things is the stuff like the unique indexes you need

and the lifecycle protocols

like IWillMount and IDidMount and so on

huh

callbacks that are called when an element is put into the dom (because you don't control that)

or when it's removed, or before it's removed, or before it goes in, etc etc

there are a ton of them

because react controls allocating dom elements

and those elements may contain their own state

so you may need to override somet hings

so you need callbacks

like run this callback when you put this thing into the dom

run that one when you remove it

etc

but of course once you have those you need before-before-remove

and before-after-before-remove

and so on

anyway that's react

hoplon is the opposite of all that

hoplon doesn't try to make the php model work

the clojure wrappers don't have means to cope with react's faults?

hoplon leverages the fact that dom elements are stateful

*clojurescript

no, it's a fault in the model really

I see

whenever you have an api inversion you'll end up with lots of complexity when you start using it for real

like imagine compiling to ASM that's implemented in JS

yeah

leaky

you'll need all kinds of escape hatches to make it not be uselessly slow

those protocols and whatnot are the escape hatches

do go on about hoplon's approach

hoplon takes the opposite approach

in hoplon there is no rendering

you just make dom elements like normal

so like (div "hi world") in hoplon is exactly the same as

var a = document.createElement("DIV"); a.appendChild(new TextNode("hi world")); return a;

that's not a virtual div, or some cljs type, it's a regular div

you can make a whole DOM too:

``` (page "index.html")

(html (body (h1 "hi world"))) ```

that's a valid hoplon application

you can compile that and you will get a html file (index.html) and a main.js file

which it will automatically load etc

notice how div for example is a function

(div :id "unit1" (span "hello") (span "world"))

^^ attributes

and children

you can construct your own custom elements

so when the model changes, hoplon deals with that by using javelin instead of the analogous diffing

?

(defelem my-list [attributes children] (ul attributes (map li children)))

yes so consider:

``` (page "index.html")

(def clicks (cell 0))

(html (body (button :click (fn [event] (swap! clicks inc)) (text "You clicked ~{clicks} times!")))) ```

that's a program with some state and behavior

oh, that's nice

the :click attribute is used to add a handler for the onclick event

if you pass a function as the value of an attribute it's unambiguous: you want to add a event handler

there is no other useful way to interpret function values as attributes of an element, right?

true

so :click (fn [event] ...) sets a onclick handler on the button

then the (text ...) macro does interpolation and creates a reactive TextNode

whenever clicks changes that text node will change too

but only the text value of the TextNode object

when clicks changes the TextNode itself is not destroyed and recreated or anything

only the textContent or whatever property of the object is updated in place

automatically of course

equivalent way to do that:

``` (page "index.html")

(def clicks (cell 0))

(html (body (button :click (fn [event] (swap! clicks inc)) :text (cell= (str "You clicked " clicks " times!"))))) ```

last line

cell= makes a formula cell

just like in a spreadsheet

and the :text attribute sets the text content of the element

whenever the formula changes, the text content of the element is updated in place

there are a few things to notice

first, this looks kind of like a normal computer program, not some wacky special webapp

like any computer program ever made has this kind of format

like pull in library code, declare module at top

then initialize state after that, set things up, define things

then finally you start your IO loop

where you read input, do work, and maybe wait for more input if you're making an interactive program

the IO loop is the (html ...

the dom

the dom you create there with that (html ... expression

how would that snippet look different if it was in Reagent/re-frame?

so you can basically use all the normal development concepts that apply to normal computer programs

i'm too rusty with that to do it justice

okay

I'll look up examples and compare

but another thing to see in the hoplon one is that we leverage static allocation

like the dom elements that are allocated are allocated almost declaratively

static allocation means that the "lifecycle" of an element is very simple

if you want to do something before some element is created, you just put the expression that does the thing above the expression that creates the element

like a normal lisp program

there is no need for lifecycle protocols

very cool

more tricky is when static allocation is impossible

like if you have N things, but you don't know what N is at compile time

like a table of data you want to display

and you don't know how many rows there will be

things like that

yeah

so we developed some macros to help with that, to preserve the benefits of static allocation, but also allow for dynamically adding things at runtime

I've had to deal with table libraries like that in the past in JS

can you give an example of the metaprogrammed "dynamic" allocation?

``` (def things (cell ["one" "two"])

(html (body (ul (for-tpl [thing things] (li :text thing))))) ```

so that would result in a <ul> with two <li> children

for-tpl is the macro?

yes

there is a corresponding regular function, but the macro does some nice syntax sugaring to make it look nice

so that's like a for loop, it assigns thing to a javelin cell that contains the value of the nth item in things

if I found myself in a similar situation, would making a macro like for-tpl to get around it be difficult?

macros are useful when there is boilerplate code that can be emitted at compile time

the macros can eliminate the boilerplate

right

what happens if you want to have the number of list items be determined by a cell?

there are a lot of subtle issues that for-tpl solves

the number of items is determined by a cell in the example above

things is a cell that contains a number of items

oh I didn't catch that

neat

the interesting thing is what happens if you add a new thing, or remove a thing from the things vector

suppose you remove the last thing, so it looks like ["one"] instead of ["one" "two"]

you will see the dom update, the second <li> will disappear

but it's not destroyed

huh

it is simply moved into a pool

so it's not in the DOM anymore, but it's still available

so now suppse you add an item back to the things

aha, sorta virtualized as in react

but on destruction instead of prior to creation

like ["one"] -> ["one" "three"]

now the for-tpl thing will realize that it needs to allocate a new thing

and it also sees that there is an element in the pool it can use

so it doesn't create a new object, it just puts that one back in the dom

now this is probably the most important part:

that element that was taken out and then put back in

it's already automatically in the correct state!

remember the for-tpl made that thing cell that contains the value of the nth item in things right?

yes

and when the <li> was created, we bound its :text attribute to thing

so now that we added a second item back to the things vector

the text of the element in the pool automatically updated!

just like you'd want

and it goes back in the dom and all looks as you expect

we took great pains to make managing state robust, simple, and correct

I'm slowly realizing that you must be involved in the development of hoplon haha

basically if you can avoid deallocating and reallocating elements, you can avoid 99% of the complexities of managing state

haha yes

i should have made a biased answer disclaimer

nah

you provided an objective explanation of the benefits

even if it came from biased motivations

why do you call Javelin's paradigm dataflow instead of FRP? what's the difference?

frp is a much bigger thing than javelin

we did a bunch of research into frp and decided we only needed a small set of features

like for instance you won't want to implement fizzbuzz in javelin cells

javelin is just to route data around

like a spreadsheet

frp kind of tries to do everything

okay I see

alright, I'm fairly sold on hoplon at this point

but since you've been listing all the benefits and cool aspects of hoplon, could you enumerate on what you don't like / hate / would like to change about it?

one thing that you need is mobile app and so on

hoplon doesn't have as much there as say react native

that's far less important to me than desktop and web, and electron ought to work just fine with hoplon since it works with clojurescript well, I imagine

but i have made apps for Android and iOS using like trigger. io

also hoplon isn't really great for brochure type sites

right

but neither would react

because load time is not as fast

react can do more optimizations the

hmm

like prerendering the html

because the dom is still separate in react

it's not part of your program like it is in hoplon

perhaps you guys could prerender as an optimization at the start of an app. does that make sense?

yes we do that like for search engines

but it doesn't help the js load faster

and in hoplon the application is a js program completely

like your program must create the Dom

right

but could you not run that js server-side in Node with default values in the cells?

so that greatly simplifies managing state which is great

the problem is that those functions that create the Dom can have state

you can't just scrape it and capture all the state

okay

because some state is encapsulated or hidden

that's a good thing though

encapsulation is how we make large programs be same

i mean sane

how bad of a performance hit is there with hoplon for booting an app?

not sure

probably less every year

as devices get faster

but right now

hoplon isn't getting any slower

you probably need to try it

i don't have recent numbers

okay

especially if you're new to all this

are devs generally happy with hoplon's performance from the feedback you guys get?

i think prototyping in hoplon will give you a good start

I'm definitely going to give it a try, I'm just asking

yeah we've never really needed to optimize it

because that's never been the bottleneck in any real application

okay cool

the bottleneck will be the backbend etc

performance in the Dom, even for very large apps is extremely good

hoplon never updates anything but the minimum number of changes

because of the way javelin cells work

a cell only updates if a cell it depends on changes its value

it's a sort of diff

but the inverse of how react does it

push-based dataflow

yes, unidirectional also

another difference from frp

FRP is bidirectional? I wasn't aware of that

or you mean FRP is pull-based

it's everything

both

I don't understand what you mean by that

i guess frp has become a vague term

but like kenny tilsons Cell stuff

that's frp

it has lazy cells

my understanding of FRP has long been of dataflow with pure functions operating on reactive values

that's pull

though which direction I've been hazy on

also javelin formulas need not be pure

which is a huge simplification in practice

like a javelin cell can keep track of some internal state

so you can encapsulate that state right where it's needed

without needing to introduce new primitives to shim it into the model

javelin doesn't have any laziness

it's eagerly updating

but it prunes updates from the graph if their dependencies haven't changed

hypothetically speaking, what would be the benefit of it being lazy?

a lazy formula need not update at all until something requests it's value

but then it must be pure

also it's hard for me to see the difference between a lazy formula and a regular function

I see

so we just use functions if we want pull semantics

there is a repo on github with lots of hoplon demo apps

and everyone is friendly and helpful in here if you get stuck on something :D

yeah I can tell!

thanks for spending so much time explaining everything!

np! have fun!