Yahoo! vs. Yahoo! Three Large-Scale Mainstream DHTML Implementations
description
Transcript of Yahoo! vs. Yahoo! Three Large-Scale Mainstream DHTML Implementations
Yahoo! vs. Yahoo!Three Large-Scale Mainstream
DHTML Implementations
Nate [email protected] • [email protected] • 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 – [email protected]
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 – [email protected]
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 – [email protected]
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: [email protected]
Usual suspects:
JavaScript, PHP, CSS, HTML, ActionScript…
Thank you.
[email protected]://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/
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?