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

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

What we’re building 

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 

" Structuring an application 

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 

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 

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 

9 Strict interactions between components Child Component Parent Component API Events 

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 

# Optimizing developer productivity 

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 

13 Example: Catalog.Album 

14 A Component 

15 Component Markup 

16 Component Styles 

17 Component Behaviors 

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

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 

$ Optimizing consumer experience 

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

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 

23 How little can be loaded? Really fast Load Time # of Features 

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 

25 Example: Rdio anonymous landing page 

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

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

Questions 

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)