Author: jeff

First Thoughts on AJAX

Okay, so I’m a bit behind the times. =)

The website I’ve been working on has a dynamically generated page that’s data-intensive and can take several seconds to load. I’ve been AJAX-ifying it so that the client browser immediately loads a skeleton page and then retrieves pieces of data as they become available on the server. Nothing extraordinary.

I’ve worked with XML before as well as a touch of Javascript here and there. The rest of the AJAX pieces took some researching but weren’t hard to learn: mostly it was a matter of seeing what the XMLHttpRequest object provides, getting a hang of the DOM for HTML, and looking up relevant CSS attributes. We (my boss has also been coding a bit) also use the prototype.js library, which extends the DOM to make it much easier to manipulate. We’re still working out kinks in how the UI should look, but it’s been surprisingly smooth so far.

What I like so far:

Needless to say, AJAX is very conducive to a clean separation between data and presentation. For me, this is a major advantage. Designing XML schemas forces one to think about what data should be provided, not how it looks. The server-side code stays clean, since it mostly just churns out data for delivery.

What I dislike so far:

Only two things really bug me so far. One is that exposing the data layer via HTTP calls can result in clients accessing that layer in ways you might not appreciate. This is a pretty common complaint about AJAX, but there are clever ways to deal with it.

The second is a more conceptual matter. The HTML document isn’t really a “document” anymore. This has been happening since before AJAX, so maybe I’m just being grumpy, but really, what your browser is getting is not a document, it’s an application!

At its inception, HTML was a format for simple page layout: “p” tags described a paragraph, a “table” tag meant rows and columns of data to be displayed. In mid-1990s, the commercial web horribly mangled HTML, making “p” tags meaningless, and forcing tables to do contortionist tricks for complex layout with graphics, which it was never intended to do. CSS has helped greatly to correct these abuses, but now AJAX is turning HTML into a sort of template language, with Javascript being in charge of interactivity.

Maybe there should be a new HTTP “Content-type” for AJAX applications. The identification would help with search engines and information accessibility, letting clients know that hey, this isn’t data you’re seeing, it’s an app. Surely, people more thoughtful than me have considered these issues already. I’ll have to look it up. Unless, that is, you can only access that material through a non-googleable AJAX interface. =)

In general, an AJAX architecture requires more human work to maintain: AJAX and non-AJAX versions of information with different presentation instances; more thoughtful design to keep the layers separate and maintainable, and to manage complexity; more testing for cross-browser, cross-platform compatibility. These are not “problems” per se, but definitely things to consider when embarking upon a site overhaul.

Up and Running

This domain is being served from a slicehost.com VPS account, which I’m sharing with my friend Danny. We spent a few hours installing a typical LAMP environment from Debian packages. It all went smoothly; we’re pretty much set up. Eventually, we’ll get around to putting actual content up on our respective domains, but we expect traffic and load to remain very light. So we spent most of our time dealing with the main resource limit on our “box”: memory.

There’s lots of information available on various optimizing strategies for Apache and MySQL, but it basically boiled down to 2 things for us. In Apache, we lowered the number of start/max/min servers, and loaded only modules we needed. In MySQL, we decreased the sizes of various buffers and queues, and also disabled InnoDB support. The latter alone changed the initial size of MySQL from 20 megs of resident memory to 9 megs! I’m sure we’ll continue to tweak later on, but memory usage seems fairly reasonable right now for what we’re running.

It’s funny to reflect on how far open source software has come in general. I remember talking nine years ago with some corporate guy in New York about a piece of open source he promptly dismissed as “not ready for the enterprise” (that phrase always makes me laugh. Whose enterprise, exactly? Mine?). Back then, it was common to hear disparaging stuff like that all the time.

And now–is there anything that’s NOT enterprise ready?! Maybe the suits are happy, but I’m not sure everyone else has benefitted. As the software has grown in scalability, performance, and features, the requirements have also increased drastically. And that means the bar is higher for even a fairly standard LAMP environment, for example. Default installs of Apache, MySQL and PHP can be real memory hogs.

I’ve been discovering a few interesting alternative projects with lighter feature sets. lighttpd and thttpd are both high-performance, small-foot web servers. And a lot of folks seem to be looking to SQLite if they don’t need the fancier features of a complex RDBMS. Maybe I will experiment with these at some point.