

JavaScript MVC frameworks: A Comparison of Marionette and Chaplin - molily
http://9elements.com/io/index.php/comparison-of-marionette-and-chaplin/

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

~~~
ganarajpr
Sorry, you might be the author of Backbone, but this is one aspect that you
might have gotten wrong. If you had considered it, there would have been more
meat in Backbone.

Following your logic, we should all be writing code in assembler or even
machine code. Higher levels of abstractions are always good and not everyone (
> 95% of the apps ) needs to fine tune their app to the last processor cycle.

If we are writing an app for a Rocket launcher or some high critical app like
that then I would agree that the developer of that app shouldnt be using
higher level abstractions / library / frameworks. But these are webapps for
gods sake and the computers of today are perfectly capable of handling an
average web app and provide 60fps rendering ( unless the developer is
seriously stupid ) or in the worst case 30fps atleast (which is smooth enough
). The question is a tradeoff between how much performance you want and how
much speed in development you want.

I am sure that for the average developer out there, Marionette or Chaplin will
be faster than plain Backbone.

~~~
posabsolute
I disagree, it might be faster on the short run but not on the long run. small
swift mvc is better than standing on the giant shoulder of the other guy.

Seriously backbone is not hard to learn, fucking easy to extend, specially
removing the rendering boilerplates, thats like 30 seconds of extending the
view system.

You also do not address the main point, most examples are plain backbone, why
is that? probably because handling your own "marionnette" is easy.

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

------
pdog
Note to those not familiar: Marionette and Chaplin are frameworks built on top
of the Backbone.js library. It's interesting to see a comparison of frameworks
that doesn't mention Ember.js or AngularJS.

------
tkxxx7
The article should've been called "Marionette Vs. Chaplin" for obvious
reasons.

------
danso
This is a nicely detailed, nuanced overview. The conclusion contains the
thesis of the comparison:

> _Marionette is rather modular, you can pick the patterns you like. (In my
> opinion, you should pick most of them because they can improve your app.)_

> _Chaplin is more like a framework, it’s centralized and rather strict. The
> Chaplin authors think these guidelines offer convenience and boost
> productivity. Your mileage may vary, of course._

I've played around with Marionette and am now tempted to try out Chaplin,
precisely because of its rigidity...Backbone's advantage is how minimal and
flexible it is, but of course, that aesthetic and philosophy is what creates
the need for Chaplin in the first place. I wouldn't mind using it to build a
hobby app if, by doing so, I gained a better understanding of best (or at
least, very good) practices in structuring a Backbone app

