yahoo! vs. yahoo! three large-scale mainstream dhtml implementations

Post on 12-Jan-2016

44 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Yahoo! vs. Yahoo! Three Large-Scale Mainstream DHTML Implementations. Nate Koechley natek@yahoo-inc.com • nate@koechley.com yuiblog.com • developer.yahoo.com/yui • nate.koechley.com/blog. a short historical story…. 1994. 1994 1995. 1994 1995 1997. 1994 1995 1997 2000. 1994 - PowerPoint PPT Presentation

TRANSCRIPT

Yahoo! vs. Yahoo!Three Large-Scale Mainstream

DHTML Implementations

Nate Koechleynatek@yahoo-inc.com • nate@koechley.comyuiblog.com • developer.yahoo.com/yui • nate.koechley.com/blog

a short historical story…

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

2005

Source: Comscore, Feb. 2006

1994

1995

1997

2000

2002

2004

2005

2007188mm users /month

5.2billion hits /month

Source: Comscore, Feb. 2006

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

so what?

It is immensely telling that the

new Yahoo! homepage is a

DHTML and Ajax

homepage.

why?

because of these facts?

It’s noteworthy because:

1. “Browser are the most hostile software engineering environment possible”

(Douglas Crockford)

It’s noteworthy because:

1. “Browser are the most hostile software engineering environment possible” (Douglas Crockford)

2. Massive edge-cases and unknowns

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

It’s noteworthy because:

1. “Browser are the most hostile software engineering environment possible” (Douglas Crockford)

2. Massive edge-cases and unknowns3. From content distribution to true

software development

4. From Implementation Models to Mental Models

from implementation model

to mental model

“Every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.”

----Larry Tesler’sLaw of Conservation of Complexity

Which is better?

a) 100 milliseconds?

b) 27 ½ years?

“getting it right the second time”

--matt sweeney

Three Case Studies

• From Scratch• Massive Scale

– 5.2 billion views/month– 188 million unique users/month

• DHMTL/Ajax Implementation(all data from comScore)

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

• From Scratch– With legacy constraints

• Massive Scale– 50 million unique users– Open content platform

• Major DHTML/Ajax Implementation

Video: http://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.avi

• Legacy– For IE via Oddpost in 1999

• Massive Scale– World’s largest email provider ~ 275MM– Available in 21+ languages

• Preeminent DHTML/Ajax Application

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

Common Goals (Technical)

1. Interactivity

1) Interactivity

• Simple• Efficient• Powerful• Rich• Familiar• Delightful

“It’s not about what you can do, but how quickly”

-- Steve Carlson,Lead Web Developer, My Yahoo!

Common Goals (Technical)

1. Interactivity2. Performance

“Law 3: Savings in time feel like simplicity.”

-- John MaedaThe Laws of Simplicity, MIT Press

2) Performance

• Time ‘til paint• Time ‘til onLoad• Speed over the wire• Speed of development• Resource footprint

Common Goals (Technical)

1. Interactivity2. Performance3. Soundness

3) Soundness

• True to our beliefs• Stable and foundational• Maintainable• Testable, tunable

Some Common Approaches

YesYesYesCompression

YesNoNoObfuscation

YesYesYesMinimization

YesYesYesKeyboard

NoYesYesFont-size Responsive

YesYesYesCSS Sprites

QuirksStrictStrictRender Mode

NoneHTML 4.01 Strict

HTML 4.01 Strict

Doctype

toto Applications Applications

from from Documents Documents & Pages& Pages

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

ApplicationApplicationPagePage

Looking Across the Spectrum

1. Tracking Events2. Memory Management3. Delivering JS and CSS4. Data Format5. Pagination6. Browser Support

Looking Across the Spectrum

1. Tracking Events2. Memory Management3. Delivering JS and CSS4. Data Format5. 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, really

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

What happens as your app gets more complex?

more events x more objects

Feeling lucky?Feeling 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?

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

Example: Single Delegating Event

Obj Obj Obj Obj

Obj Obj Obj Obj

Obj Obj Obj Obj

Event

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

Tracking Events:

• Limited objects & simple handlers• Attachment

• Event Delegation Plan• Event Model API divorced from UI

• Many objects & multiple handlers• Event Delegation Plan

ApplicationApplicationPagePage

Looking Across the Spectrum

1. Tracking Events2. Memory Management3. Delivering JS and CSS4. Data Format5. Browser Support

Memory Management

Things can get out of hand.Things will get out of hand.

Goals:1) Don’t leak memory2) Keep overall footprint minimal3) Always-responsive, stable

interface

The Key Approach

1.DOM Destruction• Thoroughly Unhook and

Remove Handlers and References

• YUI Event provides lots for free

Two Approaches

1.DOM Preservation2.DOM Recycling

Memory Management Tip (1)

Monitor Usage

• Drip is a great tool on PC– MSDN: Understanding and Solving

Internet Explorer Leak Patterns– http://outofhanwell.com/ieleak/

index.php?title=Main_Page

Memory Management Tip (2)

Monitor Various Usage Cases1. Extreme object counts2. Long interactions3. Extensive navigation

Memory Management

• Preservation (based on use case)

• Destruction

• Destruction, but also...• Recycling (of iframes)

ApplicationApplicationPagePage

Looking Across the Spectrum

1. Tracking Events2. Memory Management3. Delivering JS and CSS4. Data Format5. Browser Support

General Best Practice:

Single large file is fastest

•Minimize HTTP requests– http://yuiblog.com/blog/

2006/11/28/performance-research-part-1/

•CSS near top•JS near </body>

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

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)

Another Approach (3)

Inline in the <head>

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

page.

• DNS lookups are costly• Extra domains are costly

71Yahoo! ConfidentialNate Koechley – natek@yahoo-inc.com

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.

ApplicationApplicationPagePage

Looking Across the Spectrum

1. Tracking Events2. Memory Management3. Delivering JS and CSS4. Data Format5. Browser Support

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

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

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.

76Yahoo! ConfidentialNate Koechley – natek@yahoo-inc.com

Data Format:

“JSON rocks”

JSON, DOM strings

“Some JSON, and more soon”“Be sure to recognize strengths of client and server”

ApplicationApplicationPagePage

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

Looking Across the Spectrum

1. Tracking Events2. Memory Management3. Delivering JS and CSS4. Data Format5. Browser Support

Binary Browser Support

•Do I need to support Browser Foo on this project?

Same as saying:Those users aren’t welcome.

Graded Browser Support

1.“Support” does not mean “Same”

same isn’t important

“Expecting identical experiences fails to embrace or acknowledge the heterogeneous essence of the Web.”

Graded Browser Support

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

The Web is about Availability

A graded approach welcomes everyone while bringing sanity to development and testing.

Browsers: The Dirty Truth

•The Web is the most hostile software engineering environment imaginable.

– Douglas Crockford

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

C-grade - core support, ~ 2%

A-grade - advanced support, ~ 96%

X-grade - the X-Factor, ~ 2%

Three Grades of Browser Support

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

90Yahoo! ConfidentialNate Koechley – natek@yahoo-inc.com

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.

ApplicationApplicationPagePage

Cheat Sheet:

1. Stay true to your beliefs2. Have an event plan3. Monitor memory and CPU4. Minimize HTTP requests5. Create state on server6. Have a sane browser support

plan

Bad decisions are tomorrow’s constraints.

Bad decisions are tomorrow’s constraints.

Good decisions are tomorrow’s opportunities.

Thank you.

We’re Hiring!

Josie Aguada: jaguada@yahoo-inc.com

Usual suspects:

JavaScript, PHP, CSS, HTML, ActionScript…

Thank you.

natek@yahoo-inc.comhttp://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/grimreaperwithalawnmower/1918

90428/– http://www.flickr.com/photos/jasonmichael/4126695/

nate@koechley.com

Questions?

i don’t know.

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?

top related