Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Structure over Framework

Structure over Framework

Breakout session talk given at jQueryTO on how I think about structuring large JS applications.

Justin Tulloss

March 16, 2014

More Decks by Justin Tulloss

Other Decks in Programming


  1. 2 Overview • What we’re building • Structuring an application

    • Optimizing developer productivity • Optimizing consumer experience
  2. 4 We’re building a codebase • Many people are going

    to touch this code • From adding features to fixing bugs to massive refactors • Even more people will need to read the code • Code review! • Old code never dies • Single page application • Data driven
  3. 6 What’s in an application? • Services • API, analytics,

    loading code, DOM manipulations, animations, perf tracking, etc. • Models (View Models) • Data • View specific information inferred from the data • UI Components • Rely on services and models • Contain markup, styling, and behavior
  4. 7 Services at Rdio • Globally available • Services implement

    a simple state machine • Stopped, starting, ready • Indicate when they’re available to be used, cannot be used until they say they’re ready • Can depend on other services and libraries, but nothing else (no UI components) • Multiple classes can provide the same service
  5. 8 UI Components • Package of markup, styling, and behavior

    • Form the tree of the application • Have a standardized lifecycle • Have a model, but don’t care too much what’s in it (just that it’s the right type) • Responsible for keeping the UI up to date (data-binding or rerendering) • Can depend on models, services, and other libs • Can declare other component dependencies and instantiate those components
  6. 10 Models • Provide data • Provide APIs for manipulating

    that data • Provide APIs for gaining greater context around the data • For instance, how do I say “Share this model” in the UI? • Can rely on services for achieving the above goals
  7. 12 Principles • Only one way to do things •

    Inspecting the DOM should point the developer to the source of the elements • CSS scoping happens automatically • Declare program dependencies, not file dependencies • Strong patterns around what can be changed and what can be changed with caution • Documentation, method naming, tests, etc
  8. 18 Developer Worries • Write your markup • Describe your

    model • Write/test your behaviors • Style your component • Ship it!* • Find kegerator
  9. 19 Developer Non-worries • Loading of markup/styles/behaviors • Loading of

    dependencies • Optimizations related to rendering, animation, caching, packaging, everything except the specific job of the component • Updating code
  10. 22 How well the product works • Perception is what

    counts • Time to app perceived as loaded • Time to first X • Interactions as the user continues to use the product
  11. 24 Easy win: Caching + CDNs • CDNs are cheap

    and easy now, use them • Cache files with aggressive cache headers (public, 1 year max age) • Put files MD5 signatures in file names • Ideal is that repeat users only have to load code that has changed • Balanced against more requests for first time visitors
  12. 26 Optimizing Interactions • Measure! • Have services take care

    of performance sensitive global behaviors • Have components take care of performance sensitive local behaviors • IE, Grids
  13. Join Us • We love music and JavaScript • Canadian

    friendly! • It’s 22° C right now
  14. 29 Thanks! • Organizers have been fantastic • Thanks to

    Rdio for letting me come out and talk to all you fine folks • dancewithlight and 500px for SF skyline photo (http://500px.com/photo/58946980)