I've spent a long time with Backbone and it's still holding up well. Despite interesting projects like Meteor, or big frameworks like Ember, I continue to prefer Backbone to build rich — ambitious — web applications. Having a lean and simple event system is the magic behind Backbone as a library. It gives the developer flexibility in their application design. The weakness of Backbone is really a weakness of the developer using it: you can fall prey to poor design that's not manageable as scale grows.
One of the most frustrating areas of Backbone, as this post talks about, is view management. Rendering and subview management can be thorny issues. Some people look to help from things like Marionette, or ditch Backbone altogether for frameworks that impose convention and take render management away from the developer.
The past several weeks I've been really impressed with React. It is a fantastic, light-weight library for building reusable components and it plays very nicely with Backbone. You can mix together Backbone.Model, .Collection, .Events, but then ditch Backbone.View in favor of React components. It's incredibly fast, thanks to its virtual DOM and diff implementation, and gives you flexibility without needing to worry about render management. Everytime I've refactored a Backbone View into a React component, I think, "Wow, that's it?"
In terms of design patterns, since React components only have parent-child communications, Backbone's existing Events are still a great way to manage communication and convey state between components.
I really encourage everyone to give React a look. It's great.
I really like how marionette's event aggregators work for passing messages around on a higher level. I use marionette on the server for almost entirely that, and it's module system.
I realized recently while evaluation angular what it is I really like about backbone, and why I consider it a 'foundational' technology.
It's constrained scope and development history means I'm not actively expecting it to get more complex over time. The releases feel like they are more just 'tightening up' the formula.
...eliminates much of the need to clean up the kinds of event handlers that prevent views from being GC'd. Essentially, it contrives things such that the references preventing views from being GC'd consist in the DOM itself, so that when a node drops out of the DOM, views attached to it are automatically free to be GC'd. Serves our purposes rather well.
The current best minimalist practice is to use LayoutManager have your router be the super-orchestrator that makes sure all the models are loaded (use the caching plugin, very convenient), and instantiates the necessary nested views based on the route. Now that react.js is getting popular, it also might be worth looking into swapping LayoutManager out for it.
One one of my recent projects I found that using a state machine (http://statejs.org in this case) made the whole router malarky much easier to deal with.
It fires methods on transition etc, so you can make it load something when you go to this page, make it change this dialog when it goes to that.
The router was just something that changed the url when the application state changed.
While I am probably going to use it all the time, I think it's a better development model to have it evolve independently and having the core of backbone stay really simple.
One of the most frustrating areas of Backbone, as this post talks about, is view management. Rendering and subview management can be thorny issues. Some people look to help from things like Marionette, or ditch Backbone altogether for frameworks that impose convention and take render management away from the developer.
The past several weeks I've been really impressed with React. It is a fantastic, light-weight library for building reusable components and it plays very nicely with Backbone. You can mix together Backbone.Model, .Collection, .Events, but then ditch Backbone.View in favor of React components. It's incredibly fast, thanks to its virtual DOM and diff implementation, and gives you flexibility without needing to worry about render management. Everytime I've refactored a Backbone View into a React component, I think, "Wow, that's it?"
In terms of design patterns, since React components only have parent-child communications, Backbone's existing Events are still a great way to manage communication and convey state between components.
I really encourage everyone to give React a look. It's great.