Yahoo! vs. Yahoo!: Case Studies

Yahoo! vs. Yahoo!
: Case Studies
Web Builder 2.0 Las Vegas
SHIBA SANKAR BEHERA

RAVENSHAW MANAGEMENT CENTRE, CUTTACK
Nate Koechley
Senior Engineer & Designer,
Yahoo! User Interface (YUI) Library Team
Platform Engineering Group
Yahoo! Inc.
Slides
http://nate.koechley.com/talks/2006/12/webbuilder/
Contact
http://yuiblog.com
[email protected]
http://developer.yahoo.com/yui
Nate Koechley – [email protected]
My Perspective
 Charter member of Web Development team at Yahoo!

 In the trenches and in management
 Currently:
– Yahoo! User Interface (YUI) Library team
– Senior Front-End Engineer, Technical Evangelist, Design Liaison,
YUIBlog Editor
– Responsible for Yahoo! Browser Support specs
 Strategy and Direction

YUI: The Yahoo! User Interface Library






The DHTML Universe
by Dojo’s Alex Russell (work in progress)
http://alex.dojotoolkit.org/
DHTML_universe.pdf

12345678

2345678
1

345678
12

45678
123

5678
1234

678
12345

78
123456

8
1234567

A Great Community at Yahoo!
(praise them – blame me)

A
A quick
quick history:
history:

A bit of evolution over the years…
1994

1994
1995

1994
1995
1997

1994
1995
1997
2000

1994
1995
1997
2000
2002

1994
1995
1997
2000
2002
2004

1994
1995
1997
2000
2002
2004
Today per month:
188m users
Source: Comscore,
Nate Koechley Feb. 2006
– [email protected]
5.2 billion hits
Video:
Nate Koechley http://nate.koechley.com/talks/2006/12/webbuilder/Yahoo-vs-Yahoo/fp_2.avi
It is immensely telling that
the new Yahoo!
homepage is a DHTML
and Ajax homepage.

Why is this noteworthy?
 “Content delivery” to “software

development”
 Browser as application platform is “the

most hostile environment possible”
 Massive edge-case populations

“Getting
“Getting ItIt Right
Right The
The
Second
Second Time”Time”
(matt
(mattsweeney)
sweeney)

Three Case Studies

Case Study #1
www.yahoo.com
 History
–From scratch
 Massive Scale
–5.2 billion views / month
–188 million unique users / month
 DHMTL and Ajax Implementation
(all data from comScore)

Video:
Nate Koechley http://nate.koechley.com/talks/2006/12/webbuilder/Yahoo-vs-Yahoo/fp_2.avi
Case Study #2
photos.yahoo.com
 History
–From scratch
–Agile design and development project
 Massive Scale
–30 million unique users
–2 billion photos
 Major DHTML and Ajax Implementation

Case Study 2:
Yahoo! Photos Beta
Video:
Nate Koechley http://nate.koechley.com/talks/2006/12/webbuilder/Yahoo-vs-Yahoo/photos3_2.avi
Case Study #3
mail.yahoo.com
 History
–Beta release about 1.5 years ago
–Legacy-ish! (was Oddpost.com since 1999)
 Massive Scale
–World’s largest email provider ~257MM
–Available in 21 languages
 Preeminent DHTML and Ajax
Application
Video:
Nate Koechley http://nate.koechley.com/talks/2006/12/webbuilder/Yahoo-vs-Yahoo/mail_1.avi
(Don’t
(Don’t worry
worry –– not
not aa product
product pitch)
pitch)

Common Goals:
Nate Koechley – [email protected] 42

Common Goals:
1) Performance

Performance:
time-to-paint
time-to-onLoad
speed on the wire
speed of development
memory & CPU footprint

Common Goals:
1) Performance
2) Interactivity

Common Goals:
1) Performance
2) Interactivity
3) Make Good Choices

Common Approaches
Doctype HTML 4.01 Strict XHTML 1.0 Strict None
Render Mode Strict Strict Quirks
CSS Sprites Yes Yes Yes
Font-size Yes Yes No

Responsive
Keyboard Yes Yes Yes
Absolute Pos No No No
Minimization Yes Yes Yes
Obfuscation No No Yes
Compression Yes Yes Yes
from Documents
& Pages
to Applications
The Page—Application Spectrum
 Historically Web  Historically Desktop

 Shallow Interaction  Deep Interaction
 Simple Idioms  Sophisticated Idioms
 Reading  Doing
 Markup + Skin  DOM + Ajax
 Sequential  Contained
 Passive  Active

Page
Page Application
Application

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

1. Tracking Events
4. Data Format
5. Pagination
6. Browser Support

From: Page-Granular
To: Event-Granular

Use an Event Utility:
 No JS in markup attribute space

 Many great utilities
– Dojo
– YUI Event Utility
– many more…
 Watch out for memory leaks!!! (yes, three !’s)

Event Attachment
Obj Obj Obj Obj

+evnts +evnts +evnts +evnts
Obj Obj Obj Obj

Obj Obj Obj Obj


What
What happens
happens as
as your
your app
app
gets
gets more
more complex?
complex?

(more
(more events
events ** more
more objects)
objects)

Feeling
Feeling lucky?
lucky?

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?

From Attachment to Delegation
Obj Obj Obj Obj

Obj Obj Obj Obj

Obj Obj Obj Obj


Obj Obj Obj Obj
Obj Obj Obj Obj
Obj Obj Obj Obj

Obj Obj Obj Obj
Event
Obj Obj Obj Obj
Obj Obj Obj Obj

More on “Delegation”
Minimize Object and Event Count by:

1. Only listen to native
document.onmousedown
(or whatever node makes sense)
2. Then determine which event.target
(native)
3. Just-in-time handler attachment

Tracking Events:
Event Delegation
Obj Obj Obj Obj
Event
Obj Obj Obj Obj
Obj Obj Obj Obj

//listen on parent
YUI.Event.on('parent', 'click', clickDelegate );
function clickDelegate(e){
// get the target
var origin = YUI.Event.getTarget(e, false);
// delegate “just in time”
if(YUI.Dom.hasClass(origin, 'child'))
alert(origin.innerHTML + ' was clicked.');
}
<div id="parent">
<div class="child">Foo</div>
<div class="child">Bar</div>
</div>
http://yuiblog.com/sandbox/yui/v0114/examples/event/delegation.php
Tracking Events:
• Limited objects & simple handlers

• Attachment
• Many objects & multiple handlers

• Delegation
• Many objects & multiple handlers

• Delegation
Page Application
1. Tracking Events
4. Data Format
5. Pagination
6. Browser Support

Memory Management
 Things can get out of hand.

 Goals:
1) Don’t leak memory
2) Keep overall footprint minimal
3) Always-responsive, stable interface

Destructor for each Constructor
 Thoroughly Unhook and

Remove Handlers and
References

Three Approaches
1. DOM Destruction
2. DOM Conservation
3. DOM Recycling

Memory Management
• Conservation (based on use case)
• Destruction
• Destruction, but also...

• Recycling (of iframes)
Page Application
Memory Management Tip:
 Measure and Test

– Drip is a great tool
 Test:
– Extreme object counts
– Long interactions
– Extensive navigation

Drip:
 http://outofhanwell.com/ieleak/index.php?title=Main_Page
 MSDN: Understanding and Solving Internet Explorer Leak Patterns

1. Tracking Events
4. Data Format
5. Pagination
6. Browser Support

General Best Practice
 Single large file is fastest

–Avoid HTTP requests
 CSS near top

 JS near </body>

Other Approaches (1):
1) Many small files at once

– Enables atomic/team development
– Enables partial caching while other parts
change
(build process can clean up and concat.)

2) Many small files on demand

– Tuning in response to use case analysis
– Overall time faster, individual time slower
(bait and switch)

3) Inline in the <head>

– Caching doesn’t always work.
In particular: browser’s home page.

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.
Page Application
1. Tracking Events
4. Data Format
5. Pagination
6. Browser Support

General Best Practice
 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

Other Approaches:
 Somebody pays to render the View

– Pass DOM states as strings
– Important architectural decision
 Finding: Parsing XML degrades performance

greater-than-linearly as XML size increases.

Data Format:
“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 Application
Disclaimer:
Disclaimer:
JSON
JSON is
is great,
great, but
but an
an intimate
intimate understanding
understanding of
of
your
your application
application is
is best.
best.

1. Tracking Events
4. Data Format
5. Pagination
6. Browser Support

could
could !=
!= should
should

Pagination
 In all cases:
– Know your DOM.
– Know your footprint.
– Know your users.

Pagination vs. Endless Scrolling:
• N/A (single page)

• Some Ajax pagination
• Heavy objects
• Pagination with Ajax (new group in memory)
• Light objects
• Endless-scrolling (and clever caching)
Page Application
1. Tracking Events
4. Data Format
5. Pagination
6. Browser Support

Browsers: The Dirty Truth
 The Web is the most hostile

software engineering
environment imaginable.
– Douglas Crockford

Binary Browser Support
 Do I need to support Browser XYZ

on this project?
Same as saying:
Those users aren’t welcome.

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

The Web is Heterogeneous!
“Expecting two users using

different browser software to
have an identical experience fails
to embrace or acknowledge the
heterogeneous essence of the
Web.”

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

2. Grades of support provide an
[appropriate] experience for all.

The Web is about Availability
A graded approach is inclusive and

brings sanity to QA testing.

http://developer.yahoo.com/yui/articles/gbs/gbs.html
Three Grades of Browser Support
 C-grade support (core support, 2%)

 A-grade support (advanced support, 96%)
 X-grade support (the X-Factor, 2%)

http://developer.yahoo.com/yui/articles/gbs/gbs_browser-chart.html

Browser Support:
• GBS A-grade
• Developed in Gecko
• GBS A-grade
• Developed in Gecko
• IE and FF
• Developed in IE, then built IE-emulation layer.
Page Application
Bad
Bad decisions
decisions are
are
tomorrow’s
tomorrow’s constraints.
constraints.

Bad
Bad decisions
decisions are
are tomorrow’s
tomorrow’s constraints.
constraints.
Good
Good decisions
decisions are
are tomorrow’s
tomorrow’s
opportunities.
opportunities.

We’re hiring!
(Josie Arguada: [email protected])
[email protected]
http://nate.koechley.com/talks

Questions?
Questions?
[email protected]

II don’t
don’t know.
know.
[email protected]

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/

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

Thank you.
[email protected]
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/grimreaperwithalawnmower/191890428/
– http://www.flickr.com/photos/jasonmichael/4126695/

Yahoo! vs. Yahoo!: Case Studies

Uploaded by

Copyright:

Available Formats

Yahoo! vs. Yahoo!: Case Studies

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Yahoo! vs. Yahoo!: Case Studies

Uploaded by

Copyright:

Available Formats

Yahoo! vs. Yahoo!

SHIBA SANKAR BEHERA

 Charter member of Web Development team at Yahoo!

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

(praise them – blame me)

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

 “Content delivery” to “software

 Browser as application platform is “the

 Massive edge-case populations

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

(all data from comScore)

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected] 42

Nate Koechley – [email protected] 43

Nate Koechley – [email protected] 44

Nate Koechley – [email protected] 45

Nate Koechley – [email protected] 46

Doctype HTML 4.01 Strict XHTML 1.0 Strict None

Render Mode Strict Strict Quirks

CSS Sprites Yes Yes Yes

Font-size Yes Yes No

Keyboard Yes Yes Yes

Minimization Yes Yes Yes

 Historically Web  Historically Desktop

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

Nate Koechley – [email protected]

 No JS in markup attribute space

Nate Koechley – [email protected]