This document discusses large scale JavaScript applications and common patterns used to build them. It begins by introducing Addy Osmani and his work on JavaScript frameworks. It then covers the evolution of JavaScript apps from early uses to modern complex single page apps. Key points are made about the complexity of front-end development. The document dives into architectural patterns like namespaces, modules, facades, mediators, and observers to handle complexity. It provides examples of implementing these patterns with RequireJS and AMD for module loading. Finally, it proposes an overall application architecture bringing these concepts together and recommends further resources on the topic.

1. Large Scale JavaScript
applications

2. @alexbeletsky
http://beletsky.net
http://github.com/alexanderbeletsky

3. Big Credits to:
Addy Osmani
Addy Osmani is a rebel JavaScript blogger, speaker and a
UI Developer for AOL (yes, we're still around!). He is also a
member of the jQuery [Bug Triage/Docs/Front-end] teams
where he assists with bugs, documentation and developer
evangelism. His recent open-source projects include
TodoMVC, which helps developers compare JavaScript
MVC frameworks. For more on Addy’s work, check out his
official website AddyOsmani.com for tutorials and
magazines such as .net for his thoughts and commentaries
on the state of the web.

4. JavaScript apps
evolution

5. Early JavaScript application
● Mainly for web design
● Copy/Paste pattern commonly used
● Very poor browser support
● Lack of “community” knowledge base
● Low performace

6. Modern JavaScript application
● AJAX era started
● Adoption and respect by masses
● Huge improvement on standard and vendors
● Performance boosted
● New web assembly language
● Expertice & Best practices

7. Modern web app: GMail

8. Modern web app: Yandex Maps

9. Modern web app: Debitoor

10. “Modern web apps
tend to be more (or
equaly) complex
on front end
rather on back end”

11. In fact,
JavaScript language
is important...
Front-end development
could be complex...

12. What is Large scale app?
“In my view, large-scale JavaScript apps are non-
trivial applications requiring significant developer
effort to maintain, where most heavy lifting of data
manipulation and display falls to the browser.”
- Addy Osmani

13. Complexity is handled by
applying architectural
approach

14. Patterns &
Frameworks

15. Namespace
Module
Facade
Mediator
Observer

16. Namespace pattern
“Namespacing is a technique employed to avoid
collisions with other objects or variables in the global
namespace”
Goal: avoid names collision and provide facilities
to organize blocks of functionality into easily
managable groups

17. Namespace pattern implementation

18. Namespace
Module
Facade
Mediator
Observer

19. Module pattern
“The module pattern is a popular design that pattern that
encapsulates 'privacy', state and organization using
closures”
Goal: It provides a way of wrapping a mix of
public and private methods and variables,
protecting pieces from leaking into the global
scope and accidentally colliding with another
developer's interface

20. Module pattern implementation

21. Namespace
Module
Facade
Mediator
Observer

22. Facade pattern
“ The facade pattern provides a convenient higher-level
interface to a larger body of code, hiding its true
underlying complexity. Think of it as simplifying the API
being presented to other developers”
Goal: to hide implementation-specific details
about a body of functionality contained in
individual modules. The implementation of a
module can change without the clients really
even knowing about it.

23. Facade pattern implementation

24. Facade pattern implementation
Provides the open API for the rest of the
application

25. Namespace
Module
Facade
Mediator
Observer

26. Mediator pattern
“ The mediator is a behavioral design pattern that allows
us to expose a unified interface through which the
different parts of a system may communicate”
Goal: promotes loose coupling by ensuring that
instead of components referring to each other
explicitly, their interaction is handled through
this central point. This can help us decouple
systems and improve the potential for component
reusability.

27. Mediator pattern implementation

28. Facade pattern implementation
Subscribe for particular event / Publish
this event

29. Namespace
Module
Facade
Mediator
Observer

30. Observer pattern
“ The Observer is a design pattern which allows an object
(known as a subscriber) to watch another object (the
publisher), where we provide a means for the subscriber
and publisher form a listen and broadcast relationship”
Goal: the promotion of loose coupling. Rather
than single objects calling on the methods of
other objects directly, they instead subscribe to a
specific task or activity of another object and are
notified when it occurs.

31. Observer pattern implementation
https://gist.github.com/661855

32. Observer pattern implementation

33. RequireJS and AMD

34. RequireJS: file and module loader

35. RequreJS: Usage example

36. RequireJS: Main script

37. RequireJS uses
Asynchronous Module
Definition
to load modules

38. AMD: module example

39. Putting thing
together

40. Proposed Architecture
Module Facade Mediator
RequireJS AMD
● Loosely coupled
● Broken into independent modules
● Flexible (framework agnostic)

41. Demo application

42. backbone-aura

43. Further reading:
● Learning JavaScript Design Patterns
http://addyosmani.com/resources/essentialjsdesignpatterns/book/
● Patterns For Large-Scale JavaScript Application
Architecture
http://addyosmani.com/largescalejavascript
● Writing Modular JavaScript With AMD,
CommonJS & ES Harmony
http://addyosmani.com/writing-modular-js/
● Scalable JavaScript Application Architecture
http://www.youtube.com/watch?v=vXjVFPosQHw&feature=youtu.be

44. Thank you.
http://beletsky.net
@alexbeletsky