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.

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

[CastrTroy]

This is what bothers me a little bit. Sometimes when I'm at a web page that uses Ajax, I'm expecting the page to refresh, or do something else when I, say, click on button. Sometimes you don't even notice stuff happening, and you're sitting there waiting for some page to load, that is never going to load. I know how the web works, so I expect things to happen a certain way. When pages use AJAX, they change the way things are done, and start to confuse those that really know what's going on.

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.

The book

[dantheman82]

I ordered it recently from Bookpool.com and although they claim that it's out of stock, I still ordered it and recevied it not too long after. Otherwise, if you'd rather get it a little sooner, try out Amazon.

Also, a very interesting resource is available through Pragmatic Programmer, a beta book which means you can get PDF updates as they are written until it is shipped in hard copy in Feb. 2006. Already a book of 160+ pages, they already had a section on creating your own version of Google Maps (and more relating to SAJAX and other PHP implementations). The beta book, while only a little extra, is highly recommended!

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.

If it doesn't focus on the technologies being used

[Tetravus]

it's useless.
AJAX is a simple concept. Really, it is. Getting three different coding paradigms to work together harmoniously is not so simple. Throw in available AJAX libraries, JSPs and Atlas pages and you've got layers upon layers of coding cruft that need to be understood before a functional, stable, web-app can be built.

If this book stays at the architecture astronaut level without ever delving into the why of the code structure of the example programs, then it may serve as a cookbook but certainly not as an informative manual that can provide a baseline from which coders can build their skills.

Perhaps the book is better than the reviewer makes it out to be, but he offers no real justification of the 9/10 score awarded, so it's hard to say. Just for giggles, I should note that when Richard Stevens' seminal Advanced Programming in the Unix Environment, 2nd Ed. (being possibly the most comprehensive and useful programming book I've ever read) was reviewed it also received a 9. How do these two books compare?

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.

Re:Ajax Killed Himself

[dasil003]

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.

Oh please, not this tired argument again! What you software engineering nazis are forgetting is that HTTP and HTML were designed to transmit static content. In that regard the protocol and the markup language are a tremendous success. HTML and HTTP are incredibly scalable and easy to use, which means getting more done in far less time. Remember that most of the web is static information. In fact, web infrastructure was so dead simple and easy to work with that web applications have flourished. It's not like there weren't competing technologies, and if they were the panacaea you seem to think, no doubt they would have done better in the marketplace.

The real problem here is your inability to think outside your own comfort zone.

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.

This sentence is complete gibberish. Java is platform independent? Pretty close maybe, but you still have to test it for every target platform. There are advantages to having your application running on your server. Dumb XML data structures? No, we pass view data to the browser... maybe XML to be processed via JavaScript, maybe HTML/CSS for raw output, maybe an image, maybe a string. Why pass bloated objects and more code to be tested on every target platform when we can just pass the data we want the user to see? "stateless" objects? Just because HTTP is stateless doesn't mean web applications are. This is a separate issue from object-orientedness, which also has nothing to do with underlying protocols. all processing must happen at one end of the connection? View processing can be done client-side via Javascript which is very much optimized for that type of code. Meanwhile the bulk of your application code stays on the server in a controlled environment where it is secure. Don't underestimate the value of running your code in only one place.

You seem to think being able to pass Java objects to a remote computer would be some kind of revolution in web development, but it would introduce a whole slew of issues, and for what? Not much we can't do just as easily now (unless you only know Java).

Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser.

HTML + CSS is orders of magnitude simpler than presenting typical content through a GUI. Remember, the web is first and foremost about content. Name one other format that you can edit in a text editor and get anywhere near the power of HTML and CSS. Not PDF, Not Word Docs, Not Illustrator Files, Not Quark Files. Web browsers are not GUI technology. The fact that people can use it as a suitable replacement for GUI technology is a testament to

Re:Can AJAX finally bring us "push technology"

[doublec]

Yes and No. One approach is to use have the client initiate an AJAX request to the server but the server does not send data immediately. It delays until there is stuff to push. It can either continue to push as needed (I send Java which gets evaled by the client) or it can close the connection and have the client re-connect. It then goes back to the delayed response.

This is better than client polling in that it's not so bandwidth unfriendly. It has the downside that browsers only have a limited number of connections that it uses and this eats one of them up (Some versions of IE only use 2 connections). This could prevent other AJAX or normal HTTP requests from occurring.

The same problem exists with the 'hidden IFRAME' approach. One interesting workaround is to have a hidden flash applet on the page whose sole purpose is to create a persistent connection to the server. The server can send data to the flash applet which then calls javascript callbacks on the web page. This does not eat up a browser connection as flash has its own connection pool. As it's a normal socket you can also use any protocol for the events you want. The downside is that if the user goes through a strict firewall that only allows outgoing http traffic on port 80 you're stuck.

I describe some of the options here: More on Ajax and Server Push

Paul Colton, the author of the AFLAX library, implemented the persistent socket idea here: AFLAX and Persistent Connections. It uses AFLAX which allows easy communication from Javascript to an embedded flash applet.

The approach I've gone for is to use the flash idea, falling back to a delayed AJAX call response, then to a hidden IFRAME depending on browser support. This approach does what you want - allowing the server to push to the client.

Re:Reminder about browser abilities.

[Bogtha]

Don't get me wrong, AJAX is really cool. But if you develop your site using it, you'll be making your site inaccessable to anyone using MacOS9 or older browsers on Windows or *nix.

Nonsense.

Best practice with Javascript is to develop a site that doesn't use Javascript, and then add the Javascript in such a way as to be backwards compatible. AJAX, being a form of Javascript, is exactly like this.

Some developers cut corners and write code that isn't backwards compatible. That's their decision, but it's got no bearing on whether or not AJAX itself is backwards compatible. AJAX is definitely backwards compatible. Visit Google Suggest in Lynx. It works fine. If you visit a site that uses AJAX and is not backwards compatible, then it is the fault of the site developers for misusing AJAX. It's not an intrinsic limitation of AJAX.

All you are doing by saying that AJAX is not backwards compatible is scaring some people off AJAX, and making others give up on backwards compatibility. The former will result in less usable websites, and the latter will result in less compatible websites. Neither of these are good things. Please refrain from saying that AJAX is not backwards compatible. It is. You don't have to choose between AJAX and backwards compatibility, so don't mislead people into thinking that they do.

Re:Is AJAX secure (https)?

[Heembo]

I forced the URL to HTTPS and it worked just fine. The browsers already support HTTPS and that translates directly to JavaScript.

I make sure the initial page it HTTPS to start with. I do not know how to have a HTTP page, and a HTTPS Javascript transaction.

Here is another link that talks about the same issue. http://www.experts-exchange.com/Web/Web_Languages/ JavaScript/Q_21636735.html

PS: GREAT QUESTION! VIVA SECURE SOLUTIONS! :)