4 ms·
It depends on the use case. For applications that experience a high frequency updates near the top of the tree, a naive solution would typically block user inpu
by anonytrary 7y ago
It depends on the use case. For applications that experience a high frequency updates near the top of the tree, a naive solution would typically block user input.
Mithril's solution is very simple but using a setInterval(render, 16.6667) has its drawbacks that can lead to jankiness in the UX. React 16 from what I understand is almost a complete rewrite of React and does some smart stuff with animation frames to ensure an optimal UX.
- lhorie 7y agoMithril does use requestAnimationFrame unless you're in some version of IE. But Mithril rendering was never intended to run as the inner loop of an animation. Lifecycle hooks and CSS animations are preferable instead. React Fiber basically breaks down large animation payloads so each "chunk" can fit within one frame budget, but at the cost of a lot of untreeshakeable internal and peripheral complexity in React core.
- anonytrary 7y agoAgreed; all of complex scheduling solutions using RIC/RAF and priority queueing are probably not needed for 95% of webapps. The primary need is good state management and a good side-effect framework (e.g. hooks, lifecycle methods). Do you intend for Mithril to support this sort of "incremental" priority work handling?