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.

I think I buy into this "ajax" thing

[gtrubetskoy]

Paul Graham's got an opinion on Ajax in his Web 2.0 essay [paulgraham.com].

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.

The book

[dantheman82]

I ordered it recently from Bookpool.com [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 [amazon.com].

Also, a very interesting resource is available through Pragmatic Programmer [pragmaticprogrammer.com], 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!

Free AJAX T-Shirt!

[ChaserPnk]

OK, I know this isn't much of a deal, but it's still good if you buy a lot of books. If you buy AJAX in Action and another Manning book from major bookstores, you'll get a free AJAX T-shirt. A list of bookstores [manning.com] has been posted.

I don't work for Manning, but I'm so in love with their books. The Java GUI programming book alone is worth a million to me. I refer to it almost everyday. I've looked at similar O'Reilly books and they don't even come close! I'm about to purchase Manning's .NET book pretty soon as well.

Happy reading.

Re:Can AJAX finally bring us "push technology"

[arkanes]

No. AJAX, for all it's hype and buzz and crapola, does not fundamentally change the client/server nature of HTTP and the web. AJAX applications that load data do it by polling, exactly the same as meta refresh tags and timer-based javascript refreshes have been for 10 years.

Re:Can AJAX finally bring us "push technology"

[CastrTroy]

You really can't do "push" with webpages, or their data. You could make something that looked like push, but in reality is actually just polling. The problem with this is that AJAX is supposed to reduce the amount of traffic to a website. If you have users constantly polling you for information, you're going to increase your load. I guess it would be better than polling and getting an entire page every time. We'd need to change the way AJAX works in order to get something that was truly "push".

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.

Re:Can AJAX finally bring us "push technology"

[jd142]

I think you can do all of these things since you can have javascript in a while loop/sleep or whatever and then every x number of seconds have the javascript call the function to update the page. I don't do a lot of client side programming, precisely because I can't guarantee what's on the client, but javascript should be able to do that.

The examples you have here though can also be handled by a meta-refresh. Unless you wanted different sections of the page to update at different intervals. So that the stock is updated every second, the news every 30 minutes, the weather every 15. Then unless you set the meta-refresh to the lower time, ajax would work for these things.

You could also be really old school and use frames with meta-refresh.

Although I will confess that I have only started with ajax, it seems to me that it is better suited to apps that are also passing client side input or changes.

But I could easily be wrong.

See it in action on Yahoo Mail Beta

[gasmonso]

If you're fortunate enough to see it in action on Yahoos's new email, you will be impressed. You can take a look here http://www.ajaxian.com/archives/2005/09/yahoo_mail _beta_1.html [ajaxian.com].

gasmonso http://religiousfreaks.com/ [religiousfreaks.com]

Real-world usage

[m2pc]

I am a developer for a huge PHP/SQL project and we are creating our 2nd generation system using AJAX. As a server/client developer this technology is allowing us to create a much better user experience.

I agree that AJAX has its downfalls ("back button" breaking, JavaScript usage, etc.) but most of these issues are present in "web sites" not "web applications". With a real Web Application, you have more control over the user in terms of requirements, etc. than a public web page.

To get around state change issues, we designed the system to load initial state values on page-load, then update page elements dynamically with AJAX. This cuts down on travel time to/from the server, and if the user hits the "Refresh" button, the state isn't broken.

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/ [redredmusic.com] 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/ [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?

Poll and Pull slowly

[jhliptak]

You can only do one thing with AJAX: change a section of a screen with data from a server without reloading the entire page.

What does that mean for push? It means that you can't do it. There is no real way to establish a connection from server back to the client.

So then what's the excitement all about? There are two things you can do with AJAX that a "normal" web app can't do:

• You can poll a server and update a portion of your web page. This method of polling can provide all four of your requests. The downside is that your polling and making requests you don't need.
• You can pull slowly. This is a technique where you make a request and you don't expect to get a reply until there is new data. So you draw your page, make a request for newer information and when it becomes available, the server will finally reply. The downside here is that there is a limited number of unresolved requests that most web browsers will allow and your server needs to be very smart about thread and socket allocation.

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 [bluishcoder.co.nz]

Paul Colton, the author of the AFLAX library, implemented the persistent socket idea here: AFLAX and Persistent Connections [aflax.org]. 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 [experts-exchange.com]

PS: GREAT QUESTION! VIVA SECURE SOLUTIONS! :)

Re:Can AJAX finally bring us "push technology"

[John Hurliman]

That whole technology relies "You keep a TCP/IP connection to your XMPP server open while you are online", which is already doable with HTTP. The client makes an AJAX call to the server, and if the server has data to return it sends it back immediately, otherwise it waits and holds the connection open until $TIMEOUT. If $TIMEOUT is hit it sends a "no data" message to the client, and the client reconnects again each time. This is how http://www.meebo.com/ [meebo.com] implements pseudo-push to create the webgaim bridge, and apparently it scales up to the tens of thousands with a few decent servers, but not sure how many users each machine can effectively support.

One day IPv6 will solve all this, and I can have news pushed to my browser in my flying car. Until then polling and pseudo-push seem to work all right.