Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Book Reviews Books Media

Ajax in Action 270

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.
This discussion has been archived. No new comments can be posted.

Ajax in Action

Comments Filter:
  • 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.
  • by arkanes ( 521690 ) <arkanes@NOSPAM.gmail.com> on Wednesday November 23, 2005 @03:12PM (#14102511) Homepage
    where you think of the browser hosting your application rather than content

    And this is where you go wrong, and why AJAX sucks, and will continue to suck - web browers are (fundamentally) shitty application platforms, for very important reasons that will not go away. The future of web applications, the future where they don't totally suck and aren't jury rigged one-of inconsistent half-assed things, is in specialized thin clients.

  • by RetroGeek ( 206522 ) on Wednesday November 23, 2005 @03:13PM (#14102515) Homepage
    The central idea behind Ajax is pretty good IMHO- moving as much of the presentation-tier processing as possible to the client system.

    Which to me sounds like a stab at re-inventing Java applets.

    All the problems you describe (name spaces, libraries, etc) are already solved in Java. In addition, you are not at the mercy of browser JavaScript bugs.

    The only downside is the initial startup time for the Java applet, as the local JVM must be loaded, THEN the applet.

    As for the JVM version, you can check for this in your applet before you start the dependant code, and you can ask the user to d/w the JVM.

    The technology Java Web Start [sun.com] provides an easy to use framework.
  • Compatibility (Score:5, Insightful)

    by kstumpf ( 218897 ) on Wednesday November 23, 2005 @03:15PM (#14102540)
    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.
  • by dghcasp ( 459766 ) on Wednesday November 23, 2005 @04:11PM (#14102979)
    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.

    From the records of the site I maintain, about 6% of all accesses are from browsers that can't handle AJAX.

    Incidently, from my over-optimistic decision to do all the layout for the site in CSS, those 6% also took 75% of the time and are responsible for 1/2 of the .css file being "hacks." Never again. Tables rule.

  • by laoc00n ( 933461 ) on Wednesday November 23, 2005 @04:17PM (#14103029)
    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.
  • by arkanes ( 521690 ) <arkanes@NOSPAM.gmail.com> on Wednesday November 23, 2005 @05:01PM (#14103371) Homepage
    Netscape didn't believe that,

    And they were wrong, too, and so was Microsoft. They were worried that Java appletts, of all things, were going to kill the desktop OS. Wake me up when that starts happening - and it had a much better chance than AJAX does.

    Google doesn't seem to believe that it's a terrible platform either.

    Thats why Google Earth is an AJAX application, right? Except it's not. And Googles applications, while good and certainly groundbreaking in terms of web applications are nothing compared to the state of client applications, even years ago. The UI features Maps and GMail lack are too many list here - and they are extremely suited for deployment on the web. Spreadsheets, and even word processing, not so much.

  • by Bobbysmith007 ( 717813 ) on Wednesday November 23, 2005 @05:24PM (#14103570)
    AJAX... Woo!! After 20 years of toil and effort we have managed to recreate the Client Server application model that held us strong all through the days before the PC. Cool. I love the hype around the reinvention of 30 year old tech, on a new platform
  • by legirons ( 809082 ) on Wednesday November 23, 2005 @07:45PM (#14104543)
    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.

    I suppose the reason is, who do you trust?

    e.g. I look at xmlHTTPobject (or whatever it's called) and wonder, "how can they allow that, after all the fuss about ensuring that cookies aren't cross-domain"

    As I see it, AJAX is competing against things like Java, .NET, and ActiveX. Basically, the alternative is a popup window saying "Do you trust 123technologies to run this program? [Yes] [No]".

    And the population here is divided into (a) people who wouldn't install untrusted software if it were recommended by Gabriel Himself, and (b) people whose computers won't run because they're clogged-up with spyware.

    As you say, there are loads of better technologies if you trust the application writers. But who does?

Always try to do things in chronological order; it's less confusing that way.

Working...