hi @l1sp3r !

Hi micha

So started looking at hoplon

Really nice

Had a question about performance

Let's say we were rendering a long list of elements

sure

Existing VDom Impls use diffing to only change the existing Dom

So let's say I had a list with 10000 elements in it

ok so a couple of things

And I add an element at position 5000

yeah hoplon will only add one element to the dom

but hoplon has no virtual dom or anything like that

Interesting

hoplon cleanly separates the dom, which is by definition mutable, from the application state, which is data (and immutable, stored in reference types -- javelin cells)

so there is no "rendering" in hoplon

you create real dom elements, that's it

you're familiar with the virtual dom way of doing things?

like react, mithril, elm, stuff like that?

like in those frameworks you have a pure function that emits the virtual dom

that is what gets diffed with the actual dom to produce the delta

and the delta gets applied to the actual dom

the pure function gets a snapshot of the entire application state passed to it

it computes the next virtual dom from that

to me it's similar to the way a terminal based text editor works

you have the screen buffer

you press a key, and the next value for the buffer is computed

syntax is highlighted etc

then you print that

but there are layers of optimizations like clipping and double buffering or whatever

to reduce the redundant printing

compare that to an editor you might make in a browser

where you don't just have a terminal display

you have something more complex than just an array of pixels

you have a tree of stateful objects

so in this environment it would be natural to have elements in the tree manage their own state as much as possible

so if you type in one paragraph, the other paragraphs don't need to know about it, or be rerendered or anything

like with contentEditable

i see vdom as like emacs

and hoplon is like contentEditable

with hoplon the diffing is done in the data

(page "index.html")

(def count (cell 0))
(def color (cell= (if (= 0 (mod count 5)) "red" "blue")))
(with-interval 1000 #(swap! count inc))

(html
  (body
    (p :css (cell= {:color color})
      (span (text "count = ~{count}")))))

So my concern is that the list which will be large is held in a cell

if you run that and observe the DOM in chrome dev tools you will see that only the parts of the dom that need to change will change

So how does hoplon do list diffing?

so what you see in the example above is nice becuase all allocation is static

there is no dynamic allocation of dom elements

this is evry fast and good etc

*very

but of course you need to dynamically allocate dom elements too

most common case is a sequence of things need to be allocated

so the loop-tpl macro does that

but it leverages static allocation

which is the best of both worlds i think

it allocates into a pool

and when the list grows it allocates more elements

when the list shrinks it removes the elements from the end and puts themn back in the pool

if the list grows again they are replaced back into the dom

but the key thing here

is that the linkages between those elements and the application state are preserved

Ah so an insert would cause things to shuffle down

no

like the element at position 0 in the dom is always at position 0

it never moves

I'm thinking, if I swap two elements in the source list, say at the beginning and end

the properties, like the textContent of a node might change

well you don't do that

you swap the data that those elements have wired up to their properties maybe

but the elements stay the same

No I might do that at the model level

it's like the hotel guest situation

you build the hotel and it has 100 rooms

you might have all the visitors move down one

but the rooms stay the same

the people in them change

for example

(page "index.html")

(defc items ["one" "two" "three"])
(with-timeout 1000
  (swap! items conj "four")
  (with-timeout 1000
    (swap! items #(vec (rest %))))

(html
  (body
    (ul
      (loop-tpl :bindings [item items]
        (li :text item)))))

so that will initially be a list of 3 items

after 1s a new item is added to the end of the list

so a new element is allocated and inserted into the dom

the first 3 elements in the list are unaffected

then after 2s the first item is removed

from the items cell

what happens then is that the last element in the dom list is removed from the dom

but the text content of the lis are updated

basically it works fine, no performance issues

if you're making 10000 list items that's probably a UX issue anyway

because people can't see 10000 things at the same time

we have done very little work on performance, beacuse it's just not an issue

there's some concern for the data stored in cells

if you have computationally expensive formulas and a lot of data

yeah that's just a limitation of browsers really

yeah, thinking how that's "solved" in react world

i don't think it is at all

the react model makes that worse

because there is no pruning at the data layer

you recompute things all the time, and the diffing prunes the dom updates

vs javelin pruning updatees in the data layer

so they never get to the dom in the first place

that means you don't do the data layer computations unnecessarily

I was thinking about the javelin always-consistent-cell-graph and e.g. re-frame event->handler->state-update->react-rerender models

guess in the end that's identical

re-frame is based on the hoplon model

so yes

if you have something that can be done async, you'll have to split it off manually

explicitly

yep

since formula cells are constructed from functions you can make hand optimized javascript for them too

you don't need to use the cell= macro

we have a pretty huge application now, similar to the aws console in terms of the problem it's solving

no performance issues, it's super snappy

didn't do anything special to make it that way

the only thing we need to do is carefully manage how we fetch state from the backend api

so we have a few macros for that

to manage caches asynchronously

things like that

but one thing it does is it supports an infinite number of anything in the UI, without degrading performance

because our customers can use our api to create thousands of things very quickly

and then they want to use the UI to manipulate them

so we needed to develop a strategy for dealing with that, because the data even for a single user won't fit in memory in the browser

and we needed to have very efficient queries in the backend api

on the other hand, I have a spreadsheet-like application which allows constructing financial scenarios, using datascript to manage the pretty complicated UI model and events over websocket to allow realtime collaboration over the spreadsheet (ala google docs)

so two pretty different things working great with Hoplon

@l1sp3r: btw, another big benefit of Hoplon is Micha who'll write an essay to answer a question pretty much any time

hahah

sorry bout that i get carried away sometimes

I wouldn't want it any other way

@dm3: looking at mutation observers

there is the addEventListener thing too, seems to be supported in all evergreen browsers

http://caniuse.com/#feat=addeventlistener

how would you use that?

it's the older spec

i think it does the same thing as mutationobserver but in a different way

probably a tradeoff there

something needs to dispatchEvent on the target, no?

addEventListener is the basic thing if I understand correctly

it doesn't know about DOM mutations

really? what's the point of it?

well, how would you add an event listener?

e.g. for click

i mean this:

https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Mutation_events

oh, this is what preceded the MutationObserver but got deprecated

right

but i suspect it's better for some things

may be

but then it might get dropped completely at some point

yeah

the future of browsers is seen only via a scanner darkly

https://davidwalsh.name/detect-node-insertion

clever boy

oh man

@micha: did you ever run into needs/wants to reproduce clientside errors or reproduce the complete state of the client? I know the guy behind re-frame touts that as a great benefit of the single state map. Remember CircleCI people blogged about this feature helping them reproduce bugs, etc... What do you think?

not really, honestly we don't have those kinds of bugs

like we have bugs of course, but they're always very easy to repro

the heisenbugs are from undisciplined mutation

javelin eliminates that

the tradeoff there is that your components get a lot more complex when you have the one atom

because you can't break the problem down and use scopes to manage it

like why don't we make all applications with just one atom containing the whole state?

I understand the tradeoff why reinvent namespaces

so i think they're causing the bugs that they're only able to track down by replaying

if they didn't have the one atom they wouldn't need to replay to repro

hehe

i found that to be the case with things like the component stuff in clojure

it's impossible to reason about the huge blob of map data

and how it got into a weird state

because there is no encapsualtion of state there

Thanks guys been reading responses, v helpful

do you think we need a travis badge on the github page?

for me it's useful to see if tests pass for PRs and stuff

but i imagine people would not be using master, they'd be using a release version

so the badge seems redundant

Hi

I have a following issue with hoplon and semantic-ui mix

Following works in plain JS: http://codepen.io/badyl/pen/yOvOPM

but not in hoplon: https://github.com/pbzdyl/hoplon-semanticui-issue

With hoplon, when I click in the dropdown field I am getting an error in JS console:

semantic.inc.js:18207 Transition: Element is no longer attached to DOM. Unable to animate. slide down in <div class="menu" tabindex="-1">…</div>module.error @ semantic.inc.js:18207module.animate @ semantic.inc.js:17527module.initialize @ semantic.inc.js:17425(anonymous function) @ semantic.inc.js:18322jQuery.extend.each @ jquery.inc.js:648jQuery.fn.jQuery.each @ jquery.inc.js:270$.fn.transition @ semantic.inc.js:17373module.animate.show @ semantic.inc.js:7050module.show @ semantic.inc.js:4536module.event.search.focus @ semantic.inc.js:4966jQuery.event.dispatch @ jquery.inc.js:3074elemData.handle @ jquery.inc.js:2750jQuery.event.trigger @ jquery.inc.js:2986jQuery.event.simulate @ jquery.inc.js:3301handler @ jquery.inc.js:3552
reload.cljs:63 Reload

I can see the mentioned element in the DOM tree in dev tools

but I suspect that hoplon might be removing and adding again some elements when it detects that semantic ui is changing the DOM

@piotrek: I think you had the same exact issue last time, no? When you added a span somewhere in the autocomplete and the issue went away?

have you tried with latest Hoplon built from master btw?

yeah, but then I was using a static list of options and a workaround was to create a dummy element inside a div

but with a remote content loading I have to use a select element

and the workaround no longer works

so I wanted to find a fix for a root cause

@dm3 you have a great memory

it seems I do

I will try to get dropdown with div instead of select working but I would like to fix the problem anyway and don’t use workarounds

I'm afraid you'll have to debug which element that is that gets detached (or never attached in the first place)

try with latest master as an interaction with jQuery.remove was fixed there that caused issues

thanks for a hint - I will try the latest version

it seems that I should get the div version working too so a workaround might work

also I'd add the element to a div inside body as I think body gets some special treatment in Hoplon and might have more bugs. I might be completely wrong though.

will try that too

i think the jquery .remove() thing might be happening here?

we did fix that in the latest master

@micha - I was wondering if you have thought about/worked with Elm (or another library using Applicative FRP instead of Monadic FRP implemented in Javelin). It seems like it also allows for clean abstraction of functionality in modules. The biggest theoretical difference is that with Applicative FRP you're forced to declare all your inputs beforehand, while in Flapjax/Javelin they can be created on the fly. However, in real Hoplon applications the graph is pretty static too (if you consider things like loop-tpl just reusing a "template" of a subgraph)

@dm3: we went crazy with that stuff before we settled on javelin, yeah

hey this might be off topic as it’s probably more of a cljs question, but since it’s a hoplon app i’m working in i’m just going to ask it here: is it possible to use multimethods where the defmulti is defined in one namespace and defmethods can be defined in one or more other namespaces?

@raywillig: sure

@raywillig: sure, you just need to require the namespaces

so in the third namespace where I want to use the defmethods, i have to require both the namespace with the defmulti and the one(s) with the defmethods I want to use?

yes

but I also have to :refer the functions I want to use, right?

you don't have to refer anything, it's just for convenience

so like with hoplon.core/do! for example

that's a multimethod defined in hoplon.core

suppose there are defmethod calls that edfine dispatches for that multimethod in some other namespace

like foo.bar

and now suppose you have a 3rd namespace my.ns where you want to use the do! multimethod

in my.ns you need to require hoplon.core for sure, so you can use the hoplon.core/do! name

you also need to require foo.bar if you want those dispatches to be installed

because they get installed when that namespace is compiled

and it gets compiled the first time something requires it

if something else already required it then you're ok and you don't strictly need to require it again

ok, cool, i think i get it

defmethod mutates the multimethod

but it can only mutate it if you evaluate the defmethod expression

the only way you can evaluate expressions is to require the namespace at some point

@dm3: what do you think about "classical" FRP vs javelin

it seems like the way Javelin expresses signals is best suited for a kinda-mutable environment of Clojurescript

I have read some of Elm's thesis but can't recall much

I think he went for more static/correctness guarantees with the Applicative approach

which eliminates some of the problems with unbounded accumulation of events

i remember seeing some pretty serious flaws in the type stuff in elm

i mean typesafe javascript is nonsense i'm pretty sure

unless you're content to run your own vm or something

well, I think it can work if you develop in your safe little world and sanitize anything that goes outside

I've opened the thesis again and can see that he mentions Flapjax favourably on the accounts that are signifcant when comparing Elm to other FRP frameworks: 1. elimination of space leaks through not being lazy 2. light conceptual load through not mentioning the monadic machinery

the way you need to interop with javascript though in elm

is basically crippled by the type business

and javascirpt interop is the name of the game in the real world

like guile scheme vs clojure

yep, I guess that's why we program in Clojure/script and not Scala here

so we'll agree on that

as you can imagine the guys in #scalarians Slack would find a 101 argument to disagree

hahaha

or the haskelloids

yeah

but i mean the fact that elm does interop by adding runtime assertions

as i understand it

that's the worst of all worlds

like you have runtime enforcement of type stuff

which means lots of NPE type nonsense now

plus the crippling of the type system when you're designing your abstractions too

oh man, how I can see some people having a red face and gasping for air after you've said that

some people maintain a view that you can't even have an abstraction without the types

and I understand them theoretically

but practice of web dev is so far removed from theory, for better or worse

I looked at elm

To be honest it's pretty elegant, was put off by the complexity of go using an element

Sorry autocorrect - complexity of focusing an element

Something which should be trivial became complex, sure they'll get it fixed in time

@dm3 @micha updating to the master version fixed my problem - thanks!

when will the new version be released?

@piotrek: in the next few days, hopefully!

yeah i guess i've never seen the joy of type systems

regarding types: https://dl.dropboxusercontent.com/u/7810909/talks/parametricity/4985cb8e6d8d9a24e32d98204526c8e3b9319e33/parametricity.pdf I kind of agree with the material, but on the other hand I have the experience and joy of working with Clojure and the painful experiences of designing abstractions in Scala. I guess I'm just not smart/interested/motivated enough...

i've never seen the benefit of having an opinionated compiler

my code doesn't have any more bugs than average

the above mostly expands on the "Free Theorems" ideas by Wadler

when i see haskell programmers making finance applications without unit or integration tests then i'll be convinced

I've used Scala and Clojure extensively in financial services

which has more unit tests? just curious

i hope i'm not coming off as being argumentative, it's not my intention at all

No that's fine

I have no agenda

neither do i

It was interesting, was more about the previous Dev experience of the team than the language

On one team which was using scala, turned me against TDD

Massive amounts of complexity leaked through to make things 'testable'

i am interested in like how many tests are needed to be confident of correctness

Locals clearing makes a huge impact on how you write code also

my experience is that clojure programs have the same number of tests more or less

as typed languages

this indicates to me that the compiler isn't testing the right thing at all

I used generative testing on one clojure project. That was v useful

yeah that's the caddillac of testing for sure

I wouldn't use scala as a poster child for statically typed languages though

yeah it's insane

i was thinking haskell

Haskell is much cleaner

a very sane language

and it's more powerful in a typed language like Haskell, actually. If you have a properly typed abstraction, and you come up with good properties - you have a very good chance of the implementation being correct

it's just that the barrier to entry is so damn high

Things like heterogeneous maps are v cool

i still think that if this were the case you would see a big difference between the number of tests in real demanding applications between haskell and clojure

you would need far fewer tests in haskell

but i don't thnk this is actually the case

maybe there is

there's Jane Street running on OCaml

Well if we're talking typed languages, how about Idris ?

don't think anyone is writing business-related apps in Idris

Maybe the issue isn't that type systems aren't helpful, maybe it's that they're not good enough yet

the fundamental flaw that i see is that the compiler is essentially trying to run the program without running the program

the type system comprises a sort of shadow evaluator

this seems highly suspect

with dependent types the difference between the compiler and the program is even less apparent

and the more complex the type system is, the more of a lisp it becomes

even GHC with proper extensions has a Turing-complete type system

Yes I do see a convergence

until it becomes itself turing complete and the halting problem applies to it

I think halting problem is overrated

hahaha

Issue is we don't designed systems where computation can be interrupted correctly

there are so many ways to build functioning software

depending on what you optimize for

Agreed

in the end it all depends on individual ability/strategy

for me expressive power beats type systems by a large margin, because more powerful abstractions can give the human the power to see if it's correct or not

if you can't tell if your program is correct, in lisp you have so much power to refactor so it's clear

well, I think you can have abstractions in Haskell as expressive as the ones in Clojure

One thing Haskell gets right is its emphasis on immutability

more so, depending on how you define "expressiveness"

but the barrier to understanding the abstractions is much lower in Clojure

well like hoplon would be difficult or impossible to do in haskell i think

Does hoplon have its own compiler?

no it's just a cljs library

there is a hoplon compiler, but that's just to emit some cljs

to work around some of the design decisions of the cljs compiler

Interesting

the only thing the hoplon compiler does is generate the html boilerplate and to refer the hoplon core vars into your namespaces so you don't have to namespace qualify them

because of the way the cljs compiler works you can't do :refer :all in a cljs namespace

so you'd end up with like (hoplon/div ...) all over the place

which is not cool

Is the clojure script compiler online yet?

yesh it's self hosted, is that what you mean?

Eg I'd like to be able to call: (compile-to-js f)

From my clojure code

yeah so yes and no

Where f is just a function pointer

I don't ask for a lot do I

you can call the clojurescript compiler from a clojure program and generate javascript

but for a real application you will want to optimize that

No I don't

yeah you don't have to

My domain is apps over a LAN

Minification is totally unnecessary

yeah i mean the google compiler also does performance optimizations

keyhole optimizations of various kinds

but that might not be a big deal for your use

Yeah for me that's needless optimisation which complicates the build chain

yeah you dont need it

one thing you might want is to use the self-hosted cljs compiler

then you have the normal lisp eval and whatnot

maybe you compile the program in the client even

alan made a sort of jsfiddle thing for hoplon the other day

Interesting

like for people to try it out in a webpage

So here's my domain

I want to build a spreadsheet notebook style interface for financial companies

There's a language behind it

DSL if you will

Looking at nicking the syntax from R

Ideally the user can write a render function for some data type

That'll get transpiled on the server and send back down to client dynamically

hehe, I have a vaguely similar application that I'm working on

Interesting..

Where u based?

Switzerland

V interesting

I'm in London

Zurich?

nearby, Zug

V cool, would be interested in what your doing. Maybe compare notes

Got this crazy idea to build a prototype and start a business

But from spending 15 years working in financial services know there's a desperate need for a product like this

the spreadsheet seems to be the ultimate form. I think folks at OpenGamma have realised that, for example

they're building integrations into Excel

spreadsheet is the optimal computer interface imo

Think there's a lot more that can be applied

Been think very hard about how you adapt spreadsheet interface to report interface

Which can deal with varying size tables etc

Also about code promotion and versioning

this is pretty much exactly the goal of hoplon

I have to get some sleep, but if you want to discuss further drop me a line at: <mailto:[email protected]|[email protected]>

Thanks for talking, been a fun discussion, first of many I hope

@dm3: have you seen Backus' FL language?

@l1sp3r: you are always welcome

I'll be back :)

nope, I haven't

yep, a good discussion

I also have to get some sleep

glhf

http://worrydream.com/refs/Backus-CanProgrammingBeLiberated.pdf

that's like a 3rd form of functional programming

with i think the same potential for type-safeness

but without the type system