1. Yahoo! vs. Yahoo! Three Large-Scale Mainstream DHTML Implementations Nate Koechley natek@yahoo-inc.com natek@yahoo-inc.com nate@koechley.com nate@koechley.com yuiblog.com yuiblog.com developer.yahoo.com/yui nate.koechley.com/blog developer.yahoo.com/yui nate.koechley.com/blog

2. a short historical story…

3. 1994

4. 1995

5. 1994 1995 1997

6. 1994 1995 1997 2000

7. 1994 1995 1997 2000 2002

8. 1994 1995 1997 2000 2002 2004

9. 1994 1995 1997 2000 2002 2004 2005 Source: Comscore, Feb. 2006

10. 1994 1995 1997 2000 2002 2004 2005 2007 188mm users /month 5.2billion hits /month Source: Comscore, Feb. 2006

11. Video: http://nate.koechley.com/talks/2007/web-design-world/y-vs-y/fp_4.avihttp://nate.koechley.com/talks/2007/web-design-world/y-vs-y/fp_4.avi

12. so what?

13. It is immensely telling that the new Yahoo! homepage is a DHTML and Ajax homepage.

14. why?

15. because of these facts?

16. It’s noteworthy because: 1.“Browser are the most hostile software engineering environment possible” (Douglas Crockford)

17. It’s noteworthy because: 1.“Browser are the most hostile software engineering environment possible” (Douglas Crockford) 2.Massive edge-cases and unknowns

18. It’s noteworthy because: 1.“Browser are the most hostile software engineering environment possible” (Douglas Crockford) 2.Massive edge-cases and unknowns 3.From content distribution to true software development

19. It’s noteworthy because: 1.“Browser are the most hostile software engineering environment possible” (Douglas Crockford) 2.Massive edge-cases and unknowns 3.From content distribution to true software development 4.From Implementation Models to Mental Models

20. from implementation model to mental model

21. “Every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.” ----Larry Tesler’s Law of Conservation of Complexity

22. Which is better? a) 100 milliseconds? b) 27 ½ years?

24. “getting it right the second time” --matt sweeney

25. Three Case Studies

26. From Scratch Massive Scale –5.2 billion views/month –188 million unique users/month DHMTL/Ajax Implementation (all data from comScore)

27. Video: http://nate.koechley.com/talks/2007/web-design-world/y-vs-y/fp_4.avihttp://nate.koechley.com/talks/2007/web-design-world/y-vs-y/fp_4.avi

28. From Scratch –With legacy constraints Massive Scale –50 million unique users –Open content platform Major DHTML/Ajax Implementation

29. Video: http://nate.koechley.com/talks/2006/12/webbuilder/Yahoo-vs-Yahoo/photos3_2.avihttp://nate.koechley.com/talks/2006/12/webbuilder/Yahoo-vs-Yahoo/photos3_2.avi Video: http://nate.koechley.com/talks/2007/web-design-world/y-vs-y/my_1.avihttp://nate.koechley.com/talks/2007/web-design-world/y-vs-y/my_1.avi

30. Legacy –For IE via Oddpost in 1999 Massive Scale –World’s largest email provider ~ 275MM –Available in 21+ languages Preeminent DHTML/Ajax Application

31. Video: http://nate.koechley.com/talks/2007/web-design-world/y-vs-y/mail_3.avihttp://nate.koechley.com/talks/2007/web-design-world/y-vs-y/mail_3.avi

32. Common Goals (Technical) 1.Interactivity

33. 1) Interactivity Simple Efficient Powerful Rich Familiar Delightful

34. “It’s not about what you can do, but how quickly” -- Steve Carlson, Lead Web Developer, My Yahoo!

35. Common Goals (Technical) 1.Interactivity 2.Performance

36. “Law 3: Savings in time feel like simplicity.” -- John Maeda The Laws of Simplicity, MIT Press

37. 2) Performance Time ‘til paint Time ‘til onLoad Speed over the wire Speed of development Resource footprint

38. Common Goals (Technical) 1.Interactivity 2.Performance 3.Soundness

39. 3) Soundness True to our beliefs Stable and foundational Maintainable Testable, tunable

40. Some Common Approaches Yes Compression YesNo Obfuscation Yes Minimization Yes Keyboard NoYes Font-size Responsive Yes CSS Sprites QuirksStrict Render Mode NoneHTML 4.01 Strict Doctype

41. to Applications from Documents & Pages

42. The Page—Application Spectrum Historically Web Shallow Interaction Simple Idioms Content-Focused Markup + Skin Sequential Passive Historically Desktop Deep Interaction Sophisticated Idioms Process-Focused DOM + Ajax Contained Active

43. ApplicationPage

44. Looking Across the Spectrum 1.Tracking Events 2.Memory Management 3.Delivering JS and CSS 4.Data Format 5.Pagination 6.Browser Support

45. Looking Across the Spectrum 1.Tracking Events 2.Memory Management 3.Delivering JS and CSS 4.Data Format 5.Browser Support

46. From: Page-Granular To: Event-Granular

47. Use an Event Utility: No JS in markup attribute space Many great utilities –Dojo –YUI Event Utility –many more… Watch out for memory leaks, really

48. Event Attachment Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts

49. What happens as your app gets more complex?

50. more events x more objects

51. Feeling lucky?

53. Tracking Events: The Challenge How can we minimize the number of objects in play? How can we minimize the number of events attached and tracked?

54. Example: Standard Attachment Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts Obj +evnts

55. Example: Single Delegating Event Obj Event

56. Minimize object and event counts: 1.Capture the element high in the DOM tree: document.onclick 2.Then determine which element getTarget() 3.Then add just-in-time logic Example: http://yuiblog.com/sandbox/yui/v0114/examples/event/delegation.php

58. Tracking Events: Limited objects & simple handlers Attachment Event Delegation Plan Event Model API divorced from UI Many objects & multiple handlers Event Delegation PlanApplicationPage

59. Looking Across the Spectrum 1.Tracking Events 2.Memory Management 3.Delivering JS and CSS 4.Data Format 5.Browser Support

60. Memory Management Things can get out of hand. Things will get out of hand. Goals: 1) Don’t leak memory 2) Keep overall footprint minimal 3) Always-responsive, stable interface

61. The Key Approach 1.DOM Destruction Thoroughly Unhook and Remove Handlers and References YUI Event provides lots for free

62. Two Approaches 1.DOM Preservation 2.DOM Recycling

63. Memory Management Tip (1) Monitor Usage Drip is a great tool on PC –MSDN: Understanding and Solving Internet Explorer Leak PatternsUnderstanding and Solving Internet Explorer Leak Patterns –http://outofhanwell.com/ieleak/index.php?t itle=Main_Pagehttp://outofhanwell.com/ieleak/index.php?t itle=Main_Page

64. Memory Management Tip (2) Monitor Various Usage Cases 1. Extreme object counts 2. Long interactions 3. Extensive navigation

65. Memory Management Preservation (based on use case) Destruction Destruction, but also... Recycling (of iframes)ApplicationPage

66. Looking Across the Spectrum 1.Tracking Events 2.Memory Management 3.Delivering JS and CSS 4.Data Format 5.Browser Support

67. General Best Practice: Single large file is fastest Minimize HTTP requests –http://yuiblog.com/blog/2006/11/28/p erformance-research-part-1/http://yuiblog.com/blog/2006/11/28/p erformance-research-part-1/ CSS near top JS near

68. Another Approach (1) Many small files at once Enables –team development –atomic testing –partial caching A build process can clean up and concatenate for production

69. Another Approach (2) Many small files on demand Enables –easier tuning in response to real-world usage –Faster overall time, though sometimes slower individual time (bait and switch)

70. Another Approach (3) Inline in the Caching doesn’t always work. –In particular: browser’s home page. DNS lookups are costly Extra domains are costly

71. Yahoo! Confidential Nate Koechley – natek@yahoo-inc.com 71 Delivering CSS and JS: Many smaller files, on demand. Some inline. Every feature not used every time. Content is key. Über files of interface JS/CSS. Pay once. Then, data and objects on demand Single file (anti-example) Functionality is key. Highly interconnected.ApplicationPage

72. Looking Across the Spectrum 1.Tracking Events 2.Memory Management 3.Delivering JS and CSS 4.Data Format 5.Browser Support

73. General Best Practice (1) Use JSON for data interchange –“The fat-free alternative to XML” –Natively understood. No parsing or crawling. –It’s Ajax not AJAX http://www.json.org –Tools in every known programming language

74. General Best Practice (2) Track and create “state” on the server. My Y!: –Pass generated HTML in set JSON wrapper –Set JSON structure includes content, metadata, and assets

75. Other Notes: Who’s CPU to heat up is an important architectural question. Finding: Parsing XML degrades performance greater-than-linearly as XML size increases.

76. Yahoo! Confidential Nate Koechley – natek@yahoo-inc.com 76 Data Format: “JSON rocks” JSON, DOM strings “Some JSON, and more soon” “Be sure to recognize strengths of client and server”ApplicationPage

77. Disclaimer: JSON is great, but an intimate understanding of your application is best.

78. Looking Across the Spectrum 1.Tracking Events 2.Memory Management 3.Delivering JS and CSS 4.Data Format 5.Browser Support

79. Binary Browser Support Do I need to support Browser Foo on this project? Same as saying: Those users aren’t welcome.

80. Graded Browser Support 1.“Support” does not mean “Same”

81. same isn’t important “Expecting identical experiences fails to embrace or acknowledge the heterogeneous essence of the Web.”

82. Graded Browser Support 2. Grades of support provide an [appropriate] experience for all.

83. The Web is about Availability A graded approach welcomes everyone while bringing sanity to development and testing.

84. Browsers: The Dirty Truth The Web is the most hostile software engineering environment imaginable. – Douglas Crockford

85. http://developer.yahoo.com/yui/articles/gbs/

86. C-grade - core support, ~ 2% A-grade - advanced support, ~ 96% X-grade - the X-Factor, ~ 2% Three Grades of Browser Support

87. http://developer.yahoo.com/yui/articles/gbs/

90. Yahoo! Confidential Nate Koechley – natek@yahoo-inc.com 90 Browser Support: GBS A-grade Developed with Web Standards GBS A-grade Developed with Web Standards IE and FF Developed in IE, then built IE-emulation layer.ApplicationPage

91. Cheat Sheet: 1.Stay true to your beliefs 2.Have an event plan 3.Monitor memory and CPU 4.Minimize HTTP requests 5.Create state on server 6.Have a sane browser support plan

92. Bad decisions are tomorrow’s constraints.

93. Good decisions are tomorrow’s opportunities.

94. Thank you.

95. We’re Hiring! Josie Aguada: jaguada@yahoo-inc.comjaguada@yahoo-inc.com Usual suspects: JavaScript, PHP, CSS, HTML, ActionScript…

96. Thank you. natek@yahoo-inc.com http://nate.koechley.com/talks/2007 http://developer.yahoo.com/yui http://yuiblog.com http://nate.koechley.com/blog Photo Credits: –http://www.flickr.com/photos/jacqueline-w/56107224/http://www.flickr.com/photos/jacqueline-w/56107224/ –http://www.flickr.com/photos/grimreaperwithalawnmower/191890428/http://www.flickr.com/photos/grimreaperwithalawnmower/191890428/ –http://www.flickr.com/photos/jasonmichael/4126695/http://www.flickr.com/photos/jasonmichael/4126695/

97. nate@koechley.com Questions?

98. i don’t know.

99. Namespaces History –JS is load-and-go; text is eval’d; Implied global variables were a nicety Bad because of unreliability and insecurity –Trouble when we mashup, have many devs, and programs get large Many global variables is bad Ideally, only a single global per app|lib|widget –An object which contains all others Speed unaffected; self documentation; reliable Shorten locally if you want. http://yuiblog.com/blog/2006/06/01/global-domination/

100. Single Page vs. Multiple Page What’s the sweet spot?