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