[iamleppert]

Isn't this just queuing up the actual, real work on the event loop?

Of course its faster to call setImmediate a bunch of times to defer work, than it is to actually DO the work. It is useless to compare a synthetic benchmark for what is fundamentally a task that involves drawing something to the screen, without measuring the time it takes to finish all those tasks. The actual performance will, of course, be determined by how many DOM mutations are occurring, and the relative layout complexity of each. There will be a benefit for lots of really small, expensive mutations that could be batched together, but who designs their applications like that? Oh, wait...

At least, that's my understanding of looking at the source for a few minutes. Maybe I'm missing something, but I don't see any real algorithm at work here, just work that is shifted around to make a benchmark look good.

A better benchmark would be to use this in a real world, non-trivial use-case somehow and measure the framerate. But I can save you the effort: It's not going to win out over a well designed application that does direct DOM manipulation. Period.

[roucoulawan]

But is Icaro more on listening changes on javascript objects, in a general manner, better than just the DOM ones?

I think that this light lib could be actually a cool toy to use if you need for example to do some simple app state listened manipulations on the node backend side.

Otherwise, that is true, I would maybe still prefer to use frontend side some well-designed frameworks like redux-Rx or redux-react