Building a JavaScript Module Framework at Gilt Eric Shepherd @arkitrave
Whois? ‣ background ‣ music | architecture | web design | front end engineering ‣ companies ‣ fisher-price | condé nast | gilt groupe
Thank You! ‣ Nicholas Zakas ‣ scalable javascript application architecture presentation ‣ jQuery Conference 2010 ‣ presentations on pubsub, templating, yepnope, and js architecture
Why?
Why? ‣ code organization ‣ small files + objects, each with a defined role
Why? ‣ code organization ‣ reduce points of dependency ‣ modules communicate through only one channel
Why? ‣ code organization ‣ reduce points of dependency ‣ unobtrusiveness for third-parties ‣ other sites can include your code without fear
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
Demands
Demands ‣ allows multiple unique module instances
Demands ‣ allows multiple unique module instances ‣ does not allow modules to talk to each other ‣ freedom in clear boundaries
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
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
Components
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()
Components ‣ Gilt.App ‣ Gilt.Sandbox ‣ instantiable, one instance per module ‣ provides pubsub, state management, dom interaction, services, views
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
Components ‣ Gilt.App ‣ Gilt.Sandbox ‣ module itself ‣ …along with core code and helpers
Architecture
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
Architecture
Gilt.App
Gilt.App
Architecture
Gilt.Sandbox
Gilt.Sandbox
Architecture
Module
Module
Module View (opt.)
Module View (opt.)
Architecture
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)
Architecture
Wiring It Up ‣ on your own site ‣ page controller ‣ on a third-party site ‣ bootstrap as js loader and controller
WTF
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
A Better Bootstrap
…Which Returns…
Server-Generated Closure
Yep. Nope.
Watch Out For…
Watch Out For… ‣ make sure your bootstrap is RESTful
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
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()
Watch Out For… ‣ make sure your bootstrap is RESTful ‣ css ‣ jQuery ‣ cross-domain issues ‣ make sure your feeds are jsonp
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
You Can Do Anything ‣ anything at all ‣ the only limit is yourself ‣ …yes…
Questions? ‣ Eric Shepherd ‣ eric@arkitrave.com ‣ @arkitrave

Building a JavaScript Module Framework at Gilt

  • 1.
    Building a JavaScript ModuleFramework 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32.
  • 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.
  • 35.
    Wiring It Up ‣ on your own site ‣ page controller ‣ on a third-party site ‣ bootstrap as js loader and controller
  • 36.
  • 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.
  • 39.
  • 40.
  • 41.
  • 42.
  • 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 DoAnything ‣ anything at all ‣ the only limit is yourself ‣ …yes…
  • 49.
    Questions? ‣ Eric Shepherd ‣ eric@arkitrave.com ‣ @arkitrave