I honestly don't feel like any of the "large scale (JS|Backbone) applications" posts really addresses the difficulties you run into when scaling JS applications.
Most of these things are common sense (eg. "use namespaces", "make use of consistent naming conventions" etc.) and should hold for any kind of application development.<p>For me, one of the main problems when scaling the Backbone app I work with is decoupling View interactions. Now the usual recommendation you receive is using an event bus. In the link @analog just posted [1], Addy Osmani talks about using the Mediator pattern to achieve the decoupling, which certainly does help, but imho his example does not fully reflect the purpose of the Mediator pattern. His Mediator is barely more than just an event bus.<p>A Mediator can make use of an event bus, but an event bus is not automatically a mediator.
It still forces the views to know about events triggered from other views and react to them. This still causes coupling, and even worse, it keeps the coupling in the views. The mediator should exist to take care of that coupling and pull it out of the views.<p>Let's take for example a checkout page. The checkout page has a view containing a form for address data. It also has a view that lets you pick the payment provider, a view that allows you to enter a coupon and a view that shows the order total.<p>Here are some of the required view-to-view interactions:<p>* If the user email changed, revalidate the coupon to make sure the "new users only" constraint applies and show the status<p>* If the payment type is changed to Paypal, add an additional charge to the order total and display it.<p>* If a coupon is entered, update the order total<p>This means that in many cases, views need to know exactly how the public event interfaces of the other views look, even if they communicate by an event bus and not by direct references and method calls. To make the application maintainable, we need to get rid of the knowledge about the other views' events as well.<p>This is where the Mediator comes into play. We make the mediator aware of the different event interfaces of the Views and have it decide which events to retrigger or which methods to call in what View. Instead of having the views subscribe to the other Views' events, the Mediator wires them up and encapsulates the View interactions.
The Mediator now knows that the `change:email` event from the AddressForm triggers the `validateCoupon` method on the CouponView or the `validate:coupon` event to which the CouponView listens. The CouponView no longer needs to know about the existence of the `change:email` event.<p>Now the Views only need to specify their public (event) interfaces and the Mediator knows about how the different Views interact. This is a lot more scalable than the naive event bus approach.<p>I really wish there were more articles about scaling really big JS applications. In the end they will probably heavily borrow from GoF's Design Patterns book, but it always helps to see the patterns in action. I appreciate the author's effort, but I always feel disappointed when I read "Large Scale (Backbone|JS) Applications" and don't find advice to solve and real problems what come up with scaling "Large Scale (Backbone|JS) Applications".<p>[1] <a href="http://addyosmani.com/largescalejavascript/" rel="nofollow">http://addyosmani.com/largescalejavascript/</a>
Ben -- since you're around, and it seems to be "struggle with getting started with X.js week" around these parts ... I figure I should ask you about this:<p><pre><code> > which is what causes problems for a lot of people
> when getting to grips with it (myself included).
</code></pre>
What exactly did you have a hard time coming to grips with?
I recommend anyone getting into building web apps (regardless of framework) to read Mixu's "Single page apps in depth" <a href="http://singlepageappbook.com/single-page.html" rel="nofollow">http://singlepageappbook.com/single-page.html</a><p>It's a short read, it's opinionated and will make you think, especially if you're a novice / intermediate programmer. In particular, the "Writing maintainable code" chapter.<p>Focusing on things like namespacing is not necessarily a bad thing, but it doesn't address the real goal - writing modular, testable, maintainable code. If your components know where other components are in the namespace and depend on them internally, the namespace hierarchy does nothing to help your design.<p>The main difficulty in designing complex web applications is managing dependencies between objects, just like any large object-oriented piece of software (assuming that is the paradigm you choose).
a bit of a side track here, I've been seen a lot of blogs with this same layout, is it a blogging platform or just people copying around?<p>If it is a blogging platform, which one is it?
The big piece missing from this is RequireJs as the author mentions. We should all know it's good practice not to use global variables so that should be reason enough to use it in itself.<p>As an example an app we built had a conflict between a jQuery plugin that the frontend devs had included, and a library that we had added with require. Having the conflict only show up in one place rather than the whole app certainly made it quicker to diagnose.<p>Addy Osmani's tutorials should be required reading if you're just starting out. [1] [2]<p>The only downside that we saw was that you will have to provide AMD versions of each library you use if you want to use jQuery from a CDN.<p>As well as being good practice it just feels really nice to have everything you're using declared at the top of the file you're in. The sugared require syntax helps with this. [3]<p>[1] <a href="https://github.com/addyosmani/backbone-fundamentals" rel="nofollow">https://github.com/addyosmani/backbone-fundamentals</a><p>[2] <a href="http://addyosmani.com/largescalejavascript" rel="nofollow">http://addyosmani.com/largescalejavascript</a><p>[3] <a href="http://requirejs.org/docs/whyamd.html#sugar" rel="nofollow">http://requirejs.org/docs/whyamd.html#sugar</a>