JavaScript MVC frameworks: A Comparison of Marionette and Chaplin(9elements.com)
9elements.com
JavaScript MVC frameworks: A Comparison of Marionette and Chaplin
http://9elements.com/io/index.php/comparison-of-marionette-and-chaplin/
5 comments
Hi, I’m Mathias, the author of the linked article.
Jeremy, I think we’re on the same page. Only the individual developers are able to decide about an appropriate app architecture. My goal is to help people make these informed decisions. I’m saying that devs should learn from others who have dealt with the same problems before – and found different solutions.
What you are calling malarkey is just my professional experience from 2+ years of developing Backbone apps that have 10K-20K LOC, as well as giving Backbone consulting to startups and mid-size companies.
I’ve seen the codebase of several “plain” Backbone apps. All of them faced specific, but also common problems and solved them by putting layers on top of Backbone. Some of these layers were well-engineered, some of these were horrible. The idea of Marionette and Chaplin is to put the best practices in modular code. Let’s face it, there are probably more Backbone apps than good JavaScript application architects.
Following the paths that Marionette and Chaplin have chosen “isn’t always wise” – there’s no doubt on that. It’s the philosophy of Marionette that you should pick those parts you find valuable for your app. And even in Chaplin you’re free to break all rules if you know what you’re doing. A lot of Chaplin users are doing this, which is fine.
> hiding and showing different parts of your app with simple CSS classes is usually less complex and faster (…)
If that suits your app, full ACK. There are a lot of apps where this makes more sense.
> That pre-fab "ListViews" are often nice for simple cases, but fall down when you want to do something truly custom and high-performance.
Marionette’s CompositeView and Chaplin’s CollectionView aren’t only for simple cases. Of course, an abstraction library can’t cover custom, high-performance lists. We’re not even trying. That’s what we’re telling our users: If you want high performance, you need to get rid of the convenience layer and operate on a lower level.
> That throwing away all of your models and views by default … is actually the opposite of the approach you normally want to take
Chaplin does not say that you should throw away everything. If you can reuse objects to speed up your app, you should do so.
Chaplin wants you to think about object persistence and object disposal. Chaplin provides means for both. In Chaplin, you can mark objects explicitly as reusable. That’s a safe approach to memory management AFAICS.
Jeremy, I think we’re on the same page. Only the individual developers are able to decide about an appropriate app architecture. My goal is to help people make these informed decisions. I’m saying that devs should learn from others who have dealt with the same problems before – and found different solutions.
What you are calling malarkey is just my professional experience from 2+ years of developing Backbone apps that have 10K-20K LOC, as well as giving Backbone consulting to startups and mid-size companies.
I’ve seen the codebase of several “plain” Backbone apps. All of them faced specific, but also common problems and solved them by putting layers on top of Backbone. Some of these layers were well-engineered, some of these were horrible. The idea of Marionette and Chaplin is to put the best practices in modular code. Let’s face it, there are probably more Backbone apps than good JavaScript application architects.
Following the paths that Marionette and Chaplin have chosen “isn’t always wise” – there’s no doubt on that. It’s the philosophy of Marionette that you should pick those parts you find valuable for your app. And even in Chaplin you’re free to break all rules if you know what you’re doing. A lot of Chaplin users are doing this, which is fine.
> hiding and showing different parts of your app with simple CSS classes is usually less complex and faster (…)
If that suits your app, full ACK. There are a lot of apps where this makes more sense.
> That pre-fab "ListViews" are often nice for simple cases, but fall down when you want to do something truly custom and high-performance.
Marionette’s CompositeView and Chaplin’s CollectionView aren’t only for simple cases. Of course, an abstraction library can’t cover custom, high-performance lists. We’re not even trying. That’s what we’re telling our users: If you want high performance, you need to get rid of the convenience layer and operate on a lower level.
> That throwing away all of your models and views by default … is actually the opposite of the approach you normally want to take
Chaplin does not say that you should throw away everything. If you can reuse objects to speed up your app, you should do so.
Chaplin wants you to think about object persistence and object disposal. Chaplin provides means for both. In Chaplin, you can mark objects explicitly as reusable. That’s a safe approach to memory management AFAICS.
I'm trying to keep things "bare bones" with Backbone for a huge refactoring I'm doing, and I'm happy so far, I like the quick learning curve, the "stay out of my way" the ability to gradually refactor the code instead of the rewrite that Angular or Ember will probably trigger. The annotated source is a great help, and although I struggled on deciding on namespace and structuring conventions, the freedom to chose my own was helpful.
Having that said, I'm starting to regret I didn't do the refactoring using AngularJS, and here are the main pain points - the following must need a plugin, and the plugins keep playing catch with the core releases (not all are 1.0 compatible):
- Manual binding
- Nested collections / models
- Bootstrapping without pushstate
* The pain in manual binding is not just for things like a checkbox, the pain starts for syncing things like a sortable list, syncing manually is just painful, it should auto sync with the model
* Nested models / collections are an issue mostly due to moving from relational to noSQL database, one can use plugins, or use the method you suggest in the FAQ (I use it, it's not that bad) but it's not built in.
* Bootrapping without pushState support - the assumption that models will be bootstrapped (e.g. the fetch change event trigger will trigger if you load the model via Ajax the first time) is an aching point if you can't have pushState (user refreshes a page / clicks a deep link, the hash path is not sent to the sever, wrong model is being bootstrapped) The solution someone suggested is to have a "once" on "sync" and only then start listening to a change, I think it's a hack, and I still can't find a solution to it.
Bottom line, Backbone is great, and will be great, but needs to have the core plugins (Modelbinder, Deep Model / Relational / Nested Models) become part of the core, it's not a luxury.
Backbone is smaller than Angular, but if you add all the plugins you usually will need, it can become even bigger...
Having that said, I'm starting to regret I didn't do the refactoring using AngularJS, and here are the main pain points - the following must need a plugin, and the plugins keep playing catch with the core releases (not all are 1.0 compatible):
- Manual binding
- Nested collections / models
- Bootstrapping without pushstate
* The pain in manual binding is not just for things like a checkbox, the pain starts for syncing things like a sortable list, syncing manually is just painful, it should auto sync with the model
* Nested models / collections are an issue mostly due to moving from relational to noSQL database, one can use plugins, or use the method you suggest in the FAQ (I use it, it's not that bad) but it's not built in.
* Bootrapping without pushState support - the assumption that models will be bootstrapped (e.g. the fetch change event trigger will trigger if you load the model via Ajax the first time) is an aching point if you can't have pushState (user refreshes a page / clicks a deep link, the hash path is not sent to the sever, wrong model is being bootstrapped) The solution someone suggested is to have a "once" on "sync" and only then start listening to a change, I think it's a hack, and I still can't find a solution to it.
Bottom line, Backbone is great, and will be great, but needs to have the core plugins (Modelbinder, Deep Model / Relational / Nested Models) become part of the core, it's not a luxury.
Backbone is smaller than Angular, but if you add all the plugins you usually will need, it can become even bigger...
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.
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.
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.
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.
I don't have all that much experience with backbone yet, so I can't compare the validity of their approaches vs "plain" backbone. However, my understanding is that both these meta-frameworks were extracted from some pretty big existing applications, and contain patterns that worked for them, so it's probably unfair to say that they're only good for quick "toy" apps. These meta-frameworks wouldn't exist in the first place if people didn't find them useful for larger applications.
Otherwise, if these frameworks really are taking the wrong approach to solving these problems, maybe it would be more useful to document better approaches to solving them?
Otherwise, if these frameworks really are taking the wrong approach to solving these problems, maybe it would be more useful to document better approaches to solving them?
[deleted]
"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.
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.
This isn't even close to how Ember's router works. The whole point of controllers in Ember is to preserve client state (including between routes).
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.
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.
Views are meant to be transient and just a step above the lifecycle of the html elements themselves.
Came here to say exactly that. USAToday is made with plain backbone.js and it's doing pretty well the last time I checked.
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.
"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.
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.
The article should've been called "Marionette Vs. Chaplin" for obvious reasons.
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
> 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
... 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.