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

a short historical story…

1994

1995

Source: Comscore, Feb. 2006

mm users /month 5.2billion hits /month Source: Comscore, Feb. 2006

Video:

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 unknowns 3.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’s Law 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:

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

Video: Video:

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

Video:

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.Interactivity 2.Performance

“Law 3: Savings in time feel like simplicity.” -- John Maeda The 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.Interactivity 2.Performance 3.Soundness

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

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

to Applications from Documents & 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

ApplicationPage

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

Looking Across the Spectrum 1.Tracking Events 2.Memory Management 3.Delivering JS and CSS 4.Data Format 5.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?

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

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

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

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

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

Two Approaches 1.DOM Preservation 2.DOM Recycling

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 – itle=Main_Pagehttp://outofhanwell.com/ieleak/index.php?t itle=Main_Page

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

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

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

General Best Practice: Single large file is fastest Minimize HTTP requests – erformance-research-part-1/ erformance-research-part-1/ CSS near top JS near

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 Caching doesn’t always work. –In particular: browser’s home page. DNS lookups are costly Extra domains are costly

Yahoo! Confidential Nate Koechley – 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

Looking Across the Spectrum 1.Tracking Events 2.Memory Management 3.Delivering JS and CSS 4.Data Format 5.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 –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.

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

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

Looking Across the Spectrum 1.Tracking Events 2.Memory Management 3.Delivering JS and CSS 4.Data Format 5.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

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

Yahoo! Confidential Nate Koechley – 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

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

Bad decisions are tomorrow’s constraints.

Good decisions are tomorrow’s opportunities.

Thank you.

We’re Hiring! Josie Aguada: Usual suspects: JavaScript, PHP, CSS, HTML, ActionScript…

Thank you Photo Credits: – – –

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.

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