Hi James, thanks fo the honest feedback!
To clarify I intend to keep hipo pretty low level and to focus on creation/update of DOM elements from hiccup representation. I am a fervent believer of the one library does one thing mantra ;) I will look more closely into Flow as it looks like you already implemented some of the things I am considering. Continuing the discussion on github. Cheers, Julien 2014-12-13 15:18 GMT-03:00 James Henderson <[email protected]>: > > 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. > -- 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.
