Pro Yearly is on sale from $80 to $50! »

Large Scale JavaScript Applications

Large Scale JavaScript Applications

Slides of my talk about large scale JS applications

F32f547e66f3b6528376d67fdb67008f?s=128

Alexander Beletsky

May 12, 2012
Tweet

Transcript

  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