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