Linkability vs. Ajax
By greimer on Feb 17, 2006
How can I bookmark/index/catalog/map/associate something interesting if the page's contents were assembled on the fly with Ajax? Ajax is a cake that I really want to eat, with more benefits than just snappy UIs, but is there a way to implement it without breaking linkability? Before facing that conundrum directly, let's reduce the surface area of the problem as much as we can.
Why is Ajax so nice? More bang for bandwidth, snappy UIs, offloads processing to the client. Do any non-Ajax techniques address these things without compromising linkability? Yes. Clean, lean (X)HTML saves bandwidth and quickens things up. What else? Minding your server's last-updated response headers for GET requests reduces transfers and makes things snappier. If sluggish, bandwidth-hogging web apps are pushing us toward Ajax, then these things alleviate some of that pressure.
Trying a different angle of attack, when does Ajax not break linkability? Some use cases don't break linkability, for example a login function. If logging in happens seamlessly over Ajax, there's no inherent breakage between URL and content. So obviously there are plenty of Ajax uses that don't cause linkability problems.
So a significant chunk of the problem's surface area is whittled away, leaving the central problem: Ajax that fetches new resources onto the current page breaks linkability.
I don't think there's a single solution to the problem, but one thing that springs to mind is flip-flopping the container/content paradigm. Rather than Ajax loading a new content resource onto the existing page, a plain-old link-click loads the new content resource, and Ajax loads the container, i.e. navigation lists, company logo, etc., all of which are cached by the client.