Or, Why XBLinJS Claims AJAX Support Without Much Of A Framework

What is AJAX, really? AJAX is all based on XMLHttpRequest. XMLHttpRequest is essentially just the same old web-page framework, except the connection between retrieving a new page and displaying a new page is severed. In particular, it is not a generic socket connection.

AJAX is, in essense, very simple. A fully useful form of it is expressed in the following psuedo-code:

var request = getRequest(); // get some sort of XMLHttpRequest
request.open("GET", someURL, 1);
request.onload = function () {
  eval(request.responseText);
}
request.send("");

That's it, minus some platform differences.

From this, you can build frameworks, varying in power from simple connections to frameworks that promise the ability to write server-side code and have it automatically translated to client-side code. Let me show you some of the various frameworks I've seen, used, or can conceive of, though this is not intended to be a complete list by any means:

By far the fanciest are the frameworks that try to bundle everything onto the server side. You write code on the server side, perhaps use a form editor like Visual Basic's to specify widgets, and the framework generates HTML and widgets to send down to the user. Every event handler uses an XMLHttpRequest to go back up to the server, and you never even have to write any Javascript, potentially.

While powerful, this framework is very difficult to implement at all, and even more difficult to make it performant or featureful. Suppose you want to add history retrieval to a text field, like the Javascript Console widget has. That involves tapping into every single keypress, and even on completely local network you are pushing the limits of what humans will tolerate as response time.

It is also easy to cause 'event flurries' if the user does something wierd (goodness help you if you try to catch mouseover events while the user is moving around), and it is tempting to end up with solutions that send way too much data down to the client to be cached to get around the weaknesses.

If you try to dynamically build interfaces, you can run into horrible performance with server-client recursion, such that you'd never even use this idea in practice.

You are eventually forced into a hybrid approach with one of these other approaches, which ultimately probably simplifies the implementation but complexifies the mental model.

This model is extremely powerful and easy within its domain; no other model can even pretend to be useful to a non-web programmer who doesn't want to touch Javascript. But it is also, ultimately, the most constraining as well; trying to jump outside of the domain of this sort of framework, which largely seems limited to forms-based editing approaches, is effectively impossible without incurring horrific performance penalties or having to write a lot of client-side code. There are advantages to trying to put everything on the server side, but serious penalties as well.

In contrast to the previous framework idea, this one simply lives with the fact that the logic is going to have to be split between the client and the server intelligently. As code or data is needed on the client, the client pro-actively retrieves it.

An example is the hierachial selection dropdowns you often see on the web. For instance, suppose you want to refer to your car for some reason, perhaps a quote, perhaps a parts query, etc. Since simply dumping every model, make, and year of car ever made is impractical for multiple distinct reasons, you will often be presented first with a list of manufacturors. When you select, the page submits the form and you get a new page where you can select models, and so on down the line until you've specified your car. A simple data retrieval can cut down the re-rendering and significantly speed things up.

There are a variety of ways to wrap a framework around this idea; one easy way is to create some sort of interface for exposing the server-side objects, and creating a relatively uniform way of downloading and using the data portion of those objects.

For simple tasks, this works great. But one of the problems with this in practice, especially if you are an Object Oriented sort of programmer, is that in advanced cases, you end up wanting not just the data, but the behaviour, and you end up with a lot of concept duplication if you implement the behavior on the client side. You often find yourself wanting to effectively grab a class instance from the server and manipulate it on the client-side, which very frequently entails duplicating things the server-client can do. You can often get by with minimizing what the client-side object can do, but the client-side object will still end up trending towards a complete re-implementation of the server object.

You can try to hook up the client-side object to the server-side object like the previous framework, but you hit all the same problems as that has (especially if you want to call lots and lots of methods), plus the new problem of the potential for the client-side object to get out of sync with the server side object.

I have written this a couple of times myself. It is powerful and flexible, but even given a clever framework, extracting maximal benefit from it for the minimal cost can take a very experienced developer. It tends to become a time sink as you either under-implement object behavior on the client-side and suffer from the general problems caused by non-OO programming (trending towards spaghetti code), or you waste time over-implementing the behavior on the server side and also spending time debugging sync issues. You also still can not have the server initiate anything without a client request.

If the inability for the server to initiate anything is a problem, you could use XMLHttpRequest as a behind-the-scenes polling mechanism. While this is probably not appropriate to roll out to the general public due to the load it can produce, the load can be managed and this can be a useful system.

I have written this once; it is used in an event-based model where all kinds of events can come into a central server, which updates its own data structures, and then web clients can consume those updates within some polling interval, making it appear as if the server is pushing events down to the client, even without a persistent connection.

This is powerful, but it tends to require a very different approach to programming that is only a clear winner in rather constrained circumstances. If you have a pre-existing messaging platform you can tap into, this might be relatively easy, but rolling your own can be tricky. And as mentioned above, this is probably completely unsuitable for wide-scale deployment.

Orthogonal to the rest I've named, there's the idea of building a framework for AJAX by strongly constraining what the client-side can do, which most frameworks I've seen go with. Sure, it's great, as long as your needs do not leave the constraints, but trying to do something not provided for may be significantly harder than even rolling it yourself.

Each of those frameworks has a time and a place where they will shine. And while you can't combine all of them at once reasonably, you can hybridize them to some degree.

Still, you can't use all of these together; even were you to create one framework that had them all the complexity and bloat would be quite significant. A Push framework does no good in the car selection instance, only causes waste. And correspondingly, in a strongly event-based system it is usually possible to design the system to recieve all of its requisite data from the event stream, with no need to explicitly initiate extra XMLHttpRequests as the server-side systems do.

XBLinJS does not ship with a strong AJAX framework because it is not possible to optimize for all of these uses at once. Moreover, due to the diversity of techniques available and desirable even within the broad categories described above, it is probably still not possible to optimize an XBLinJS framework usefully for any given user.

However, from my own experience I know that the library as-is is definately useful in many of those scenarios; the only one I haven't tried is the first, and it is easy to imagine making that work as well.

Therefore, while JObjects do have a remoteExecution function, which is in some sense enough to check of an "AJAX support" bullet point without it being a lie, that is intended to be more a building block than a finished framework. Should you create such a framework, I'd love to hear about it. If you want to integrate XBLinJS into an existing framework, I'd love to help you any way you might need, though I may not be able to help in the code much.