4 ms·

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

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. 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. 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. 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. Here are some of the required view-to-view interactions: * If the user email changed, revalidate the coupon to make sure the "new users only" constraint applies and show the status * If the payment type is changed to Paypal, add an additional charge to the order total and display it. * If a coupon is entered, update the order total 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. 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. 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. 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". [1] http://addyosmani.com/largescalejavascript/ http://addyosmani.com/largescalejavascript/

camus 14y ago
the problem is a large JS application is no different from a large desktop application. You cant code your way out of it without States , Proxies , Commands , Mediators , etc ... wether they are blundled with the framework one uses or not. Or one writes "throw away" code , which is what most people do anyway.
ef4 14y ago
The example you give is the kind of thing that Ember is really good at. You would implement all those interrelationships with computed properties. Each computed property updates automatically if its dependencies change, and each view redraws automatically when the corresponding properties change. All that work of defining events and propagating them through the mediator is stuff that Ember does for you automatically, once you've declared what depends on what. I'm one of the early adopters who built a rather big application in pre-1.0 Ember. It definitely pays off as the application grows larger.

camus 14y ago

the problem is a large JS application is no different from a large desktop application. You cant code your way out of it without States , Proxies , Commands , Mediators , etc ... wether they are blundled with the framework one uses or not. Or one writes "throw away" code , which is what most people do anyway.

ef4 14y ago

The example you give is the kind of thing that Ember is really good at. You would implement all those interrelationships with computed properties. Each computed property updates automatically if its dependencies change, and each view redraws automatically when the corresponding properties change. All that work of defining events and propagating them through the mediator is stuff that Ember does for you automatically, once you've declared what depends on what. I'm one of the early adopters who built a rather big application in pre-1.0 Ember. It definitely pays off as the application grows larger.