Ajax in Action

Simon P. Chappell writes "There's always a danger when a new technology buzzword hits the ground running. The danger is that when it finally slows down enough for us to take a good look at, it'll be found to be empty hype with less value than a mime performance on a radio show. This time the buzzword is Ajax and it's moving so fast that you can almost hear the sonic boom. The authors of Manning's new Ajax in Action have managed to catch up with Ajax long enough to take a look at it for us. Their book explains what Ajax is, how to use it and how, for once, the hype may be underselling the prospects for this new buzzword." Read on for Simon's review. Ajax In Action author Crane, Pascarello with James pages 650 (16 page index) publisher Manning rating 9/10 reviewer Simon P. Chappell ISBN 1932394613 summary If you want to create dynamic web applications, get this book.

The majority of the book is for programmers engaged in the development of web applications; especially those who are interested in taking their applications beyond the traditional ``click and wait for the response from the server'' model that we've become accustomed too.

The first section, and particularly the first chapter, would be suitable for anyone who is curious about Ajax. The first chapter answers the questions of what it is, and why it deserves all of the positive press that it's received. If you're introducing Ajax at work, this might be the chapter of recommended reading for your managers and software architects.

Alright, enough introducing the book, now let's take a look at just what Ajax is. Ajax itself is an acronym created by Jesse James Garrett in his, now classic, article Ajax: A New Approach to Web Applications. Ajax, we are told, means Asynchronous JavaScript and XML. This is our first clue that Ajax is not a single, new thing. Ajax actually turns out to be a combination of existing technologies mixed up in a fairly new way.

The fundamental ingredients in Ajax are in-browser JavaScript, Cascading Style Sheets, the browser's internal DOM model and asynchronous HTTP requests. Ajax, the technology, is the amalgam of these individual technologies. Thus, Ajax is both new and well proven at the same time.

Perhaps it's also possible to view Ajax as the natural resting place of the pendulum of application development. Programmers, since the beginning of application development have been trying to balance user experience and ease of installation and maintenance. First we had mainframes with their centralized usage model. Next we got the PC with it's entirely disconnected usage model. This was followed by the Client/Server model that tried to be connected yet offloaded it's processing to the client. The world wide web came next and browsers as the ultimate thin clients forced all of the processing back onto the server again. Finally now, with Ajax, we have what seems like a good balance of server side processing, with responsive clients that provide the rich user interface that users want. The pendulum of centralized versus decentralized has found it's rest point.

The structure of the book is fairly standard. The first section, three chapters, concentrates on imparting the concept of Ajax to the reader. The first chapter begins with the concepts, chapter two takes the reader through some very simple first steps, while chapter three explores how the Model View Controller pattern (MVC to it's friends) applies in the Ajax world and looks at third party, free and open-source Ajax libraries available today.

Part two of the book explores the core techniques of Ajax. Chapter four explores the difference between a web application and a desktop or Ajax application, that of a single page being the entire application. Chapter five explores the role of the server, looking at what resources are available for the server-side coding, including available languages and frameworks as well as ways and means of exchanging data with the server.

Part three looks at what the authors call ``Professional Ajax'', the techniques that make a difference when creating real world applications. Chapter six covers the design of the user experience. The user experience for a major application basically is the application for the user and so getting this right is of fundamental importance. Chapter seven explores security and some of the actions that the developer can take to both ensure access control and protect confidential data. Once the basics of Ajax are mastered, this may well be the most important chapter in the book. Chapter eight covers performance and what can be done to assist application speed and resource usage in practical use. Perhaps the most important measure for an Ajax application is the perceived speed and responsiveness that it delivers. The asynchronous processing is a huge factor in achieving these user perceptions.

Part four shows Ajax by example, with four chapters of example applications and a fifth chapter addressing building stand-alone applications using Ajax.

There is much to like about this book, but top of the fold for me is the clear and concise explanation of just what exactly Ajax is and why it has the power to make a difference in the web application arena. At a time when more people speak of Ajax than actually understand it, this book has the power to bring forth understanding.

This is a very dedicated book. It takes no time to teach the reader the individual technologies that compose Ajax, rather it concentrates on using those technologies. If you do not know JavaScript, or Cascading Style Sheets or do not understand the W3C's DOM model or asynchronous messaging then you would be better served at this time by learning the individual technologies and saving this book for after you've mastered them.

Other than the standard book page over at the Manning website, there is no dedicated book website. This is perhaps unusual, but 30 seconds on your search engine of choice should get you started. Failing that there is a good Ajax page available at Wikipedia.

This is a magnificent book. Not because it's well written and has good example code in it, although it is and it does. Rather, it is magnificent because of the high speed target that they have accurately hit and described in a clear and hype-free fashion; for this the authors are to be commended. If you want to create dynamic web applications, get this book."

You can purchase Ajax in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

AJAX explained...

[nother_nix_hacker]

No need to buy this book. Just consume one of these and you will awake the next morning know how to use javascript and XML in unison to produce yet another del.icios.us clone!

http://www.cleansweepsupply.com/pages/skugroup1068 .html

I think I buy into this "ajax" thing

[gtrubetskoy]

Paul Graham's got an opinion on Ajax in his Web 2.0 essay.

I too initially thought "What's the big deal, it's just JavaScript". But I'm now actually reading the "Ajax in Action" book, and it looks like there is something to it. It's not so much about the tools you use (which are indeed JavaScript and CSS pretty much), it's more about the architectural view of the application, where you think of the browser hosting your application rather than content and the server produces data rather than content and how Ajax coding is not just get-the-javascript-to-work-and-move-on like in the old days, but rather not unlike any other language, requiring same level of discipline.

Anyhow, the book explains it better, I recommend it.

Re:I think I buy into this "ajax" thing

[AKAImBatman]

I too initially thought "What's the big deal, it's just JavaScript". But I'm now actually reading the "Ajax in Action" book, and it looks like there is something to it. Anyhow, the book explains it better, I recommend it.

You make it sound so new and mysterious.

AJAX is simple. We now have a cross-browser method for making server requests in an asynchronous fashion. Combined with the fact that the demise of Netscape 4 means that we can finally code for the DOM, and you've got a recipe for success. It's not anything magical or mysterious. In fact, you could do it with hidden IFrames long before AJAX even became a buzzword. The key is that it's useful and semi-standard. Which means that we can finally deploy all those cool web apps we've wanted to deploy for years but couldn't.

So..

[PhrostyMcByte]

I guess we are in for a much cleaner internet?

Intersting book site

[smittyoneeach]

My only disappointment was that the popup on mouse-over didn't say "Hello, world", which would've been funny on a couple of levels, and opted for something practical like telling you how to BTFM.

Feyenoord Ajax

[Anonymous Coward]

I have used this idea Ajax and I found the alternative Feyenoord to be superior in every department. However there is worse to be found on the market, after trying out PSV Eindhoven I demanded my money back.

Javascript namespaces

[brunes69]

"Namespaces in Javascript are dead simple, because of function scoping:

window.MyNamespace = new Object() {
function NamespaceMethodA() {
// alert('hi');
}

function NamespaceMethodB() {
// do b code...
}
}

NamespaceMethodA() // Causes exception

MyNamespace.NamespaceMethodA() // works.

Want to "import" a namespace? Include this function in one of your base .js files

function import( namespace ) {
for( i in namespace )
window[i] = namespace[i];
}

You can now do import(MyNamespace) and all it's members will be locally scoped.

The problem in Javascript is not namespaces - it is the fact that there's no way to mark a method/variable as protected/private. So you need to resort to old C-style crap like appending _ to private members if you want to enforce your contracts.

Compatibility

[kstumpf]

AJAX represents a new paradigm in UI design for web applications. I don't think there's much question about AJAX's value. You will see two problems though: 1) browser compatibility, and 2) bad code and interface design.

You have to think hard when deciding if your client base is ready for it. The same browser issues exist with AJAX that exist for any other "new" client-side technology. By relying on it, you will exclude visitors.

As for my second point, get ready for a lot of bad AJAX. People have a hard enough time designing interfaces as it is (think of all the bad ones out there), and building dynamic ones that work like people expect them to will be that more complicated.

Re:Can AJAX finally bring us "push technology"

[_xeno_]

Nope. Push is dead, NAT killed it. (Well, a whole bunch of things killed it, but essentially you can't connect back to a client any more, and there are a whole host of reasons why you generally don't want to leave connections open.)

However, you can do what email clients have done for ages: poll. And that's what things that emulate what you're talking about essentially do.

Essentially, with AJAX, you'll have some JavaScript program that uses the good ol' window.setInterval to poll the server every five minutes or so. It gets back an XML document that contains a list of changes, if any, to the page you're looking at. If the data has changed, it then uses the DOM to alter the page to display the new information.

Effectively, though, it's just a page that refreshes automatically via JavaScript. Because it can pull back an XML document, it doesn't have to download ALL the HTML stuff to get the data. Because it's in the background, it doesn't have to "destroy" the page to load the new information, allowing it to be added to an existing page in a seamless manner.

It's really nothing new, exactly, it's just that the most popular browsers (Internet Explorer, Firefox, Opera, and Safari) all support XMLHttpRequest in some form now, making it feasible to use it without cutting out some section of your user base. It's just message passing in JavaScript.

A Shorter, More Direct Alternative

[kimanaw]

I read the sample chapters of the reviewed book and was underwhelmed. Chapter 4 spent way too much time trying to sound "impressive", with lots of UML diagrams and Design Patterns references. Plus, 615 pages for AJAX ? Unless 400 of those pages are weblinks to online references, I'm afraid its just killing a lot of trees.

I just picked up Foundations of Ajax, and its a good, focused 273 pages, of which nearly half is resources and tools for implementing. I haven't had a chance to download and try out the examples, but the reference links all look like great resources. While I wish they'd skipped the usual Chapter 1 "Here's the history of the web" that any reader of the subject matter already knows, all in all, its a great way to cut thru the BS and get rolling with the AJAX concepts.

In summary:

• If you want to learn UML, buy a UML book
• If you want to learn Design Patterns, buy the GangofFour book.
• If you already know how to put together a webpage, write some Javascript, and maybe a little CSS, and just want to understand how it all to hangs together in AJAX, then Foundations of Ajax is probably a better choice than "Ajax in Action".

AJAX inthe Real World

[Heembo]

In may ways, that book is out-of-date. Here is what is working for me *today*. There are many possibiliites, but my focus is Rapid Application Development - and these tools help me rock and roll, fast.

Last week I was tasked to replace several standard (but sometimes complex) HTML business forms with an AJAX solution. Here are the best tools I found after lots of research time. This is bleeding edge; but functional in Opera, Safari, IE XP, FF XP, FF OSX, no small feat.

1) AJFORM - submit a form via Javascript using HTTP post or get without refreshing the page. (next release in a few days, keep an eye on it, its brilliant and easy to use) http://redredmusic.com/brendon/ajform/ 2) YOUR SERVER CODE - I use Java, but anything including ASP, CF, PHP - its all works. (Standard HTTP). Just needs to spit out XML, easy feat. 3) GOOGLES XPATH LIB - those of you who use Sarissa, drop it - she does not support Safari. Google's XPATH lib does, well, on all browsers you need. http://goog-ajaxslt.sourceforge.net/ - this is the best and easiest way to "search into" XML data. You can use native DOM calls, but it takes about 10x as much time to get it right.

With AJFORM and Googles XPATH lib on the client, I was able to quickly and effectively start making business forms in AJAX that were "scarry fast" and WOW'ed all the folks who are paying the bills! YAY!

Whats your architecture for AJAX?

Ajax Killed Himself

[laoc00n]

Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http. Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications. Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser. So: having gone from a world of functional, stateful, distributed applications engineered to a true software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to procedural programming and dumb terminals (meaning Web browsers). In other words, 1970s technology with pictures. Any half-wit can see that this situation is broken. How do we fix it? The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place. Brilliant.