Category Archives: ajax

SWFObject now available on Google AJAX Libraries API

Posted on by

I’m happy to announce that SWFObject (version 2 of course) is available from the Google AJAX Libraries API.

What does this mean to you, the average user of SWFObject? It means you no longer need to place a copy of the SWFObject script on your own web server, and can instead link to the copy hosted on Google’s servers.

If you are unfamiliar with the AJAX Library API, you can find more information on the Google code site, or continue reading below for some simple examples to get you up and running quickly. SWFObject may not be in the docs on the AJAX Libraries API site yet because it was just added recently, but the team is working on the updated docs now, so check back later if you don’t see the SWFObject specific information.

Now for the business: I imagine that most SWFObject users most likely only use SWFObject and none of the other libraries hosted on the AJAX Libraries site. So here’s a direct link to SWFObject v2.1 that you can simply place on your site, and that’s it:

http://ajax.googleapis.com/ajax/libs/swfobject/2.1/swfobject.js

Yep, that’s it. Just replace the path to your local copy of swfobject.js with this one and you are done.

Another option is to use the google.load call which is documented here.

Flash vs. Ajax

Posted on by

I’ve been hearing a lot of Flash vs. Ajax arguments lately, and unfortunately, they almost always start off in the wrong way.

It’s very common to hear people argue about Flash websites or RIAs vs. Ajax websites or RIAs, but this is always the wrong way to approach building any website. Would you have an argument with an architect about whether to build a house out of wood vs concrete? Of course not, they would use each material to build the parts of the house that the respective material is best for. Sometimes you might want to build a shack or barn out of all wood, sometimes you might want to build an all brick house, but many times you’ll want to use the best material for each section of the house. Build the foundation out of concrete, the walls and roof out of wood.

Websites and web applications should be treated the same way. Break things down to a component level and go from there. Use the right tool for each component. If you can do it well with HTML/Javascript, go for it. If it would work out better with Flash, then why waste time recreating something with Javascript that you could build 3 times faster with Flash? There are plenty of great examples of this today around the internet:

One of my favorite examples is Google Finance. They use HTML and Javascript for the stuff that is best suited for that, and then when they need to show a nice graph, they drop in a great interactive Flash graph and talk to it using Javascript as needed. The Flash controls the Javascript, and the Javascript can control the Flash as needed.

Another example is Flickr. They started out using Flash to display all of the images, including the image notes and the other toolbar options along with each image. While this might have been a good choice as the site started out, it was soon replaced by a more efficient HTML version of the toolbar and notes system that works just as well as the Flash version. They did end up keeping one small bit of Flash so users can rotate images and see a preview before they save it.

So the next time you start planning a website and you start thinking: “Hmm, Flash or Ajax?” Instead of looking at it from a site-wide perspective, try thinking about your site as a series of components, and then choose Flash or HTML/Javascript for each individual component instead.