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
Tweet

More Decks by Justin Tulloss

Other Decks in Programming

Transcript

  1. JQUERYTO MARCH, 2014
    Justin Tulloss
    [email protected]
    @justin_tulloss
    Structure over Framework
    Thoughts on building web clients

    View Slide

  2. 2
    Overview
    • What we’re building
    • Structuring an application
    • Optimizing developer productivity
    • Optimizing consumer experience

    View Slide


  3. What we’re building

    View Slide

  4. 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

    View Slide

  5. "
    Structuring an application

    View Slide

  6. 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

    View Slide

  7. 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

    View Slide

  8. 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

    View Slide

  9. 9
    Strict interactions between components
    Child Component
    Parent Component
    API
    Events

    View Slide

  10. 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

    View Slide

  11. #
    Optimizing developer
    productivity

    View Slide

  12. 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

    View Slide

  13. 13
    Example: Catalog.Album

    View Slide

  14. 14
    A Component

    View Slide

  15. 15
    Component Markup

    View Slide

  16. 16
    Component Styles

    View Slide

  17. 17
    Component Behaviors

    View Slide

  18. 18
    Developer Worries
    • Write your markup
    • Describe your model
    • Write/test your behaviors
    • Style your component
    • Ship it!*
    • Find kegerator

    View Slide

  19. 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

    View Slide

  20. $
    Optimizing consumer
    experience

    View Slide

  21. 21
    What to optimize?
    • Measure Everything
    • The product!
    • How well the product works

    View Slide

  22. 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

    View Slide

  23. 23
    How little can be loaded?
    Really fast
    Load

    Time
    # of Features

    View Slide

  24. 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

    View Slide

  25. 25
    Example: Rdio anonymous landing page

    View Slide

  26. 26
    Optimizing Interactions
    • Measure!
    • Have services take care of performance sensitive global behaviors
    • Have components take care of performance sensitive local behaviors
    • IE, Grids

    View Slide

  27. Join Us
    • We love music and JavaScript
    • Canadian friendly!
    • It’s 22° C right now

    View Slide


  28. Questions

    View Slide

  29. 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)

    View Slide