Fork me on GitHub
#hoplon
<
2015-09-04
>
alandipert12:09:51

argues against javelin and in favor of dirty checking, basically

alandipert12:09:49

i think the primary hoplon consideration is the ability to separate the way something looks from the way it behaves... which leads to "strict" dataflow, because we know from clojure that lazy things can be hard to compose when they have resources (files, objects on screen) under them

raywillig16:09:26

@alandipert: that paper looks pretty old. I think they have a pill or a cream now for premature evaluation

alandipert17:09:16

we need a rimshot emoji

raywillig18:09:02

actually it'd be nice to have that as one of the sounds for speak

raywillig18:09:37

@alandipert: on a serious note, I haven't experienced with Javelin any of the phenomena they mention in the article. Do you think that means they just didn't learn as much as they could in their 10 years of investigation?

alandipert18:09:32

my guess is they are leaning toward the lower level abstraction because they were building on X11, not the browser - they kind of had to build their own DOM etc

alandipert18:09:07

and as implementors of the DOM it makes more sense

alandipert18:09:24

also because of that they probably couldn't imagine wanting to use the same state machine with multiple UIs, since the only UI that existed was the one they made

alandipert18:09:00

who knows though, i'd love to show them hoplon some day and see what they think

raywillig18:09:47

it's interesting that all of those assumptions were unstated. it makes it seem as if they are making pronouncements about universal "betterness" rather than for their specific environment

raywillig18:09:12

those guys must all be retired by now, or at the very least as old as me 😛

alandipert18:09:48

actually a guy who works here at adzerk worked with one of the authors

alandipert18:09:53

as an undergrad

alandipert18:09:13

and says they're all still pluggin'