Virtual-dom – A Virtual DOM and diffing algorithm

Hi All,

I dont know if anyone have seen the virtual-dom package ( ) before but it looks promising and might be good addition for blaze. Its receiving some positive feedback on hackernews -

Havnt tried it out yet but its looks very light-weight (1586 lines (1270 sloc) 43.199 kb not minified ) and snappy ( ) Run the benchmarks yourself at

Anyone used it before?



This looks great. Blaze templates have been really close to being actual web-components for awhile now (even if people didn’t realize it), and this is very much one of the missing pieces. Going to add this to the Blaze 2 hackpad for consideration.



One more thing - Also have a look at requestAnimationFrame ( ) . The elm framework above use that method to update the DOM diff to the DOM. This way there can be lost of DOM updates per second and your browser will not slow down (because of rendering) because it just adds a new animation frame and the browser does not have to render every one. rAF is not just for canvas but also for DOM insertions. I have done a quick search through meteor and it does not look like its using rAF at the moment. PS: I dont know much about this but it sounds like something to investigate as well.

Drag the tiger with your mouse on the following canvas examples:
Canvas example without rAF:
Canvas example with rAF:

See whole discussion here about that.

“It provides a native API for running any type of animation in the browser, be it using DOM elements, CSS, canvas, WebGL or anything else.”


We have been using to run everything w/ rAF. It has boosted our mobile apps performance significantly.

1 Like

Virtual DOM is awesome. I just checked out this library called “Magic Move” for React and its pretty simple – it uses a virtual DOM to see where things are before and after a change and animates their motion. This is MUCH easier than animating with _uihooks.

1 Like

You say that Blaze is close to web-components. Is there any documentation on how building components with Blaze ? I’ve tryed Template.subscribe / autorun … but i didn’t see anything about data storage and routing.

Well, data-storage is handled by minimongo or session variables, and routing can be done with iron:router as a dependency. :smile:

There’s a proposal in the Blaze 2 hackpad to rename ‘template instances’ to ‘components’. If that happens, we might see the entire API renamed from Template to Component! It’s a big picture thing. Like, the templates are the components. Almost.

1 Like

The problem with Session is that they are global to the app. Maybe using ReactiveVar to define the state of the Template would be more “clean”. I have to think about it.
Template or Component, naming will mainly help to give a good looking to devlopers of other framework like Angular/Ember that are really negative with Meteor.