search

aaronc / freactive

High-performance, pure Clojurescript, declarative DOM library
http://documentup.com/aaronc/freactive
Eclipse Public License 1.0
387 stars 27 forks source link

Google's Incremental DOM #54

Open kennyjwilli opened 9 years ago

kennyjwilli commented 9 years ago

Google is working on a new "virtual-dom" project: Incremental DOM. Possibly use this project to avoid freactive having to do its own diff.

aaronc commented 9 years ago

Thanks for mentioning! freactive however will probably not use diffing at all - it has no need for it as everything including reactive sequences is handled via direct binding. If we did need diffing at some point, I have code which does it but in my benchmarks it adds little benefit and I'm not sure the complexity is really worth it. That code is in this branch: https://github.com/aaronc/freactive/tree/experimental-diffing not develop.

GetContented commented 9 years ago

Yeah, the TLDR; version is "Freactive already does this, but better".

Also, Incremental DOM seems to have different use-cases in mind. In particular, it seems to function from a textual-template-is-the-source-of-truth stance, which isn't how freactive works. Freactive hooks up to the DOM directly - no need to walk the DOM, or create a VDOM, or anything. When data changes, Freactive updates its representation in the DOM.

Because it's text-template-first, it's possible to have unbalanced tags. This makes me wonder how Incremental DOM could possibly work with something like ReactJS, as react has a component-centric stance where it's impossible to have unbalanced HTML (because the JSX "template" won't compile), though the technique (walking the DOM directly and doing diffing rather than building a VDOM first) could probably be utilised as an efficiency technique. It's a bit surprising that the existing react VDOM doesn't do this already. You'd think the Facebook engineers would definitely have thought of, and tried, this, and if it were faster and also more memory-efficient, embraced it.