Summary & Notes

Update: A more detailed version of these slides along with code samples and further notes can be found on the resource page for my 'Scalable JavaScript Design Patterns' talk from Web Directions (South).

In this high-level talk, I focus on introducing developers to some of the concepts in my article on Large-Scale JavaScript Architecture. Specifically:

  • Design pattern fundamentals
  • Three important JavaScript design patterns
  • Building applications that scale (and are 'future-proofed')

The takeaway of the talk is that although building applications which scale requires careful planning and thought to get right, there are many interesting ideas you can apply to your architecture to cater for growth in the future.

Think about decoupling your application architecture so that the modules in your system don't need to directly talk to each other - this means that they can instead focus on publishing and subscribing to events of interest.

Consider supporting framework agnosticity. I talk about how you can create swappable application cores that offer a testable, reliable abstraction around frameworks and toolkits like Dojo and jQuery. This means that you're able to easily write JavaScript modules which don't need to directly touch a framework - they instead only speak to a middle-layer (through the facade pattern) which does all of the grunt work behind the scenes.

If specific modules in your architecture stop functioning or crash, is the rest of the application able to continue working?. In the architecture presented, we rely on an application core to both handle error management for modules but also control when they start, stop and need to be restarted.

Consider application security. Do modules in your architecture need to be able to access everything?. In most systems they probably don't need to. We can use patterns like the facade and mediator to help achieve a decoupled, safe architecture without a considerable amount of effort.

Is it possible for modules in your architecture to be independent entities that are self-contained?. Whilst not always possible, when it is, you gain the ability to write components which can be instantly dropped into other projects are reused with no additional effort required.

Finally, I present a preview of a framework I'm currently building at AOL called 'Aura' which provides you a boilerplate for building applications which use a lot of these concepts. You can of course build your own from scratch (and in a lot of cases it might make sense to), but I'm hopeful that once the framework gets released it'll help encourage a few more developers to consider developing applications this way.

Note: I briefly talked about AMD, CommonJS and Harmony modules at my Fronteers talk. For anyone wishing to learn more about writing modules using any of these formats, you may be interested in my post on Smashing Magazine about these topics.


Can you summarize this talk in 140 characters?

In the event of you being short for time, here's the tweet-sized summary of this presentation:

Future-proof your app:build highly decoupled architectures supporting easily swappable libraries/frameworks without the need to rewrite code