I think there's some misunderstanding of performance in the browser here. This library might make smooth animations when its observer system is used (doing it in parallel to the main update flow is best), but only while complexity is kept low.
Looking at the code, all it does is queue each observer listeners using RAF, the moment the component tree takes longer than 16ms to render, or a single component does a bit more work than expected, you'll get dropped frames. To actually ensure 60FPS it would need a more sophisticated scheduling system that is able to time-slice the updates (== asynchronous rendering) and possibly interrupt updates.
Render 100 node in browser it is less then 16ms, if you need hard logic, you can use reactive for that. Library first of all created all child deep, after that appendChild to DOM in memory, when all child and root ready and after that will be append in place on page.
> if you need hard logic, you can use reactive for that
What do you mean by that? Any logic still has to execute in the same 16ms budget. In any case, it's pointless to discuss in a vacuum, I suggest you implement something like the JS Framework Benchmark [1] or DBMonster to see where it stands in fact, and then optimize from there.
Thank you for link, i 3rd week try found it. Yes of course optimisation always in progress. I tested render 500 nodes node(simple div) and every 10ms updating 50y from them, fps was 60.
Tongue in cheek, I'm going to hold you to that ;)