backbone.layoutmanager

That'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

I'm not great at reading ClojureScript - but I'd really like to port some of the optimizations from Om, such as the rendering on requestAnimationFrame and usage of shouldComponentUpdate to Backbone.LayoutManager[1]. Swannodette, if you're around, do you have a minute to give a more in-depth explanation of how that works? 1. https://github.com/tbranyen/backbone.layoutmanager/wiki

Looking into it, it seems like most of your issues stem from the fact that you depended on View._configure being called during initialization. You overwrite it here: https://github.com/tbranyen/backbone.layoutmanager/blob/mast... but this was completely removed with the update: https://github.com/jashkenas/backbone/compare/1.0.0...1.1.0#... In backbone's defense, that wasn't part of its public API, but it does make updating challenging. I'll give it a try and see if I can be of some help.

For those who have not yet tried it, I would highly recommend TIm Branyen's Backbone.LayoutManager [1]. It solves items 1 and 2 very well. [1] https://github.com/tbranyen/backbone.layoutmanager

Yep. 'Leaving things to chance' is a good way to put it. Thanks, I'm aware of Marionette and have also used Backbone.LayoutManager [1] before which solves some of the same issues, though I am wary of the cobbled-together stack I might end-up with if I pick Backbone + Marionette + Some-Better-Router + ... That's certainly why Ember appeals, especially now they're beginning to nail the docs and there are great resources emerging like the recent Peepcode episode [2], which I'm going to have a watch a few more times through. Very interesting work with Sails, as someone who's written (much more basic) REST scaffolding scripts before I'm especially intrigued by that angle. I'll be digging into it for sure. [1] https://github.com/tbranyen/backbone.layoutmanager [2] https://peepcode.com/products/emberjs

Awesome work man, saw this last night and definitely want to get it hooked up with LayoutManager https://github.com/tbranyen/backbone.layoutmanager

I would say it's because you guys are doing it wrong. Backbone is just a very bare-bones backbone for your app. As you say, views don't provide anything. In fact backbone barely helps you with organizing your code at all. It's great for making a todos app but terrible for anything stretching across multiple pages, and with more than 10 views on a page. Let's be serious here. DON'T USE BACKBONE TO START A NEW APP!!! DON'T USE BACKBONE TO START A NEW APP!!! DON'T USE BACKBONE TO START A NEW APP!!! Use one of the higher level frameworks built around backbone. The most flexible / clean, decoupled framework (my preference) is: https://github.com/derickbailey/backbone.marionette If you like coffeescript: https://github.com/chaplinjs/chaplin If you want *only good views/layout: https://github.com/tbranyen/backbone.layoutmanager If you want model

https://github.com/tbranyen/backbone.layoutmanager Plugin I wrote for managing layout/views in Backbone. Provides a ton of features and flexibility. Before 0.5.0 it wasn't very stable for lists/collections. I'd highly recommend giving it a shot, because it makes writing Backbone applications significantly easier.