JavaScript MVC frameworks: A Comparison of Marionette and Chaplin

I wish more people would be this open:

"As one of the main authors of Chaplin, I may be biased. But I do see weaknesses and room for improvement."

instead of the bashing that we see in many comparisons.

Everyone's entitled to their opinion ...

    > When using Backbone, you need to set up a scalable architecture 
    > yourself. Do not write applications in plain Backbone and make 
    > the same mistakes others did, but put yourself on the shoulders 
    > of giants. Have a deeper look at Marionette, Thorax, Aura, 
    > Chaplin and other architectures [...]

... but here's mine. This advice is pure malarkey. If you look at the really impressive, sophisticated, polished JS/MVC apps (http://backbonejs.org/#examples), you'll find that they're pretty much all using "plain" Backbone, without any of the meta-frameworks. If you know what you're doing, you'll be fine.

That said, if you're just getting started -- perhaps are hoping to make a quick toy app, and the freedom of "plain" Backbone feels a little overwhelming, the meta-frameworks are a great way to get your toes wet while being guided down a particular path. Once you're comfortable, and begin to realize (to pick on specific examples from the article):

* That manual management of event removal is usually more complex than architecting your application so that logical modules can be garbage collected naturally...

* That having a top-level "Controller" God object isn't always wise...

* That pre-fab "ListViews" are often nice for simple cases, but fall down when you want to do something truly custom and high-performance. (The simple case just being one line of code to implement yourself, anyway).

* That not having all of your URLs available all of the time is an anti-pattern...

* That hiding and showing different parts of your app with simple CSS classes is usually less complex and faster than building up and then having to tear down large view hierarchies.

* That throwing away all of your models and views by default when a different route matches is actually the opposite of the approach you normally want to take -- at least if you're hoping to achieve a smooth app-like look and feel...

... you'll begin to understand that you are the person best equipped to design the data + UI architecture that best suits your app.

"That throwing away all of your models and views by default when a different route matches is actually the opposite of the approach you normally want to take -- at least if you're hoping to achieve a smooth app-like look and feel..."

This is actually a really important point. This is exactly how Ember's router works, as far as I can see from the documentation - when you transition, you lose all prior state. It's essentially trying to emulate traditional routing, which defeats the point.

Apologies, this is what I get for not drinking coffee before commenting. You're completely right about keeping state when it comes to models.

What I don't see - and again, I have not dived very deeply into the router; I'm going off the documentation here - is how to keep views during the transition. In my app, the router has to re-render all views when changing between routes. This isn't a huge deal, as it's a very lightweight application. Still, Backbone offers much more flexibility when it comes to views.