Recorded at:

Building Rich User Experiences without JavaScript Spaghetti

Sections

Architecture & Design,

Development

Topics

Code Quality ,

Javascript ,

Code PaLOUsa 2012 ,

Web Development ,

Quality ,

Dynamic Languages ,

Code PaLOUsa ,

Software Craftsmanship ,

Coding Standards ,

Agile ,

UX ,

Patterns

Share |

RelatedVendorContent

Cutting Edge Ruby, PHP, and Dynamic Languages for the Web @QConSF

Enterprise-class API Patterns for Cloud & Mobile

Identify Technical Debt Early and Often with Visual Studio 2012

Patterns for Software Configuration Management

The Agile Tester

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

Related Research

Latest Research

1. Back to top

   UI-level model instead?

   by Rick Mugridge

   Hi Jared,
   
   I agree that code can easily become tangled, because the wiring is done too close to the (upper-most) GUI layer. So it feels like lots of hacks with no coherence. I know of at least two approaches, busses and GUI-level models.
   
   It seems to me that your service bus works here because it's quite constrained in what it handles. I've seen such busses grow out of control as more is added, because they turn into a complex global with large numbers of dependencies. The complexity is in all the routing through the bus. And there will be lots of unrelated "interactions" going on, all blended together.
   
   I approach this issue by having an explicit model for the state of selection/showing of the GUI, and this mediates the interactions between the GUI pieces. It has anonymous (multi-) listeners registered to respond to changes of interest to them. I can then TDD that model. It's flexible for plugging in additional capability. This allows me to create a coherent model with a clear focus.
   
   I usually find that different people choose different solutions because of subtle differences in their goals. So I'd be interested to hear what aspects of your app meant that a bus is a better choice than a GUI-model approach.
   
   Cheers, Rick

   Reply

2. Back to top

   Re: UI-level model instead?

   by Russell Leggett

   I'm pretty much with you Rick, especially if you have a rich data-binding layer. In the application I work on (client side templates and ~100,000 lines of JS code, dozens of screens, hundreds of rest services) it's rare that I ever have a situation which would benefit from a global bus approach. I've thought about it, and there are a few instances that might benefit, but I have found it overwhelmingly useful to have a model/binding centric approach with a judicious sprinkling of custom events. Your example of two controls interacting can easily be solved by having them share a data model describing the state of the app. Modification to state is observed through data bindings and automatically updated.
   
   One of the core reasons why I find the model based approach to be advantageous is that it can be saved and reloaded in the same state, not to mention, if you are rendering everything in the client, you really need to have a model for it anyway, just so that you can supply the data for the template. With a little work, and a flexible UI framework, you can share a model with multiple views for example. One rendering makes the table, while another would render the selectable sidebar.
   
   - Russ

   Reply

3. Back to top

   Re: UI-level model instead?

   by Jared Faris

   Hi Rick and Russ,
   
   It depends on what I'm building. At the time I put together this talk I was building single pages of a more traditional multi-page app. A single bus worked out pretty well on the pages because for a) there wasn't a lot of unrelated messaging to complicate things and b) most of the elements on the page really cared about some identifier and then a few bits of information only they used. A message that identified the item could trigger a fresh pull of data from the server for what the control was interested in. Fresh data for a different related control wasn't always necessary. I've been able to build pretty nice applications really quickly this way.
   
   On more complex things (like huge SPAs) I'm more likely to do something similar to what you're describing. When I've used Backbone.js I've created models for everything inside of a router and then reused those models in views when appropriate. I still end up passing a few events to an event aggregator but there aren't a huge number of them and it doesn't get messy.
   
   One other benefits of the pattern I'm talking about is that it seems to click quickly for people who have done things like WPF or used the MVP pattern elsewhere. I've talked to a number of people who struggle with building organized JavaScript in general and have trouble wrapping their heads around shared model approaches. Having them start by building a single model for a single part of a page and then using messaging to connect things gets them moving towards elegant JS pretty quickly.
   
   I may have totally missed parts of your feedback so if so please let me know. I don't necessarily disagree with either of you :)
   
   -Jared

   Reply