Friday Feb 17, 2006

Linkability vs. Ajax

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.

Monday Feb 06, 2006

AJAX: What's the best tool for the job?

Choices, choices, choices. Is it better to pull XML from the server and manipulate it via DOM/XSL? Is it better to use JSON to convert data directly to JavaScript variables? Is it better to pull text in as tag soup, spackling it into place via innerHTML? Or is it better to use CSV and string.split()? There are no hard and fast rules, so I'll just convey some of my thoughts and experiences.

XML: An issue here is choosing what XML language to use. The XML language that sprang readily to my mind was, of course, XHTML. There are some pretty good reasons to use XHTML for something like this, plus rolling your own XML language might not be such a good idea. But mainly it provides options. With minimal fuss I can use DOM to drop elements from the X(HT)ML right onto the page, or I can be agnostic about things and treat it like XML; reading out data from it and transforming it as necessary. I just make sure my XHTML sticks to reasonable structure conventions. XHTML also has built-in metadata capability, a well-understood syntax, and, as of recently, microformats. All of this is gravy for me, the programmer. With this technique, there are some things to remember: first, an XHTML "mini-document" needs to be well-formed or the parser will reject it; second, the mini-document needs to use the XHTML namespace as the default namespace or the client may not treat it as XHTML.

JSON: Render unto Caesar that which is Caesar's. Thus, in my mind, XHTML is the best data format, and JSON is the best way to import dynamic behavior. Traditional JavaScript files can get huge, and given the direction things are headed, this problem will only get worse. Why not have a minimal JavaScript file, and from there load only the functionality you need, as needed? What this entails is, instead of using JSON notation like this: var foo = {"bar":"baz"}, use notation like this: var foo = {"bar":function(){/\* do stuff \*/}}. It also might make sense to implement some design patterns on top of this, for example the command pattern or some kind of inversion of control pattern. The possibilities are endless.

TAG SOUP: I'm going to resist busting on this method too much because there's always a situation where a given method is the best tool for the job. I'll just say this: importing text as tag soup and then shoveling strings into innerHTML with JavaScript is not my preferred way to do AJAX. I guess I just tend to like either pure XML or no XML at all, (but don't hold me to that!).

CSV: Sometimes the sledgehammer approach is the best approach. CSV has advantages: the syntax is compact, simple, easy to understand, easy to consume, easy to generate. For transmitting mass quantities of simple, tabular data, CSV is hard to beat.


My name is Greg Reimer and I'm a web technologist for the Sun.COM web design team.


« July 2016