nate koechley

95
1 Y! v. Y! v. Y! Three Yahoo! Case Studies Across the Page—Application Spectrum, One Size Does Not Fit All Nate Koechley – [email protected] | http://nate.koechley.com/blog AJAXWorld Conference & Expo, October 2 nd – 4 th , 2006

Upload: ike

Post on 12-Jan-2016

90 views

Category:

Documents


0 download

DESCRIPTION

Y! v. Y! v. Y! Three Yahoo! Case Studies Across the Page—Application Spectrum, One Size Does Not Fit All. Nate Koechley – [email protected] | http://nate.koechley.com/blog AJAXWorld Conference & Expo, October 2 nd – 4 th , 2006. Nate Koechley. It’s Pronounced “Kek’lee”. Hello, World. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Nate Koechley

1

Y! v. Y! v. Y! Three Yahoo! Case Studies

Across the Page—Application Spectrum, One Size Does Not Fit All

Nate Koechley – [email protected] | http://nate.koechley.com/blog AJAXWorld Conference & Expo, October 2nd – 4th, 2006

Page 2: Nate Koechley

2

Nate Koechley

Page 3: Nate Koechley

3

It’s Pronounced “Kek’lee”

Page 4: Nate Koechley

4

Hello, World

• Nate Koechley

– At Yahoo! since 2001

– Charter member of Web Development team

– On Yahoo! User Interface Library (YUI) team

• Three roles:

– Senior Frontend Engineer

– Technical Evangelist

– Design Liaison

Page 6: Nate Koechley

6

12345678

Page 7: Nate Koechley

7

12345678

Page 8: Nate Koechley

8

12345678

Page 9: Nate Koechley

9

12345678

Page 10: Nate Koechley

10

12345678

Page 11: Nate Koechley

11

12345678

Page 12: Nate Koechley

12

12345678

Page 13: Nate Koechley

13

12345678

Page 14: Nate Koechley

14

A Great Community at Yahoo!

Page 15: Nate Koechley

15

Praise Them, Blame Me

Page 16: Nate Koechley

16

You?

Page 17: Nate Koechley

17

OK then, a quick history:

Page 18: Nate Koechley

18

1994

A bit of evolution over the years…

Page 19: Nate Koechley

19

1994

1995

A bit of evolution over the years…

Page 20: Nate Koechley

20

1994

1995

1997

A bit of evolution over the years…

Page 21: Nate Koechley

21

1994

1995

1997

2000

A bit of evolution over the years…

Page 22: Nate Koechley

22

1994

1995

1997

2000

2002

A bit of evolution over the years…

Page 23: Nate Koechley

23

1994

1995

1997

2000

2002

2004

A bit of evolution over the years…

Page 24: Nate Koechley

24

1994

1995

1997

2000

2002

2004

…into the page that today welcomes 188m users every month, 5.2 billion times

A bit of evolution over the years…

Source: Comscore, Feb. 2006

Page 25: Nate Koechley

25

The New Yahoo! Home Page

Video: http://nate.koechley.com/talks/20061003_ajaxworld/fp_2.avi

Page 26: Nate Koechley

26

It is immensely telling that the new Yahoo! homepage

is a DHTML homepage.

Page 27: Nate Koechley

27

“Getting It Right The Second Time”

Page 28: Nate Koechley

28

Three Case Studies

Page 29: Nate Koechley

29

Case Study 1:

• History

– From scratch

– Freshest development effort to be released

• Massive Scale

– 5.2 billion views per month

– 188 million unique users

• Major DHMTL and Ajax Implementation

Page 30: Nate Koechley

30

Case Study 1:

Yahoo! Home Page Preview

Video: http://nate.koechley.com/talks/20061003_ajaxworld/fp_2.avi

Page 31: Nate Koechley

31

Case Study 2:

• History

– From scratch

– Long development timeline

• Massive Scale

– 30 million unique users

– 2 billion photos

• Major DHTML and Ajax Implementation

Page 32: Nate Koechley

32

Case Study 2:

Yahoo! Photos Beta

Video: http://nate.koechley.com/talks/20061003_ajaxworld/photos3_2.avi

Page 33: Nate Koechley

33

Case Study 3:

• History– Beta release about 1.25 years ago

– Legacy-ish, was Oddpost.com

– Oddpost development began in 1999

• Massive Scale– World’s largest email provider

– Available in 21 languages

• Preeminent DHTML and Ajax Application

Page 35: Nate Koechley

35

do not worry – not a product pitch

Page 36: Nate Koechley

36

Common Goals:

Page 37: Nate Koechley

37

Common Goals:

1) Performance (x3)

Page 38: Nate Koechley

38

Common Goals:

1) Performance 2) Interactivity

Page 39: Nate Koechley

39

Common Goals:

1) Performance 2) Interactivity3) Stay true to our beliefs

Page 40: Nate Koechley

40

Common Approaches:

Page 41: Nate Koechley

41

The Basics

NoNoNoAbsolute Pos

YesYesYesCompression

YesNoNoObfuscation

YesYesYesMinimization

YesYesYesKeyboard

NoYesYesFont-size Responsive

YesYesYesCSS Sprites

QuirksStrictStrictRender Mode

NoneXHTML 1.0 Strict

HTML 4.01 Strict

Doctype

Page 42: Nate Koechley

42

From Documents to Applications

Page 43: Nate Koechley

43

Page—Application Spectrum

• Historically Web

• Shallow Interaction

• Simple Idioms

• For Consumption

• Markup + Skin

• Sequential Nav

• Passive

• Historically Desktop

• Deep Interaction

• Powerful Idioms

• For Productivity

• JS, DHTML, Ajax, DOM

• Self Contained

• Active

ApplicationApplicationPagePage

Page 44: Nate Koechley

44

Page—Application Spectrum

ApplicationApplicationPagePage

Page 45: Nate Koechley

45

Looking Across the Spectrum

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

Page 46: Nate Koechley

46

Looking Across the Spectrum:Tracking Events

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

Page 47: Nate Koechley

47

From Page-Granular to Event-Granular Interfaces

Page 48: Nate Koechley

48

Tracking Events:Event Utilities

• Don’t piss off the DOM Scripting Task Force– No JS in attribute space / markup!

• Watch out for memory leaks!!! (yes, three !’s)

• Many great utilities– YUI Event Utility

– Dojo

– Scott Andrew

– many more…

Page 49: Nate Koechley

49

Tracking Events: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

Page 50: Nate Koechley

50

Browsers die when there are too many (objects + listeners)

Page 51: Nate Koechley

51

Tracking Events:Lots and lots

• Objects can have many events:

– Multiple keyboard listeners

– Down+drag

– Down+key

– Down+doubleclick

– Down+click+key

– More…

• Multiple by countless number of objects!

Page 52: Nate Koechley

52

Tracking Events:Event Delegation

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Obj+evnts

Page 53: Nate Koechley

53

Tracking Events:Event Delegation

Obj Obj Obj Obj

Obj Obj Obj Obj

Obj Obj Obj Obj

Page 54: Nate Koechley

54

Tracking Events:Event Delegation

Obj Obj Obj Obj

Obj Obj Obj Obj

Obj Obj Obj Obj

Event

Page 55: Nate Koechley

55

More on “Delegation”

Addressing Object Count1. Listen to document.onmousedown (native)

2. Note which event.target (native)

Addressing Handler Count

3. Then delegate and attach the handlers you need, just in time.

Page 56: Nate Koechley

56

Event Delegation Example:

• Mousedown in vicinity of thumbnail

– If on <img>

• If MouseMove

–Assign Drag and Drop

– If on whitespace

• If MouseMove

–Assign Selection Rectangle

Page 57: Nate Koechley

57

Event Delegation Example:

• Is the click on a photo thumbnail?

• If so, delegate to its related Javascript controller object eg: photoItems[this.index].mousedown();

• Where "this" is the thumbnail <img> clicked, via event.target/srcElement etc.

Page 58: Nate Koechley

58

Tracking Events:Event Delegation

Obj Obj Obj Obj

Obj Obj Obj Obj

Obj Obj Obj Obj

Event

Page 59: Nate Koechley

59

Tracking Events:Details

ApplicationApplicationPagePage

•Few Objects with Simple Handlers

•Event Attachment

•Many Objects w/ Multiple Handlers

•Event Delegation

•Many Objects w/ Multiple Handlers

•Event Delegation

Page 60: Nate Koechley

60

Looking Across the Spectrum:Memory Management

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

Page 61: Nate Koechley

61

Memory Management

• With extensive DOM and JS work, there’s the potential for things to get out of hand.

• Goals:

– Don’t leak memory• Also, keep overall memory footprint small

– Offer a quickly-responsive interface

– Stability

Page 62: Nate Koechley

62

Memory Management:General Best Practices

For each constructor have a destructor

1. Create Objects

2. Unhook

3. Remove Handlers

4. Remove References

Page 63: Nate Koechley

63

Memory Management:Three Approaches

1. Destruction (general best practice)

2. Conservation (niche)

3. Recycling (niche)

Page 64: Nate Koechley

64

Memory Management:Details

ApplicationApplicationPagePage

•Conservation

•Destruction

•Destruction, but…

•Recycle iframes (about:blank)

Page 65: Nate Koechley

65

Memory Management Tip:

• Measure and Test

– Drip is a great tool

– Test extreme object counts

– Test long interactions

– Test extensive navigation

Page 66: Nate Koechley

66

Looking Across the Spectrum:Delivering JS and CSS

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

Page 67: Nate Koechley

67

Delivering JS and CSS:General Best Practices

• A single large file loads fastest.

– HTTP requests are the nemesis of a well-tuned site.

– Build process is, therefore, very important.

• CSS files as close to the top as possible.

• JS files as close to </body> as possible.

Page 68: Nate Koechley

68

Delivering JS and CSS:Three Other Approaches

1) Many small files at once

– Enables atomic/team development

– Enables partial caching if parts change

Page 69: Nate Koechley

69

Delivering JS and CSS:Three Other Approaches

2) Many small files on demand

– Some demanded functionality may be subtly slower

– Allows tuning in response to use cases and task analysis

Page 70: Nate Koechley

70

Delivering JS and CSS:Three Other Approaches

3) Inline in the <head>

– Caching is not as effective as we imagine, especially on pages set as browser’s default home page.

Page 71: Nate Koechley

71

Delivering CSS and JS:Details

ApplicationApplicationPagePage

•Many smaller files, on demand. Some inline.

•Every feature not used every time. Content is key.

•Uber file of interface JS/CSS. Pay once.

•Objects/data on demand

•Single File (anti-example)

•Functionality is key. Highly interconnected.

Page 72: Nate Koechley

72

Looking Across the Spectrum:Data Format

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

Page 73: Nate Koechley

73

Data Format:General Best Practice

• Use JSON for data interchange

– Natively understood

– “The fat-free alternative to XML”

• http://www.json.org

– Tools in every known programming language

Page 74: Nate Koechley

74

Data Format:Other Approaches

• Somebody is going to have to pay the CPU price to render the View– Faster to pass a string that expresses a DOM state

directly than trying to parse and create on the fly.

– Consider client and server in tandem when making architectural choices

• Parsing XML degrades performance greater-than-linearly as XML size increases.

Page 75: Nate Koechley

75

Data Format:Details

ApplicationApplicationPagePage

“JSON rocks”

“We want to move to JSON”

“We’re using some JSON, and will be much more soon”

Recognize strengths of client and server

Page 76: Nate Koechley

76

Looking Across the Spectrum:Pagination

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

Page 77: Nate Koechley

77

“Ajax is awesome!! Hmmm, I know: we can do

pagination without refreshing the page!!

Sweet, we’re so totally Web 2.0 now!!”

Page 78: Nate Koechley

78

could != should

Page 79: Nate Koechley

79

Pagination:Details

ApplicationApplicationPagePage

•Single page, so basically not applicable.

•Some Ajax pagination in Personal Assistant module

•Heavy Objects

•Ajax Pagination; No refresh but new collection.

•Light Objects

•Endless-scrolling (and clever caching)

Page 80: Nate Koechley

80

Looking Across the Spectrum:Browser Support

1. Tracking Events

2. Memory Management

3. Delivering JS and CSS

4. Data Format

5. Pagination

6. Browser Support

Page 81: Nate Koechley

81

Which browser to support?

Page 82: Nate Koechley

82http://developer.yahoo.com/yui/articles/gbs/gbs.html

Page 83: Nate Koechley

83

Graded Browser Support:Two Key Ideas

1) Support does not mean “the same”

“Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web.”

2) Support must not be binary!

Page 84: Nate Koechley

84

Graded Browser Support:General Best Practice

• 3 Grades of Browser Support

C-grade support (core support, 2%)

A-grade support (advanced support, 97%)

X-grade support (the X-Factor, 1%)

Page 85: Nate Koechley

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

Page 86: Nate Koechley

86

A bit about browser stats…

Page 87: Nate Koechley

87

A bit about browser stats…

• More 5.0 than 5.5;

– We consider 5.0 C-Grade

• Note by-country skews

• Note by-content skews

• IE7 already moved the needle

– Historically, SP2 rollout out very quickly

Page 88: Nate Koechley

88

Browser as Development Environment?

Page 89: Nate Koechley

89

Browser Support:Summary

• Still a huge pain in the ass.– The Web is the most hostile software

engineering environment imaginable. (Douglas Crockford)

• Same answer for everybody.– Develop to standards, then patch.

• Maintain discipline in the face of heterogeneity.

Page 90: Nate Koechley

90

The price is always higher to say “no” to Safari and Opera

Page 91: Nate Koechley

91

Browser Support:Details

ApplicationApplicationPagePage

•GBS A-grade

•Developed in Gecko

•GBS A-grade

•Developed in Gecko

•IE and FF

•Developed in IE, then built IE-emulation layer.

Page 92: Nate Koechley

92

We're in this for the long haul.

Page 93: Nate Koechley

93

Quality is OUR job. Be belligerent.

Page 94: Nate Koechley

94

Today’s bad decisions will be tomorrow’s constraints

Page 95: Nate Koechley

95

Thank you. Questions?

Nate Koechley

[email protected]• http://developer.yahoo.com/yui

• http://yuiblog.com

[email protected]• http://nate.koechley.com/blog

This presentation is available at http://nate.koechley.com/talks/