@flyboarder: hoplon doesn't itself

but there are a number of libraries you can use

in combination with the on! multimethod

hoplon basically supports the events that jquery supports

so if I wanted to use jquery mobile, do i just need to include the lib?

does that add events to jquery's event system?

if so then yes

i have used hammerjs in the past with good results

https://github.com/tailrecursion/hoplon.hammerjs

that's an example

it won't work as is, needs to be updated for hoplon 6

http://www.w3schools.com/jquerymobile/jquerymobile_events_touch.asp

the demo there seems to use regular jquery when accessing the touch events

should work

that will have to be a tomorrow thing 😛, what namespace changes are happening for on!/do! i saw that circulating here earlier

so on! and do! are multimethods

which will be defined in hoplon.core as always

but multimethods can be implemented anywhere

eg the individual implementations of the multimethod functions

so for instance (div :css {:width 100} ...)

somewhere there would need to be a

(defmethod do! :css ...

but not necessarily in the same namespace as where do! multimethod itself is defined

oh ok, so the implementations are moving

so we can move the existing implementations, which are based on jquery, to a special namespace

and make ones based on goog or whatever

then whichever one of those namespaces you require in your program will be the one that provides the implementation for the multimethod

can you override the implementations? like :click for example?

yes

multimethods are just basically mutable maps

underneath

ok im thinking of making click call tap on mobile so I dont need to implement both everywhere

but ill look into that more tomorrow i think

you can call one multimethod from another of course

or use get-method

thats interesting tho, having multiple implementations of attributes

yeah hoplon itself really doesn't need to provide things like :click and :css etc

just the framework for those to be implemented in

hi

hi @lewix !

how does working with hoplon compare to reframe

like how do you mean?

anything in particular?

hoplon seems a tad old to me since it only relies on jquery. Am I missing something?

well when you manipulate the dom you need to have a dom compatibility layer

and frankly jquery is miles ahead of anything else

no virtual DOM

even virtual dom things need a dom compatibility layer

when they manipulate the dom

but with hoplon you don't use jquery directly

micha: have you worked with 'anything else' before/

it's just what hoplon uses underneath to do simple things

sure

like when reactjs diffs the dom and applies changes, it needs to manipulate the dom

there's a nice presentation by Micha

trying to find in Hoplon Wiki...

https://www.youtube.com/watch?v=UoZyyo2Bwr8

micha: did you just say that hoplon uses the virtual DOM underneath to do simpel things?

@lewix: no virtual dom in hoplon

dm3: I'm listening to it right now; with a very open mind - however, I must admit I'm not convinced

it uses jquery to do simple things like event handlers, reliably set css, attributes, etc

what's exactly holding you back? jQuery?

I'm coming from a react/redux workflow, I tried reagent, reframe/reagent, and rum, now I'm looking into hoplon ; I'm still not sure what the later brings to the table compared to the aforementioned @dm3

for me personally - sane javscript integration through absence of React and simple state management through plain vars in namespaces

dm3: have you used react or any react-related libs before?

yes, one Om project, one with Re-Frame

Om doesn't count 🙂 It's rocket science

not Om.next

i see

how far did you go with re-frame dm3

micha: nice presentation

not sure how to answer that 🙂 a "working project" far?

dm3: I see. how's Hoplon performance?

fine for my use case

performance is fine in real-world applications

not for games maybe, i dunno i do't make games

todomvc with a million todo items probably not good performance, but that's a useless application even with good "dom rendering" performance

micha: so in a nutshell in terms of performance virtual dom > than javelin ?

depends what you mean by performance

i'm saying that that's never the bottleneck

in my experience

so it's a pointless exercise

the bottleneck is interaction with servers and working around the limited memory available and nonexistent local caching options

hoplon naturally minimizes dom manipulation operations

but in a different way than reactjs

i think in most cases hoplon actually performs fewer dom manipulations

maybe in all cases

in react the dom manipulations are pruned at the DOM layer

via "dirty checking" (diffing)

in hoplon that's done in the data layer, in javelin

stupid question: is javelin built on top of rxjs or something?

no it's a clojurescript library

no dependencies

well no dependencies other than the priority-map datastructure

One thing that I think works smoother in Re-frame land is hot reloading. Re-frame forces you to keep most of the state in one map and :on-jsreload rerenders pretty much the same state you had. In Hoplon you have a lot of state scoped to the defelems that gets thrashed on reload.

hmm

micha: thanks for the info

any time! good luck 🙂

do you have a global store in Hoplon (kind of like redux)

you mean a single atom containing the entire state?

in react we use flux like pattern to manage complex state. a predictable state container, the only way to change the state of the app is to emit an action that transform the state tree

hoplon is most similar to reframe

i believe a lot of it was based on things in hoplon

unidirectional dataflow, etc

there is no framework around it, as such

it just naturally falls out of the choice of abstractions

i.e. the javelin cell reference type and the hoplon linkage between cells and element properties

https://github.com/hoplon/castra#dataflow

there's a diagram there you can see

and compare with re-frame

that library, castra, is the cqrs backend rpc thing

similar to like falcor or whatever

separate from hoplon itself, optional

there is no need for a state container or to emit actions in hoplon

because the javelin cells correctly process updates in dependency order

micha: I see. thanks ill give it a try

and suppress spurious updates, so the update fns don't need to be pure

which is pretty crucial in a real-world application

what's crucial? didn't get that part

having stateful reactive things

like with reflux your updaters need to be pure fns

javelin formulas do not need to be pure

this eliminates a ton of framework and special conventions

and this, in turn, makes it possible to form abstractions that are better factored

you can achieve a better separation of concerns when you don't have layers of framework that introduce coupling

I don't think that reflux updaters need to be be a pure; and I believe that having pure fns make your UI code easier to reason about

i was under the impression that updates could happen more than once, and that the order they happen in is not guaranteed

and that would of course make it extremely difficult to reason about any side effects performed in there

javelin does not suffer from this problem

it's really easy to reason about side effects in formula cells

consider for example, this debounce function

the separation of concerns here makes it very easy to understand the side effects and statefulness there

there is very little code there, and it avoids the common mistakes with something as simple as a debouncing mechanism

i have the same thing implemented in core.async, and it's much harder to reason about

and it had a bug we missed because it was hard to reason about

the bug was with the handling of the first update after a long pause

I see; I cannot understand the code because I haven't learned one bit of hoplon yet

I'll get to that later today, and see for myself

that gist was just jaevlin

which is its own separate thing, used in hoplon

it'd be nice to have an actual graph comparing hoplon to react kind of like http://elm-lang.org/blog/blazing-fast-html

eh

my interest isn't in blazing fast anything

because that's premature optimization

micha: if I understand correctly, javelin is a frp framework just like rxjs. However it's implement in clojurescript?

the bottleneck in any SPA i've ever made was not in the dom

at least not with hoplon anyway

we've never even had any need to optimize for blazing

so there is a lot of opportunity there if anyone ever wants to do it

maybe your UI don't require you too, and are not fully SPA, I haven't worked with SPAs for long before I reached performance issues

we've made large hoplon SPAs

especially with angular 1; I eventually swithced to react

well angular doesn't use javelin etc

so it's doing a lot of extra work all the time to achieve "reactive" things

right but my point was in regard to you saying that the bottelneck in any SPA is not in the dom

i guess i mean in a hoplon application

it rarely touches the dom, just as a result of the choice of abstractions

can i see your large hoplon SPAs just so I can refer to it while learning

they're all business applications that are behind logins, unfortunately

so wouldn't it be nice to compare the speed without premature optimization?

we used to have a pretty large SPA on http://hoplon.io, with all the docs etc

but we decided to move the actual content to github wiki for ease of contribution

so that went away

but it was pretty large, like 50k elements probably

and zero performance issues there

oh one more question. is it possible to have custom made middlewares like reframe or redux?

what is that, exactly?

middle of what?

micha: I understand. I still maintain that it wouldn't remove anything to hoplon to just compare the speed to other frameworks without optimization

you're welcome to add hoplon in there, if you like 🙂

http://redux.js.org/docs/advanced/Middleware.html

although i maintain that it's not a helpful metric

it is helpful

it might not be helpful to you

like you will never reach the limit in a real application

the benchmarks are imho mostly foolish ones that are testing bizarre artificial situations

like we made a missile command game one time

just to show why this kind of thing is unnecessary

after working with angular and react i can confirm that the metrics are not artificial

we could have thousands of missiles in flight simultaneously

with explosions and sound effects

and maintain 60fps easily

our render loop was on a 100ms interval

60fps means a frame every 16ms or so

how did we do it?

we used svg animations and interpolated paths

which we would update every 100ms

100ms is way faster than the human nervous system can see

so you can separate those concerns

one part of the application is a highly optimized animation thing

we used svg transforms and animations, but you could use velocityjs or whatever

our actual game logic just updated the paths in the svg rtansforms now and then as the user interacts with the game and the internal state of the application changes

so talking about how many dom elements you can craete per second does not apply to hoplon

because you don't need to do that

if you can't separate those orthogonal concerns then yes, everything in the world is an important, relevant metric

but if you can separate them then some of them are not relevant

so in theory it could be faster...You should market it as such then. It might sounds odd but some people care about those things - react is not actually that much faster than other libs, they just capitalized on that. Sometimes marketing a good lib is as important as working on the lib IMO

yes but that's a race to the bottom

i just want to make applications that make people money in their business

and have the applications not be disposable junk in 6 months

the people i work for don't care about benchmarks

if the app is slow maybe they would

and how do those people make money? through marketing for the most case - how do you reach them? probably through marketing too...marketing is underrated in software development. Bad libs are more popular than better ones sometimes just because of better marketing

but that has never been a problem

that's true

i'm not good enough with that to enter the world of the-latest-big-thing

like facebook is

haha

bro culture doesn't feel good to me

I can't wait to go home and play with hoplon cause you sold it well enough to me

hahaha that's nice of you to say 🙂

i hope you enjoy at least playing with a weird thing

I

we're working on separating out the jquery parts into an optional namespace btw

I'm basically looking for the the right framework for my next SPA.

because the base hoplon functionality doesn't use it

jquery is used only in some of the "custom attributes" that hoplon ships with

I see.

in the past we had that just so you'd have a more or less complete environment out of the box

are you guys the same people doing boot?

but now there is a case for separating it out, as an optional :require

yes

nice

boot was originally the lein-hoplon plugin

🙂

then we realized we were like 75% of the way toward implementing a complete build tool in there

wow

so we said fuckit onward

thanks a lot man. you were super helpful

awesome, any time!

I should probably head back to work. I'll hit you up tonight while trying to grok hoplon

you are welcome to talk about re-frame/om/whatever in here btw

oh I took a look at om, and it felt like rocket science especially for someone new to clojure/clojurescript

vue.js then!

I liked reagent and reframe, played with it for about a week but I didn't like the attitude of the creator

rum seems nice too

it's nice to see comparisons

here is one, i will find a link

https://github.com/hoplon/demos/tree/master/async-webinar

@raywillig made that one

the biggest hurdle for me when coming from Re-Frame/Reagent was not passing things down the "component tree", but rather rethinking the UI in terms of separate namespaces holding pieces of state

yes that's probably the biggest difference between hoplon and react-based things

with react you usually have the single atom, so you can have transactional updates

and then you need lenses or cursors or action signals, etc

hoplon inverts that

instead you just make cells, which are almost like cursors

and they knit themselves together into a single dependency graph

which automatically enforces the transactions

where can i learn about all those concepts: lenses, cursors, action signals, dependency graph...

there's also an issue of making "reusable" components

those are om words

but the approaches are pretty similar across react frameworks as far as i've seen

dm3: no reusable components?

you just have to think about them differently

in Re-frame you get a reusable component by completely decoupling it from the app state

so you have to pass everything in explicitly

callbacks and such

in Hoplon you can have state in the namespace, and you pass in Javelin cells instead of callbacks

@dm3 you can have reusable components in hoplon. You just need to pass cells to those components as attributes instead of defining them as a global vars in component’s namespace

or create cells as local vars inside custom element function