Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Google's Incremental DOM #54

Open
kennyjwilli opened this issue Jul 10, 2015 · 2 comments
Open

Google's Incremental DOM #54

kennyjwilli opened this issue Jul 10, 2015 · 2 comments

Comments

@kennyjwilli
Copy link

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
Copy link
Owner

aaronc commented Jul 10, 2015

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants