design your software—please!

I’ve been working with some other (non-Prototype) Ajax toolkits recently at work, and I feel the need to vent. It really hasn’t been fun. But it has been useful—it’s served as a powerful reminder to me about the importance of logical design. Sometimes we get so spoiled with our tools that we forget how truly bad the rest of the world is.

Design is the Difference

When [insert item here] feels properly designed, instead of feeling as if it grew like weeds in the moldering corpse of dead ideals, it’s better. It leads to a happier overall experience. You can feel the difference… it’s a tangible thing. It’s possible that you may not be able to identify the feeling of why you really like [insert item here] but you know you like it much better than the other choices. That’s what leads to holy wars about operating systems, text editors, languages, and, yes, frameworks (asbestos underwear, anyone?). The differences may not be easily quantifiable, but they’re there.

That’s why I choose OS X over Windows, BSDs over Linux, Ruby over PHP (where possible), and Protoype over SAJAX and JPSpan.

        <span id="more-4466"></span>

The Ajax Frameworks That Weren’t

Prototype is designed. SAJAX and JPSpan are also designed, in the sense that someone came up with an intention and turned that intention into software. But it feels as if there was no consideration as to what, exactly, the purpose of the software is. Lots of open source software is that way, because the geeks behind it don’t stop to question why? they merely focus on achieving the end result. It’s scratch-an-itch programming.

On the other hand, Prototype is definitely “opinionated software,” and it was created by a guy who really thought about what a programmer would want to do with Ajax. It also doesn’t try to be a framework.

SAJAX

SAJAX supposedly stands for Simple AJAX—which is true, in terms of lines of code, but not in terms of how you use it. Not only does SAJAX offer only two ridiculously simple examples and zero documentation besides, its pattern of use dictates that it be inextricably embedded in any application. Here’s the basic procedure of how to use SAJAX:

1. To make anything happen, you have to have one or more PHP functions which do the task at hand. Let’s call this method serversidemeth().
2. You then have to register your PHP function with the SAJAX framework using a binding method.
3. Then you have to write a Javascript function (we’ll call it clickme()) which will do things for you such as get a value from a form field and then call the Javascript function x_serversidemeth() with any data the PHP method takes, and another Javascript function to update the page as the callback method.
4. Then, you have to take your form, link, or whatever you want to Ajax up, and make it call clickme() when it’s clicked, or submitted, or whatever.

So for even the simplest example which echoes a line of text submitted in a form, you have to write a bunch of custom functions just to make it work at all. And you have to know Javascript.

Worse, if your business logic—the code you use now to do whatever it is that the code does normally without Ajax—isn’t encapsulated into its own special function, you’re SOL. Oh, and it conveniently assumes that you always want the Ajax request to be sent, via GET or POST, to the same file as the Javascript you wrote.

See the pitiful examples. Worse yet, view how many lines of code it takes to make them work.

JPSpan

Now, JPSpan tries to be an actual framework. It has far too many files and yet even for something simple you must BYOJ (Bring Your Own Javascript). It just defies belief. All it does is ferry the data back and forth for you and you still can’t (easily? at all? I can’t tell because there aren’t any docs) specify where, exactly, the request is made to. It’s still up to you to do everything on the client-side except writing the code that generates the nuts and bolts of the Ajax request itself. Half the examples online don’t even work at all, and the rest are just hideous.

I had to find a problem in the many, many lines of code. It took forever. JPSpan now occupies a very special part of my heart—the dark, withered part that IT KILLED.

But what killed JPSpan? Delusions of grandeur. Pretension so thick you could cut it with a spoon. Hey, we’re creating a framework! A framework! We’re big and bad (and so is our code)!

Again, the pitiful examples. And the horrible, horrible code.

The Good Software Design Award

Prototype, on the other hand, does what most people actually need and want: it makes life simple. A single line of Javascript will make your form submit via Ajax if Javascript’s available and hey, if it worked before Prototype, it’ll work even if your users have no Javascript. You can tell it to use any URL you’d like for the request, so if you’re using PHP (and if you were considering SAJAX or JPSpan, you’re using PHP) you can fit it into your current system with no additional work.

Here’s how you craft a simple Ajaxed link with Prototype:

<!-- basic link -->
<h2>ajax replacing link</h2>
<a href="backend.php?return=time"
   onclick="new Ajax.Updater('testdiv', 'backend.php?return=time',
   {asynchronous:true, evalScripts:true }); return false;">
This link updates a line</a>
<div id="testdiv"></div>

You don’t have to write any more Javascript than the example for the link—you don’t really need to learn how to code Javascript in general, just how to use the Prototype syntax. Whatever the result of backend.php?return=time, it’ll be displayed in the testdiv div. If it’s Javascript you get back, the Javascript will be run.

And on the back-end side of things, you only need one line of code to tell whether or not your code is responding to an Ajax request instead of a regular one. You can look for the HTTP header:

$ajax = ($_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest' ? true : false);

So it takes very little effort to change your web app to return just the relevant HTML or Javascript instead of the whole page with sidebar, headers, and whatnot. Then, voila. Ajax or not, your app works the same way.

Prototype gets the job done, and it puts all the work where it belongs: in the Javascript, not in the server-side scripting language. It may have a learning curve, but it’s sure as hell the best of breed. Better yet, it’s got a distinct pattern to its usage so you can easily write a wrapper class to take all the repetitive Javascript out of the equation. And you know whenever you need to change the way your Ajax works, it’ll all be in the same place.

If you’re interested in Prototype, don’t forget to check out Scriptaculous, an equally well-designed package built on top of Prototype to provide fun goodies like drag & drop, edit in place, and lots of pretty effects.