D3 with Backbone / D3 with Angular / D3 with Ember?

Question

I\'m working on a medium sized application that is going to include a lot of D3 charts / interactions in it. I\'m wondering if anyone has tried to use Backbone, Angular, or

Answer 1

My group has used both angular and backbone with d3, and we like both for different reasons.

Backbone

Backbone is a bit less opinionated about the way you construct your application, which is nice if you need to customize the way data is getting handled for performance. You generally integrate d3 with a backbone view.

One challenge of working with Backbone is memory management for complex views, but using marionette helps with that. Also Marionette's event aggregator (and specifically using request-response) is a good fit for centralized data sources for coordinated views if you want to use something like crossfilter or lunr.

Angular

Angular is more structured, and it is allows you to build up cool features very quickly. It has a steep learning curve, but I've found now that I'm understanding angular (having using it to develop an application for the past ~4 weeks), I've found that I can accomplish many of the same things I can in backbone without resorting to anything too hackish.

Like the request-response object in backbone marionette, using angular services allows you to build up complex views quickly. You'll need to avoid using angular's dirty checking on $scope data for complex data visualizations to keep your application from bogging down, so the code you write for working with your data in angular is going to end up looking a lot like the code you would write in backbone.

I had resisted angular's "magic" for a while, but I'm starting to get won over by the speed of development you can achieve because of all the built in directives, scope checking, and other goodies. Angular still allows you to poke around in its internals to speed up your code when that's required. This "digging" may take more time than in backbone (because the code base is more complex), but I've found that time lost in this phase is usually recouped by time saved avoiding common bugs like memory leaks in view code and writing boilerplate code like view rendering and data binding.

In summary

• Backbone is a good choice if you need extensive control and customization
• Angular is excellent if you really like data binding
• Ember is probably fine too, if for no other reason than Square uses (used?) it, and Mike Bostocks worked for Square.
• In any framework the "hard" data intensive parts of your app are probably going to look similar if you write them well (i.e. get the data transformations into services and put a clean simple interface around your view code)