Slide 1

Slide 1 text

Large Scale JavaScript applications

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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.

Slide 4

Slide 4 text

JavaScript apps evolution

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Modern web app: GMail

Slide 8

Slide 8 text

Modern web app: Yandex Maps

Slide 9

Slide 9 text

Modern web app: Debitoor

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Complexity is handled by applying architectural approach

Slide 14

Slide 14 text

Patterns & Frameworks

Slide 15

Slide 15 text

Namespace Module Facade Mediator Observer

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Namespace pattern implementation

Slide 18

Slide 18 text

Namespace Module Facade Mediator Observer

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Module pattern implementation

Slide 21

Slide 21 text

Namespace Module Facade Mediator Observer

Slide 22

Slide 22 text

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.

Slide 23

Slide 23 text

Facade pattern implementation

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Namespace Module Facade Mediator Observer

Slide 26

Slide 26 text

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.

Slide 27

Slide 27 text

Mediator pattern implementation

Slide 28

Slide 28 text

Facade pattern implementation Subscribe for particular event / Publish this event

Slide 29

Slide 29 text

Namespace Module Facade Mediator Observer

Slide 30

Slide 30 text

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.

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Observer pattern implementation

Slide 33

Slide 33 text

RequireJS and AMD

Slide 34

Slide 34 text

RequireJS: file and module loader

Slide 35

Slide 35 text

RequreJS: Usage example

Slide 36

Slide 36 text

RequireJS: Main script

Slide 37

Slide 37 text

RequireJS uses Asynchronous Module Definition to load modules

Slide 38

Slide 38 text

AMD: module example

Slide 39

Slide 39 text

Putting thing together

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Demo application

Slide 42

Slide 42 text

backbone-aura

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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