Why you should be using disambiguated URLs

2007-02-04T13:57:24+00:00

Good URLs are important. The best URLs are readable, reliable and hackable.

One of the nice things about Rails, Django and other modern Web frameworks is that most of them encourage smart URL design. Rails has relatively smart defaults and a powerful routing system for custom URLs; Django forces you to think about URL design up front by defining them as regular expressions. Many of the definitive "Web 2.0" sites such as Flickr and del.icio.us also use well designed URLs. This is a positive trend, and long may it continue.

There's one aspect of URL design that is often ignored. Good URLs should be unambiguous. By that, I mean that any logical piece of content should have one and only one definitive URL, with any alternatives acting as a permanent redirect.

This rule is frequently broken. Here are some examples:

My Flickr photo stream lives at www.flickr.com/photos/simon/ and flickr.com/photos/simon/
My del.icio.us account is at del.icio.us/simonw and del.icio.us/simonw/
The YDN Python Developer center lives at both http://developer.yahoo.com/python/ and http://developer.yahoo.com/python/index.html
The Google AdSense sign-in page is at https://www.google.com/adsense/ and https://google.com/adsense/. If you visit the latter you get a scary certificate warning (they really need to fix that).

In each of the above cases, it's obvious to regular people that the URLs are the same. Unfortunately, from a technical point of view they are different and could quite feasibly serve up different content. This causes all kinds of problems:

Caches (both browser and intermediate proxies) can't improve performance if you request the same content from a different URL.
Browser can't show users their visited links.
Social link sharing sites such as del.icio.us can't accurately aggregate links to the same resource.

That last one in particular should catch your attention if you care about effectively promoting your site. Here's a random example, plucked from today's del.icio.us popular. convinceme.net is a new online debating site (tag clouds, gradient fills, rounded corners). It's listed in del.icio.us a total of four times!

http://www.convinceme.net/ has 36 saves
http://www.convinceme.net/index.php has 148 saves
http://convinceme.net/ has 211 saves
http://convinceme.net/index.php has 38 saves

Combined that's 433 saves; much more impressive, and more likely to end up at the top of a social sharing sites.

Here's a useful rule of thumb:

Links to (and within) your site should never, ever end with index.php / index.html / default.aspx / any default directory index filename.

The whole point those defaults is that you can link to the containing directory to see their content, resulting in a shorter and prettier URL. If you're linking to them directly you're missing out on a golden opportunity to disambiguate your URLs.

Disambiguating your URLs isn't particularly difficult. The no-www site offers tips on having one domain name redirect to the other, and there are various mod_rewrite techniques for achieving the desired effect as well. If mod_rewrite makes your hair stand on end, remember that if you are using a server-side scripting language such as PHP you can implement rewriting logic in your application code by examining the $_ENV['PATH_INFO'] variable or your platform's equivalent.

Django sites get this behaviour for free, thanks to some default settings and Django's CommonMiddleware. You can that in action on this weblog: try here, here and here.

Tags: delicious, django, flickr, rants, urls

Fjax: Just say no

2006-06-25T15:03:53+00:00

To my utter amazement, a decent amount of buzz appears to be building around a new "technology" called Fjax - much of it centred around this interview on Webmonkey, but also benefiting from a mention on the O'Reilly Radar and of course the obligatory Digg story.

Here's the catch: Fjax solves a non-existent problem. Here's the description from the site:

Fjax is the lightweight, cross-browser, rapid-development methodology for Ajax-style web 2.0 development that puts a Flash engine under the hood (not in the presentation layer - read on) to handle realtime XML/HTML content updating.

Fjax enables web 2.0 development, with true, asynchronous (x)HTML content updating without page refreshes. The trick is, it does it with less than 65 lines of code and works in most browsers. It can process multiple streams of data simultaneously, and has an incredibly small footprint (4K!).

So what does it actually do? It offers a replacement for the native browser XMLHttpRequest object that is slower, less fully-featured and does a bunch of crazy extra work behind the scenes. Ajax requests are instead made through an invisible Flash file that uses Flash to load the data, parse the XML, extract some CDATA and pass it back to JavaScript to replace a div.

Kind of like Prototype's Ajax.Updater then.

Why would you do this? According to the authors, doing this with JavaScript requires painful code forking. It certainly does if you write JavaScript like they do:


if (document.all) {
  //isIE
  document.all[ThisOutputDivID].innerHTML = objFjax;
} else {
  //isNotIE
  document.getElementById(ThisOutputDivID).innerHTML = objFjax;
}

(The document.all workaround is only needed by IE 4 - every subsequent IE version has supported document.getElementById, part of the DOM specification.)

They also claim that using Flash to load and parse XML is substantially faster than the native alternative:

And of course, this stuff is SPEEDY. Vastly reduced code, crazy fast parsing & delivery, quick load/unload, and multiple simultaneous data streams means your final applications have some serious pep.

They haven't done any benchmarks and I haven't either - but I would be amazed if this claim held up. Simply sending data between Flash and JavaScript is notoriously slow (see Brad Neuberg's writeup) and I've heard bad thing's about Flash's XML parsing speed too. Not that they are really using any of the capabilities of XML - the actual data used to update the page is handed back in one big CDATA block.

The executive summary builds its case on the idea that JavaScript is inconsistent, buggy and slow to develop. Bizarrely, making simple XMLHttpRequest calls (of the kind that Fjax is meant to replace) is one of the few parts of modern JavaScript for which that isn't true. The following is all the browser-forking code you need to cover every available major browser.

function createXMLHttpRequest() {
  if (typeof XMLHttpRequest != 'undefined') {
    return new XMLHttpRequest();
  }
  try {
    return new ActiveXObject("Msxml2.XMLHTTP");
  } catch (e) {
    try {
      return new ActiveXObject("Microsoft.XMLHTTP");
    } catch (e) { }
  }
  return false;
}

They boast that Fjax uses only 65 lines of JavaScript (plus 4KB of Flash). The equivalent functionality in pure JavaScript, including the above browser workaround, runs to less than half of that:

function ajaxUpdate(url, id) {
  var xmlhttp = createXMLHttpRequest();
  if (xmlhttp) {
    xmlhttp.onreadystatechange = function() {
      if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
        document.getElementById(id).innerHTML = xmlhttp.responseText;
      }
    }
    xmlhttp.open("GET", url, true);
    xmlhttp.send(null);
  }
}

Another quote:

Using a Flash engine for XML parsing and (x)HTML content delivery reduces approximately 90% of the redundant cross-browser-supporting XML-related code usually associated with standard Ajax development. That in itself is HUGE.

That 90% looks like a rectal approximation to me.

In its present form, Fjax offers absolutely nothing of value to front end developers. Even the idea of using invisible Flash components to make new functionality available to JavaScript isn't a new one - dojo.storage takes advantage of Flash's ability to store large amounts of data in an offline cache, while FlashXMLHttpRequest makes cross-domain HTTP requests possible. There's a lot to be said for using Flash in this way (I'd love to see someone make the Flash accessibility APIs available to JavaScript), but Fjax is not a useful demonstration.

I'm not normally given to debunking crazy technology ideas - mainly because there are so many out there that it would be a full-time job - but this thing is so obviously broken I thought it best to try and nip it in the bud.

One last thing: their technique doesn't work in either Opera 9/Mac or Konqueror, both of which support vanilla Ajax just fine.

Update: Steve McDonald, one of the Fjax authors, has posted a follow-up comment on the O'Reilly Radar entry. He argues that the getVariable API they are using avoids the performance issues communicating between Flash and JavaScript (I have not verified this) and points out that code-forking for XML parsing is more likely with complex documents (that's why I like JSON). They have removed the 90% claim from the site.

Tags: fjax, flash, javascript, rants

Simon Willison's Weblog: rants

Why you should be using disambiguated URLs

Fjax: Just say no