[bmelton]

That's funny, as someone who's got a ton of bloated jQuery that we've mostly migrated to Backbone, I would have argued exactly the opposite.

Our front-end guy, who is a jQuery wizard but new to Backbone, originally looked at the conversions I'd done and was quick to remark at how clean it all was.

Is there magic? Sure, but in Backbone, not that much of it. There's decidedly more in Ember, but they're both open projects so you're welcome to go scour through the magic and figure it out for yourself.

I would feel remiss if I didn't also point out that code you write in Backbone is just as much your code as code you wrote in jQuery. As for magic quotient, I would also suggest that jQuery is more magical than Backbone, on the whole. If you think otherwise, that probably just speaks to a lack of familiarity with one compared to the other.

[Jemaclus]

Serious question. I haven't figured out the need for MVC in JS. I'm primarily a PHP programmer, and I use a custom MVC on the back-end. I don't see the point in having two MVC frameworks (one in front, one in back). At the end of the day, the front-end has to talk to the server to get data, doesn't it? What's the difference?

[bmelton]

You may not, necessarily, but Javascript Frameworks 1) aren't necessarily exactly MVC anyway and 2) if you're using the MVC in both frameworks, that's sort of the wrong way to do it.

Using Django as the example (which has its own stack behind it) and Backbone as the front-end, the only part of Django I really end up using, from an end-user's perspective, is the ORM and JSON serializers.

The way that backbone works is that your 'models' don't read to or write using the database, they read and write using APIs that you define with your normal framework. So, where in Django, you might execute a .save() on a model to commit it to the database, that same .save() operation in backbone will execute a PUT or PATCH request to your API endpoint to which its bound.