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