Here’s my quick view on the two strategies:

In the words of Agent Jay:

Old and busted: pages and technologies that work for older browsers

New hotness: think AJAX

Both strategies have the same end goal: provide support for the widest variety of user agents, but have opposite approaches of doing so.

More reading

This is a quick high level overview, so read below for more information and examples:

• Accessites.org goes more in depth
• Yahoo developer articles

Scope chain pain

If you’re like me and use a lot of framework singletons, such as the popular YAHOO.util.Dom, there’s something you can do so speed things up.

Every time you use a global variable, the browser has to work its way up the scope chain until it reaches the global scope. By giving all those pesky global vars a local reference, you can significantly lower the time it takes to find that variable.

Remember, JavaScript code is executed on the end-user’s computer, so writing efficient code should always be the #1 priority. Here’s an example with using YUI core components which are accessed frequently:

(function() {

var lang     = YAHOO.lang,
    dom      = YAHOO.util.Dom,
    event    = YAHOO.util.Event;

var newObject = function() {
  // 'lang' is much faster to lookup than 'YAHOO.lang' and so on...
  alert(lang.JSON.stringify({"key" : "value"}));
};

})();

By writing your code within a self-executing function, variables lang, dom, and event are only local to that function and everything inside of it. So, lookups to such frequent tools like YAHOO.util.Dom are much faster.

DOM caching

Similarly, lowering the times you access the DOM improves the performance as well, most of the times drastically.

So if you have something along the lines of this (but hopefully more profound):

for (var i=0; i<100; i++) {
  document.getElementById('el').innerHTML = i;
}

Do this:

var el = document.getElementById('el');
for (var i=0; i<100; i++) {
  el.innerHTML = i;
}

In other words, only do one DOM lookup per element and save the reference to a variable.

That’s it. Happy coding.

... at least according to the TIOBE index, which measures language popularity based on the number of web searches:

The ratings are calculated by counting hits of the most popular search engines. The search query that is used is +”<language> programming” The search query is executed for the regular Google, Google Blogs, MSN, Yahoo!, and YouTube web search for the last 12 months. The web site Alexa.com has been used to determine the most popular search engines.

Observations

• PHP moves up one spot from last year into #4 and still dominates the web languages
• ActionScript enters top 20 (as #20) and I expect it to grow even more in the coming years
• Java dominates with 20% market share and sits comfortably at the #1 spot
• Pascal enters top 20 as well at #15, jumping up eight spots in one year! This one I’m just confused about, but I do miss the language
• JavaScript and Ruby are #9 and #10 respectively, though over last 4 years, Ruby has risen tremendously (#27 in 2004) with the help of Ruby on Rails

View the rest

First and foremost, I love a lot of what Google has to offer, particularly Gmail and Reader.

Recently, Google released a new Gmail version to the world with many wonderful upgrades. One thing however, left me scratching my head. I noticed they replaced a regular old HTML <select> tag with a smaller drop-down widget.

Apart from the apparent visual improvement, it doesn’t seem to be all that better and innovative to me. In fact, I’d imagine it suffers a bit as far as accessibility goes.

Growing pains

Being a daily Reader user, I also noted that their drop-downs are pretty custom as well. What’s interesting, is that they have a completely different look from Gmail’s.

I dug deeper and found that drop-downs across most of Google’s web apps did not look much alike. In fact, sometimes there was more than one look within the same app!

These inconsistencies are most likely attributed to Google’s exceptional growth. It’s huge now and all big companies have the same struggles. Yahoo is no different and I see this first hand almost everyday at work.

Plenty of examples

Another one from Gmail

Analytics – my favorite

Calendar

Docs

Groups

Picasa

Reader

Conclusion

Google has done a pretty good job keeping the main look similar from from one app to another. What’s more important, their services are pretty good and are actually helpful.

Still, they need to work out and implement various design patterns for specific controls that appear on multiple apps. The latter part is the hardest of course, but Google can do it, can’t they?

I know I do

Yesterday afternoon, Yahoo! released a nice little tool built on top of Firebug called YSlow (Firefox only). In Yahoo!’s own words:

YSlow measures web page performance based on the best practices evangelized by Yahoo!’s Exceptional Performance team. Since many of these best practices focus on the frontend, YSlow is integrated with Joe Hewitt’s Firebug, the web development tool of choice for frontend developers. »

I test drove the tool this morning and apart from the fact that I got an embarrassing and pitiful F for Youtilize, I still really like YSlow.

YSlow follows YDN’s Exceptional Performance guide for its performance test, which is definitely a great guide to follow. One thing to keep in mind though is that one solution doesn’t fit all, so don’t take the test results too closely to heart.

For example, while I agree I need to minimize my HTTP requests, I don’t think this blog will benefit greatly from using a Content Delivery Network. Other blogs may, but not me. At least not yet

Summary

Use this tool to see if there’s anything you can do to optimize your website, but don’t go crazy over every negative result.

Also, YSlow is a plugin for a Firefox plugin? Weird.