The following are my panel notes from @media2006. As I am not the fastest typer I have paraphrased what was said. Should you notice any mistakes please do point them out in the comments for corrections.
Y! v. Y!
Three Yahoo! Case Studies, Across the Page - App spectrum, One Size Does Not Fit All.
Nate Koechley
It's proniounced Kek'lee
Nate Koechley
At yahoo since 2001
Charter memeber of the web dev team
On Yahoo User interface library team
Three roles:
Senior Frontend Engineer
Technical Evangelist
Design Liason
The YUI library:
It expects users to be proficient with javascript. There's a significant amount of implementation. We take care of some of the lower level stuff.
It's completely A la carte you can take what you need there are no dependencies. Event utility is 2k the DOM utility is 3k
Utilities vs, controls + CSS (inc reset default styles)
There's no shortage of better things to spend your time on.
Extensive docs and support. Mailing lists etc.
These are the same files that yahoo themselves are using.
The DHTML Universe a diagram by Dojo's alex russell showing code and the people that wrote them. Alot of these people are at yahoo. Praise them blame me.
A quick history.
1994 this was yahoo (slide of screenshot of yahoo in 1994) Comprising lists and links no tables. no Exclamation
1995 introduction of graphics. not many changes
1997 more services, first ad
2000 not much changed, conservative
2002 More content but still the same. I joined then and started a holy war against font tags.
2004 More graphics
Today 188m users 5.8billion page views.
Preview of new version.
dynamic content, draggable maps, event info.
it is immensely telling that the new Yahoo! homepage is a DHTML homepage.
Web 2.0 is getting it right the second time. Buzzwords aside it's a chance to re-focus.
New yahoo! photos, mail etc
Yahoo homepage
History
new homepage developed from scratch
released one month ago today.
Newest development effort
Yahoo Photos
Beta released 8 days ago.
from scatch
long dev timeline
300 million unique users
2 billion photos
major DHTML and ajax implementation
Fetures video:
edit in place. Full marquee selection of photos. Desktop shortcuts carried over from the desktop.
Yahoo Mail:
Still in beta released one year ago
legacyish was oddpost.com
Features:
preview in place
tabs
autocompletion
Easter egg for humorous subjects if you can't think of one. Tap the subject button.
Don't worry not a product pitch
Common goals:
- perforamance, percieved performance. javascript overhead loading in a different thread. Is the behaviour availalble when I need it.
- Interactivity. Keyboard shortcuts.
- Stay true ot our beliefs. Sometimes at odds with the other two. In the rush this can get called into question.
The basic:
Doctype:
Yahoo! uses HTML 4.01 strict
Yahoo! photos uses XHTML
Yahoo MAil none
Render mode strict except for mail which is in quirks
CSS sprites throughout
Font size resposive except mail.
Keyboard functionality across the board
Abs positioning NO all
minimisation yes across the board
... (best see the slides!)
Page to Application spectrum
Mail is an applcation.
Yahoo is a page.
Photos sits in the middle of being page driven as well as an app.
TRacking Events:
moving from page granular to event granular interfaces.
More event driven things, handlers and interaction.
Don't piss off DOM scripting taskforce. No JS in attribute space /markup
Watch out for memory leaks.
Many great utilities. Many objects and events. Browsers die when too many, objects and listeners. Objects can have many events. Drags, keypress, double clicks etc etc.
multiply by countless number of object you will quickly hit the ceiling.
Event delegation. no events on the objects them selves. This take actions on the document and interprets them and passes them the the right object
As your object count goes up and you handlers you will need event delegation.
Don't leak memory, keep memory footprint small.
If you create elements unhook, remove handlers and remeove references. Destroy!
Conservation, we never throw anything away. Once created we don't gert rid of it to save the cost of rebuilding. This is uses on teh Y homepage. In photos we used destruction. In mail we deswtruct but we also recycle iframes. There's an overhead to keep creating iFrames. Starts with 18 iFRames when we are done we clear it out using about:blank and then it's ready for re-use.
Measure and Test
Drip is a great tool (win only?) memory profiler.
Test extreme object counts
test long interactions. Memory usage can accumulate greatly over time.
test extensive navigation. When you leave a page you may not reclaim the memory used. So test coming and going to check for memeory issues.
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 teh top as possible. JS files as close to the closing body tag as possible. Once javascript is being downloaded the system will be locked and nothing else will be downloaded until the js is fully downloaded.
Other approaches.
-
Many small files at once. Enables atomic/team development enables partial caching if parts change.
this alloows tuning in reposnse to use cases and task analysis. -
Many small files on demand. Files are only downloaded as needed.
-
inline in the head. Caching is not as effective as we imagine. Even with all of the tuning we do 30% of our audience has an empty cache when they visit. This is especially true of the home page. In IE if you do Ctrl+N IE won't touch the cache in loading the homepage. Counter-intuitive but the data didn't lie.
Data Format
we use JSON for data interchange. Natively understood and available. "The fat-free alternative to XML"
http://www.json.org
tools in every known programming language (toungue in cheek). 60 languages.
Somebody is going to pay the cpu price to render the view.
Server of client side. Consider client and server in tandem when making architectural choices.
Faster to pass a string that expresses a DOM state directoy than trying to parse and create on the fly.
Parsing XML degrades performance great than linearly as size of xml increases.
Yahoo : JSONrocks
photos wants to move to JSOn
mail uses some but wants more usage.
Ajax: Could does not equal should.
Pagination: Yahoo single page so N/A, photos heavy objects with ajax pagination no refresh but new collection. Mail light objects endless scrolling and clever caching.
Browser support
We use the graded browser have been for years internally now sharing that publically. Support does not mean "the same". Not identical experiences. Support should not be binary. We support everyone, you will just get a different experience.
3 grades of browser support
C-grade support NN4 core support
A-grade support advanced support (all modern browsers). Interaction should work. Good array of browsers.
X-grade support everyone else.
Browser stats. More IE 5.0 thatn 5.5 we consider 5 C-grade. Note by-country skews. note by content skews. IE7 already moved the needle.
Browser as a development environment. use most standards compliant browser first and least last.
The price is always higher to say no to safari and opera. Took flak because the beta didn't support safari. Apple called while I was in bed.
We're in this for the long haul.
Quality is our job be belligerent.
Today's bad descisions will be tomorrow's constraints.