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

Add Morphdom #53

Merged
merged 1 commit into from
Apr 18, 2016
Merged

Add Morphdom #53

merged 1 commit into from
Apr 18, 2016

Conversation

whiteinge
Copy link
Contributor

No description provided.

@whiteinge
Copy link
Contributor Author

PR rebased on latest.

@mathieuancelin mathieuancelin merged commit c8abdde into mathieuancelin:gh-pages Apr 18, 2016
@whiteinge whiteinge deleted the morphdom branch April 18, 2016 08:00
@whiteinge
Copy link
Contributor Author

cc @patrick-steele-idem

@leeoniya
Copy link
Contributor

leeoniya commented Apr 18, 2016

I'm not sure this implementation (or perhaps Morphdom itself) does anything to dispel the belief that the DOM is slow; if anything, it shows this to be exactly the case :\

@patrick-steele-idem
Copy link

patrick-steele-idem commented Apr 18, 2016

tldr; in practice, the performance of morphdom will be great 99% of the time.

I'm seeing nearly identical performance compared to React which shows that the real DOM is not really slower than a virtual DOM solution such as React. Admittedly, when garbage collection kicks in there is definitely some lag for morphdom.

With that said, don't judge a library based on one benchmark... While the dbmon benchmark is interesting it is just one use case that is likely not representative of real world usage. Also, morphdom does much better when coupled with a view library that optimizes calls to morphdom. For example, morphdom provides hooks to avoid diffing/patching DOM subtrees (e.g., onBeforeUpdateEl). In practice, you wouldn't want to rerender the entire DOM (only the the DOM subtrees that actually changed). Marko Widgets is a UI components building library that uses morphdom to only update the parts of the DOM that may have changed (if the input state associated with a DOM subtree didn't change then that subtree is not rendered and not diffed/patched).

Other things to consider:

  • morphdom is tiny (network overhead is often more important... especially in developing countries)
  • morphdom avoids the memory overhead of maintaining a parallel virtual DOM tree in memory
  • morphdom plays nice with vanilla DOM libraries and web components
  • The performance of morphdom varies by browser (Safari seems to have the fastest DOM operations)
  • morphdom will get faster as browsers optimize the DOM
  • morphdom can be used with any library that produces HTML or DOM nodes
  • Using morphdom for animation is not recommended (use hardware accelerated CSS transitions or an animation library instead)
  • I'm sure there is plenty of room to improve morphdom for specific use cases

Every benchmark should be taken with a grain of salt ("There are Lies, Damned Lies and Benchmarks"). At eBay we have lots of teams using morphdom (paired with Marko Widgets) heavily for both mobile and desktop web development and it has worked really well.

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

Successfully merging this pull request may close these issues.

4 participants