This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-09-04
Channels
- # admin-announcements (25)
- # beginners (21)
- # boot (161)
- # cider (12)
- # clojure (92)
- # clojure-art (1)
- # clojure-germany (5)
- # clojure-nl (5)
- # clojure-russia (38)
- # clojure-sweden (1)
- # clojurescript (87)
- # clojutre (2)
- # cursive (9)
- # datascript (1)
- # datomic (22)
- # devops (1)
- # editors (33)
- # events (3)
- # hoplon (19)
- # immutant (7)
- # jobs (2)
- # ldnclj (22)
- # off-topic (41)
- # re-frame (34)
- # reagent (39)
argues against javelin and in favor of dirty checking, basically
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
@alandipert: that paper looks pretty old. I think they have a pill or a cream now for premature evaluation
we need a rimshot emoji
@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?
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
and as implementors of the DOM it makes more sense
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
who knows though, i'd love to show them hoplon some day and see what they think
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
ha, true
actually a guy who works here at adzerk worked with one of the authors
as an undergrad
and says they're all still pluggin'