> 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 [...]
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.
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.
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...
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.
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.
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?
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.
"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.
> 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