3 ms·
In OP's conclusions: "the DOM is slow, so use a framework that batches updates to it." It would be nice to see a comparison of React/Om with some less naive ap
by scelerat 13y ago
In OP's conclusions: "the DOM is slow, so use a framework that batches updates to it."
It would be nice to see a comparison of React/Om with some less naive approach to handling Backbone events.
In my own apps, for instance, I've dealt with rapid batch DOM updates simply by putting a short timeout on the event handler and canceling it if another draw-inducing event arrived in the timeframe (5ms, let's say). Doing that has led to similar order-of-magnitude speedups, and while not as sophisticated as using requestAnimationFrame, has been sufficient and maintainable.
- jbeja 13y agoDo you have a open example to this? I would like to know how is implemented.
- eddieplan9 13y agoHe just described the _.debounce function in underscore.js http://underscorejs.org/#debounce http://underscorejs.org/#debounce
- STRML 13y agoThat's something I've recently added to Backbone.LayoutManager[1], but it's still sitting in a PR while we figure out the 1.0 API. The PR is complete, however, so feel free to use my branch. It does offer very meaningful speedups, especially when data changes rapidly or causes a chain reaction. I have not benchmarked it in comparison to React/Om but it is very fast. The implementation is simple; when render() is called, the render is queued up. Every ~16ms (RAF or setTimeout), any pending renders are executed. If another render() is called within that time frame, the earlier is dropped. So long as you expect an async API and listen only to events/hooks ('beforeRender', 'afterRender'), it works pretty well. Backbone.LayoutManager supports it fully and it is configurable in case you rely on synchronous renders, which can be helpful in tests. 1. https://github.com/tbranyen/backbone.layoutmanager/pull/421 https://github.com/tbranyen/backbone.layoutmanager/pull/421