There are many different architectural ways of approaching the client/server paradigm as it applies to Ajax. Mostly you can pare these differences down to two major camps:

A. Rich client/data server
B. Thin client/app server

What, you say? A rich client isn’t an HTML browser? Well, let me remind you that many of the bigger, badder Web apps out there, particularly in the enterprise world, do a huge amount of the heavy lifting in the browser directly via DHTML, Javascript, Java applets, Flash, ActiveX, and so forth. The server is more there just to serve files and data, at least some of the time. In terms of lightweight Ajax-oriented development, this might still be true where the server just sends some JSON or XML data to the browser now and then and the browser does most of the logic and UI work.

On the other hand, you have the thin-as-possible client design, where the Web app basically lives on the server, and as much of the heavy lifting as possible happens there and is reflected in the browser through simple DOM updates. This is certainly a much more common scenario in the consumer Web app space and public Web sites — and a lot of Web designers are used to this model and are comfortable with it.

Well, I’m a Web designer, and I’m comfortable with keeping the browser lean and mean and putting the love into the backend. Except for certain types of operations where client speed is key, I just don’t see the need to do massive amounts of Javascript engineering. So when I was first actively looking for a good Ajax library to integrate into my PHP apps, my #1 priority was to find something that made Ajax as PHP-oriented as possible. The less Javascript I had to worry about, the better.

That’s why I settled on xajax and ended up joining the development team. xajax orients the developer towards a PHP-centric design model, whereby PHP functions (or object/class methods) process incoming data, do all the fun stuff they need to do, and return a response object with the necessary commands to update the browser accordingly. With a growing number of useful commands (and the all-useful “addScript” command to send raw Javascript down the pipe), the fun and easy things you can do with xajax are endless. And meanwhile, your Javascript can largely be reduced to single lines of code to trigger those PHP functions — xajax handles all the rest!

Now some purists may think putting that much “client logic” and DOM-specific commands in the server end, particularly the controller end in a MVC system, is a bad thing. Thankfully, I’m not a purist. I like keeping as much app logic out of the browser as possible. But the nice thing about xajax is that its flexible enough to accommodate almost anything. So if you simply use it to pass some data back to another Javascript function that you write, you can do that. (And we’ll be making that even easier down the line by adding JSON and callbacks). You can also use other JS libraries too, such as Prototype, at the same time within your client code. Finally, we soon plan on adding some plugin-based support for certain effects powered by libraries like script.aculo.us or moo.fx, so that’s also going to be nice to use in this fashion.

So there you have it. Two Ajax philosophies, and where xajax fits in. If you think PHP is the cat’s meow and Javascript should be kept simple and to the point, xajax may be the very thing you’re looking for. Version 0.2 stable is just around the corner, so be sure to come back soon and grab a copy!

This entry was posted on Wednesday, December 21st, 2005 at 11:39 pm and is filed under Design Philosophy, Personal News, xajax. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.