1.
Building a JavaScriptModule Framework at Gilt Eric Shepherd @arkitrave

2.
Whois?‣ background ‣ music | architecture | web design | front end engineering‣ companies ‣ fisher-price | condé nast | gilt groupe

3.
Thank You!‣ Nicholas Zakas ‣ scalable javascript application architecture presentation‣ jQuery Conference 2010 ‣ presentations on pubsub, templating, yepnope, and js architecture

4.
Why?

5.
Why?‣ code organization ‣ small files + objects, each with a defined role

6.
Why?‣ code organization‣ reduce points of dependency ‣ modules communicate through only one channel

7.
Why?‣ code organization‣ reduce points of dependency‣ unobtrusiveness for third-parties ‣ other sites can include your code without fear

8.
Why?‣ code organization‣ reduce points of dependency‣ unobtrusiveness for third-parties‣ adaptability + extensibility ‣ any piece of the application can be switched out without affecting the rest of the application

9.
Demands

10.
Demands‣ allows multiple unique module instances

11.
Demands‣ allows multiple unique module instances‣ does not allow modules to talk to each other ‣ freedom in clear boundaries

12.
Demands‣ allows multiple unique module instances‣ does not allow modules to talk to each other‣ tightly restricts dom access (with a few exceptions) ‣ the page doesn’t need to worry about being messed with

13.
Demands‣ allows multiple unique module instances‣ does not allow modules to talk to each other‣ tightly restricts dom access (with a few exceptions)‣ touches as little global code as possible ‣ ideally, only one global var

14.
Components

15.
Components‣ Gilt.App ‣ there is only one ‣ manages all modules, provides one sandbox to each module ‣ public api is register(), start(), stop(), startAll(), stopAll(), view.register()

16.
Components‣ Gilt.App‣ Gilt.Sandbox ‣ instantiable, one instance per module ‣ provides pubsub, state management, dom interaction, services, views

17.
Components‣ Gilt.App‣ Gilt.Sandbox‣ module itself ‣ implements a simple create() and destroy() interface ‣ it’s an overprotected child, with a limited view of the world

18.
Components‣ Gilt.App‣ Gilt.Sandbox‣ module itself‣ …along with core code and helpers

19.
Architecture

20.
Flow‣ a module is a function, passed to App.register() as a creator‣ on App.start(), a new Sandbox() instance is passed to that creator, which returns public create and destroy methods, and…‣ the new module instance’s create() is called

21.
Architecture

22.
Gilt.App

23.
Gilt.App

24.
Architecture

25.
Gilt.Sandbox

26.
Gilt.Sandbox

27.
Architecture

28.
Module

29.
Module

30.
Module View (opt.)

31.
Module View (opt.)

32.
Architecture

33.
The Hoff Helpers‣ jQuery‣ underscore.js‣ handlebars.js‣ yepnope.js‣ &c…but modules can’t know anything about these (jQuery as a partial exception due to its plugin architecture)

34.
Architecture

35.
Wiring It Up‣ on your own site ‣ page controller‣ on a third-party site ‣ bootstrap as js loader and controller

36.
WTF

37.
A Better Bootstrap‣ don’t be a jerk – think of the children‣ protect the global scope – you’re in someone else’s house!‣ make it easy to inline or inject the script dynamically‣ keep the payload light – it’s like spending someone else’s money

38.
A Better Bootstrap

39.
…Which Returns…

40.
Server-Generated Closure

41.
Yep. Nope.

42.
Watch Out For…

43.
Watch Out For…‣ make sure your bootstrap is RESTful

44.
Watch Out For…‣ make sure your bootstrap is RESTful‣ css ‣ conflicts are a bitch ‣ and you can’t use id selectors ‣ !important is your only hope ‣ jquery.important can help, but it’s the roach motel, and animations are out

45.
Watch Out For…‣ make sure your bootstrap is RESTful‣ css‣ jQuery ‣ plugin convention requires a globally- accessible jQuery object ‣ so noConflict(true) will work only if you don’t need plugins ‣ use sandbox.getContainer().find()

46.
Watch Out For…‣ make sure your bootstrap is RESTful‣ css‣ jQuery‣ cross-domain issues ‣ make sure your feeds are jsonp

47.
Watch Out For…‣ make sure your bootstrap is RESTful‣ css‣ jQuery‣ cross-domain issues‣ assumptions of shared code ‣ included code can later introduce dependencies unavailable on a third- party site, hard to test

48.
You Can Do Anything‣ anything at all‣ the only limit is yourself‣ …yes…

49.
Questions?‣ Eric Shepherd‣ eric@arkitrave.com‣ @arkitrave