

How to Structure and Render Views in Backbone - AlGal
http://blog.42floors.com/structure-render-views-backbone/

======
mrcwinn
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.

~~~
AdrianRossouw
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.

------
_greim_
This simple extension:

[https://github.com/greim/Backbone-
Subscriptions](https://github.com/greim/Backbone-Subscriptions)

...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.

------
BadassFractal
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.

~~~
AdrianRossouw
One one of my recent projects I found that using a state machine
([http://statejs.org](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.

------
AdrianRossouw
any post on this topic really needs to mention marionette.

~~~
thegoodlab
marionette should pretty much be prerequisite for using backbone IMO

~~~
AdrianRossouw
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.

