Hi Julien, On 13 December 2014 at 13:38, Julien Eluard <[email protected]> wrote: > > Hi James, > > I saw your ClojureX video about Flow, cool stuff! >
Thanks, glad you enjoyed it :) > > I believe there are some synergies between a lower level hiccup Virtual > DOM style library (direction hipo might evolve) and the various UI library > based on hiccup, either relying on React or implementing their own DOM > manipulation strategies like Flow. Ideally those libraries could just use > hipo (or equivalent) and focus on the higher level features they provide. > If I understand you correctly, the approach you're looking into for Hipo is what Flow currently offers - you refer to it as option 2 in #9 - expanding the Hiccup forms at compile time and generating the necessary update code. In fact, the code you specify is quite similar to the code that Flow generates :) One area that Flow doesn't currently do a lot in is static analysis - inferring (where possible) the state -> element dependencies at compile-time. It currently does this at runtime, but I'd like to move as much of this as possible to compile-time in the next version of Flow. I've had a few thoughts regarding how to do it, but haven't made much headway as yet - if you've got ideas about what could be inferred, what properties such an analyser should look for, or how it could be implemented, it'd be great to chat through them - it seems like we've got very similar plans here :) Flow does, however, maintain as much of the DOM as possible - you say '[in] most cases a complete diff is not necessary as the general element shape is usually kept intact. In our example only li children change, in one of 3 ways: ...'. I absolutely agree - this is one of the core implementation principles of Flow (you can see it in action at https://github.com/james-henderson/flow/blob/0.3.0-branch/src/flow/forms/node.cljx#L81, if you're interested - each node is only created once ($el, here) and we can return that node every time, just updating the styles/attrs/children if necessary) Obviously, if I've misunderstood the aims behind Hipo, let me know :) Likewise, if Flow is doing a fair proportion of what you want to achieve in Hipo, but is missing a killer feature, or isn't quite how you'd like to express UIs, please let me know - I'd really appreciate the feedback! As an aside, if it helps, I did consider your option 1, but decided against it on the grounds that Facebook/React/Om etc will probably do a much better job of fast DOM diffing than I could ever manage! If nothing else, given the popularity of Om+React within the ClojureScript community, any alternative solution based on DOM diffing would have to be *much* better to justify fragmenting the community :) Don't let me put you off though - if nothing else, it'd be a very interesting/challenging project! Cheers, James P.S. I'll post this onto your GitHub issue as well, feel free to continue the conversation wherever it's easiest :) > To achieve this hipo needs to provide the proper hooks so that it is > flexible enough to be used in various scenario. I created a separate ticket > [1] to start the conversation around this. > > Please feel free (and anyone interested) to participate! > > [1] https://github.com/jeluard/hipo/issues/10 > > Cheers, > Julien > > > 2014-12-12 14:44 GMT-03:00 James Henderson <[email protected]>: >> >> On Tuesday, 9 December 2014 20:45:47 UTC, Julien Eluard wrote: >> > Hi, >> > >> > Following the release of the hipo library (DOM templating based on >> hiccup syntax) I started thinking about expanding its scope to updates. >> > >> > >> > >> > Applying Virtual DOM style techniques to hiccup template at macro >> expansion time might offer opportunity for even more optimisation. >> > I detailed this here: https://github.com/jeluard/hipo/issues/9 >> > >> > >> > I would be interested in any feedback before I invest more time into >> it, especially if some important details have been left out or the whole >> approach is too naïve. >> > >> > >> > Thanks! >> > Julien >> >> Hi Julien - this sounds pretty similar to the approach I've been taking >> with Flow (https://github.com/james-henderson/flow) >> >> Flow doesn't use a virtual DOM, but does generate the ClojureScript >> required to effect updates at macro-expansion time. Currently, it's quite a >> naive macro-expansion (but does support reasonably fast updates) but I, >> like you, believe there're more possibilities for using the information we >> have at compile-time to get better performance :) >> >> It's in alpha at the moment (but pretty stable and performant enough to >> start playing with) - would be great to chat through ideas! >> >> James >> >> -- >> Note that posts from new members are moderated - please be patient with >> your first post. >> --- >> You received this message because you are subscribed to the Google Groups >> "ClojureScript" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/clojurescript. >> > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to a topic in the > Google Groups "ClojureScript" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/IxbyPOQd7yI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
