Request for feedback: Virtual DOM for hiccup and macro compilation

[Julien Eluard]

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

[James Henderson]

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

[Julien Eluard]

Hi James,

I saw your ClojureX video about Flow, cool stuff!

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.

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

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 clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[James Henderson]

Hi Julien,

On 13 December 2014 at 13:38, Julien Eluard <julien...@gmail.com> 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 :)

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 clojurescrip...@googlegroups.com.

[Julien Eluard]

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