7.
Design Patterns Reusable solutions that can be applied to commonly occurring problems in software design and architecture.“We search for some kind of harmony between two intangibles: a form we have not yetdesigned and a context we cannot properly describe’- Christopher Alexander, the father of design patterns.

16.
Architecture How do you structure your application?• Architecture patterns describe concepts for the structure of an application• Certain patterns can be applied to both the client and server-side• Most client-side architecture patterns have roots in the server-side

17.
The pattern most commonly used on thefront-end these days is ‘MVC’.*It’s of course not the *only* option, just the most frequently implemented.

18.
The MVC Pattern Separates applications into three main concerns:Models Views Controllers

20.
MVC: Views Render models into a form suitable for user interaction• In most cases can be considered the UI• Typically render to a speci c user interface element• Many frameworks rely on templating for this• Multiple views can exist for single models

21.
MVC: Controllers Receive input and instruct models and views to respond accordingly• Sits between models and views• (May) perform business logic and data manipulation• It’s role in client-side MVC heavily varies• Some replace it with a router, others use it as a logic handler

22.
How Does This Work? Converting spaghetti code to use MVC isn’t all that hard.. What unique data is represented in my app? e.g a picture, a Models person What does the user need to be able to see and do? Views What (repeatable) output can I shift to JS templating?Spaghetti code Controllers (varies) If a router, what happens when a route is navigated to? e.g. /#admin

23.
How Does This Work? Converting spaghetti code to use MVC isn’t all that hard.. What unique data is represented in my app? e.g a picture, a Models person What does the user need to be able to see and do? Views What (repeatable) output can I shift to JS templating?Spaghetti code Controllers (varies) If a router, what happens when a route is navigated to? e.g. /#admin

24.
How Does This Work? Converting spaghetti code to use MVC isn’t all that hard.. What unique data is represented in my app? e.g a picture, a Models person What does the user need to be able to see and do? Views What (repeatable) output can I shift to JS templating?Spaghetti code Controllers (varies) If a router, what happens when a route is navigated to? e.g. /#admin

25.
On the client-side, I prefer to refer to thispattern as MVV (Model-View-Variation).All JavaScript ‘MVC’ frameworks seem tointerpret MVC differently.

33.
Modules Interchangeable single-parts of a larger system that can be easily re-used. In JS we use the module pattern.“Anything can be de ned as a reusable module”- Nicholas Zakas, author ‘Professional JavaScript For Web Developers’

38.
Sample usage Inside the module, youll notice we return an object. This gets automatically assigned to basketModule so that you can interact with it as follows://basketModule is an object with properties which can also be methodsbasketModule.addItem({item:bread,price:0.5});basketModule.addItem({item:butter,price:0.3}); console.log(basketModule.getItemCount());console.log(basketModule.getTotal()); //however, the following will not work:// (undefined as not inside the returned object)console.log(basketModule.basket);//(only exists within the module scope)console.log(basket);

43.
Better: AMD Take the concept of reusable JavaScript modules further with the Asynchronous Module De nition.Mechanism for de ning Stepping-stone to the Non-blocking, parallelasynchronously loadable module system proposed loading and well de ned.modules & dependencies for ES Harmony

49.
Want to see a Backbone.js + RequireJS +AMD + jQuery demo? Hang on until the end.*or look at:https://github.com/addyosmani/backbone-aura

50.
Alternative: CommonJS Another easy to use module system with wide adoption server-side CommonJS Format widely accepted Competing standard. Tries Working group on a number of server-side to solve a few things AMDdesigning, prototyping, platforms (Node) doesn’t.standardizing JS APIs

51.
CommonJS Modules They basically contain two parts: an exports object that contains the objects a module wishes to expose and a require function that modules can use to import the exports of other modules/* here we achieve compatibility with AMD and CommonJSusing some boilerplate around the CommonJS module format*/(function(define){ define(function(require,exports){ /*module contents*/ var dep1 = require("foo"); var dep2 = require("bar"); exports.hello = function(){...}; exports.world = function(){...}; });})(typeof define=="function"? define:function(factory){factory(require,exports)});

56.
Facade Pattern Convenient, high-level interfaces to larger bodies of code that hide underlying complexity“When you put up a facade, youre usually creating an outward appearance which conceals adifferent reality. Think of it as simplifying the API presented to other developers”- Essential JavaScript Design Patterns

60.
A Facade A structural pattern found in many JavaScript libraries and frameworks (eg. jQuery). Hides the inner- Simpli es usage This lets you be more workings of a library.through a limited, creative behind the Allows implementationmore readable API scenes. to be less important.

61.
Facade Pattern How does it differ from the module pattern?• Differs from the module pattern as the exposed API can greatly differ from the public/private methods de ned• Has many uses including application security as we’ll see a little later in the talk

62.
Mediator Pattern Encapsulates how disparate modules interact with each other by acting as an intermediary“Mediators are used when the communication between modules may be complex, butis still well de ned”- Essential JavaScript Design Patterns

63.
Air Traf c Control I always nd this mediator analogy helps when discussing this pattern: The tower handles All communication done Centralised controllerwhat planes can take from planes to tower, is key to this success. off and land not plane to plane Similar to mediator.

64.
A Mediator Promotes loose coupling. Helps solve module inter-dependency issues. Allow modules to Noti cations can be Typically easier to add or broadcast or listen for handled by any number of remove features to loosely noti cations without modules at once. coupled systems like this.worrying about the system.

68.
Scalable ApplicationArchitecture Strategies for decoupling and future-proo ng the structure of your application. Let’s build empires.Thanks to Nicholas Zakas, Rebecca Murphey, John Hann, Paul Irish, Peter Michaux and JustinMeyer for their previous work in this area.

69.
Challenge De ne what it means for a JavaScript application to be ‘large’.• It’s a very tricky question to get right• Even experienced JavaScript developers have trouble accurately de ning this

70.
Some AnswersI asked some intermediate developers what their thoughts on this were. Umm..JavaScript apps with over 100,000 lines of code?

71.
Some AnswersI asked some intermediate developers what their thoughts on this were. Obviously, apps with over 1MB of JavaScript code written in-house!

76.
Current ArchitectureIf working on a signi cantly large JavaScript app,remember to dedicate suf cient time to planning theunderlying architecture that makes the most sense.It’s often more complex than we initially think.

78.
Possible Problems The last slide contains some great architectural components, but used non- optimally they can come with a few problems: Can single modules Can single modulesHow much of this is exist on their own be testedinstantly re-usable? independently? independently?

79.
Possible Problems Some further concerns: How much do Is your application If speci c parts of modules depend on tightly coupled? your app fail, can itothers in the system? still function?

80.
Think Long-Term What future concerns haven’t been factored in to this architecture?• You may decide to switch from using jQuery to Dojo or YUI for reasons of performance, security or design• Libraries are not easily interchangeable and have high switching costs if tightly coupled to your app

81.
Think long term - what future concernshaven’t been factored in yet?

82.
Ask Yourself This is important.If you reviewed your architecture right now, could a decision to switch libraries be made without rewriting your entire application?

83.
“The secret to building large apps is never build largeapps. Break your applications into small pieces. Then,assemble those testable, bite-sized pieces into your bigapplication”- Justin Meyer

84.
“The more tied components are to each other, the lessreusable they will be, and the more dif cult it becomes tomake changes to one without accidentally affectinganother”- Rebecca Murphey

85.
“The key is to acknowledge from the start that you have noidea how this will grow.When you accept that you dont know everything, youbegin to design the system defensively.”- Nicholas Zakas

86.
Solution: Combine Patterns Fixing our architecture with what we’ve learned to date.“The only difference between a problem and a solution is that people understand thesolution.’- Charles F. Kettering

88.
Brainstorm. What do we want? Functionality broken Framework or libraryLoosely coupled down into smaller agnostic. Flexibility to architecture independent modules change in future.

89.
Some More Ideas. How might we achieve this? An intermediate layerSingle modules speak interprets requests. Prevent apps from falling to the app when Modules don’t access over due to errors withsomething interesting the core or libraries speci c modules. happens directly.

90.
The Facade The Facade pattern will play the role of:• An abstraction of the application core that sits in the middle between it and modules• Ensures a consistent interface to our modules is available at all times• Should be the only thing modules are aware of - they shouldn’t know about other components

91.
The Facade How else can it help?• Components communicate via the facade so it needs to be dependable• It acts as a security guard, determining which parts of the application a module can access• Components only call their own methods or methods from a sandbox, but nothing they don’t have permission to

92.
The FacadeThis is how modules might normally communicate with the mediator.

93.
The FacadeThis is where the Facade ts in. The intermediate security layer that pipes noti cations back to the mediator for processing.

94.
The FacadeAn abstraction of the core, it listens out for interestingevents and says ‘Great. What happened? Give me thedetails’.

95.
The FacadeIt also acts as a permissions manager. Modules onlycommunicate through this and are only able to do whatthey’ve been permitted to.

96.
A Quick Note:• Nicholas Zakas refers to the facade as a sandbox controller• Agrees it could equally be considered the adapter, proxy or facade pattern• I prefer ‘facade’ as it matches the purpose most closely

97.
The Application Core The Mediator Pattern• It’s job is to manage the module lifecycle• When is it safe for a module to start?• When should it stop?• Modules should execute automatically when started

98.
The Application Core The Mediator Pattern• It’s not the core’s job to decide whether this should be when the DOM is ready.• The core should enable adding or removing modules without breaking anything.• It should ideally also handle detecting and managing errors in the system.

99.
The Application Core The core acts as a Pub/Sub manager using the mediator pattern

101.
Modules Tying in modules into the architecture• Modules want to inform the application when something interesting happens. e.g. a new message has arrived• Correctly publishing events of interest should be their primary concern

102.
Modules Tying in modules into the architecture• Modules should ideally not be concerned about: • what objects or modules are being noti ed • where these objects are based (client? server?) • how many objects subscribe to noti cations

104.
Modules Tying in modules into the architecture• They also shouldn’t be concerned with what happens if other modules in the system fail to work• Leave this up to the mediator

105.
ModulesIf a single module fails, the facade and mediator should stop and restart it.

106.
ModulesUnique blocks of functionality for your application. Theyinform the application when something interestinghappens. Don’t talk to each other directly, only concernedwith publishing events of interest.

108.
Aura: A PreviewEnough talk! Let’s take a look at some real code.Aura is a framework I’m building at AOL that provides a boilerplate for one way to approachimplementing this architecture. It will be released for open-source consumption once stable.

109.
Aura: Core The Mediator / Application Core• Swappable Mediator with a light wrapper around a speci c JavaScript library• Ability to start and stop modules• By default it comes with wrappers for both Dojo and jQuery, with core syntax that resembles the latter

110.
Aura: Core How does this work?• Accessing this wrapper, the facade doesn’t care what framework has been slotted in. It works with the abstraction• Behind the scenes, arguments are mapped to the relevant jQuery or dojo methods and signatures for achieving speci c behaviour

117.
What We LearnedLet’s review what we looked at today.‘Anyone who stops learning is old, whether at twenty or eighty. Anyone who keepslearning stays young. The greatest thing in life is to keep your mind young’- Henry Ford

118.
We looked at design patterns, jQuery &MVC, JavaScript patterns and how to nally build a large, scalable app.

119.
We looked at design patterns, jQuery &MVC, JavaScript patterns and how to nally build a large, scalable app.

120.
We looked at design patterns, jQuery &MVC, JavaScript patterns and how to nally build a large, scalable app.

121.
We looked at design patterns, jQuery &MVC, JavaScript patterns and how to nally build a large, scalable app.

123.
Summary This can be very useful as:• Modules are no longer dependent on anyone• They can be managed so that the application doesn’t (or shouldn’t) fall over.• You can theoretically pick up any module, drop it in a page and start using it in another project