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.
Can AJAX finally bring us "push technology" (Score:3, Interesting)
I'd like to have the following, all of which have been cumbersome and refreshy to implement in a web browser so far:
Re:I think I buy into this "ajax" thing (Score:2, Interesting)
Imagine Slashdot never re-loading a page. We could watch as posts spring into existence in real time. A little spooky, if you ask me. :)
Re:Good read so far (Score:2, Interesting)
Additionally, you could compile with optimizations to meet the capabilities of different browsers. Hell, toss in a little bit of encapsulation in the language "libraries" to avoid all of those layer/div issues. Etc, etc.
Javascript is good at what it does, it just wasn't meant to do quite that much.
Also, anyone wonder why there isn't a "valid CSS" to "IE broken CSS box model" translator? Maybe I ought to write that...
Re:Can AJAX finally bring us "push technology" (Score:5, Interesting)
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.
Re:I think I buy into this "ajax" thing (Score:4, Interesting)
Re:Good read so far (Score:3, Interesting)
Your cold fusion code is now acting an application tier language- it receives a simple query (give me the answer to my FAQ question number 3), and it queries the DB, formats the result as XML, and goes back to sleep.
However, a classic cold fusion site handles the page layout, loads in whatever resources are appropriate for that locale (english, german, japanese, whatever), queries the database, formats the results as a bunch of table tags, and outputs everything.
So you've effectively split your tasks into three tiers- presentation tier (in javascript), application tier (in cold fusion), and data tier (mysql or whatever). You're using cold fusion as middleware- I'd suggest that this is a fine strategy for a one or two developer site, but that you may wish to look to a more maintainable / suitable language for middle tier development- but that's just my $.02.
If it doesn't focus on the technologies being used (Score:4, Interesting)
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 [joelonsoftware.com] 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. [slashdot.org] (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?
Re:Can AJAX finally bring us "push technology" (Score:3, Interesting)
I saw a proof-of-concept demo of this over a year ago. It would be nice to see it integrated into Mozilla...
A Shorter, More Direct Alternative (Score:5, Interesting)
I just picked up Foundations of Ajax [apress.com], 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:
Re:Good read so far (Score:2, Interesting)
Re:Ajax Killed Himself (Score:1, Interesting)
The thing that annoys me is the "holy grail" this solution appears to be to many people.
It's still asynchronous. You still have to wait for a server response.
The only difference is that your browser will never know the status of the request until the Ajax request is returned.
It can be useful, but it's not the solution by a long shot.
Infact, it's even worse than page refreshed IMO. At least in the current "way of things," it's easy to know when the application fails to complete the request and it's easy to guage the progress of a request with visual in-browser cues.
Ajax is not going to bring the "desktop" to the web. the web isn't a desktop environment to begin with. it's a very different monster and I hope we won't all be disappointed by making it something it isn't.
I'm a web applications developer and I know this. Am I crazy?
You don't know (A)JAX sh*t. (Score:2, Interesting)
How many replied without even reading the book? I started it a month ago with the pre-release PDF made available before the book was published. (This book was the number 1 seller on Amazon just last week.)
My complaint is that the book is LONG on theory and SHORT on small, reproduceable code snippets. It's not until chapter 9 that you get into meaningful code and most of that is dependent on technologies you may not care about like SquealServer and VisualBasic. The last thing I want to have to do is install half a dozen things in order to get some sample code going. It seems the book is not so much about AJAX as it about "The software development process." It drones on about design patterns and MVC. The book is also very verbose saying in 100 words what could be said in 10. Good software engineering discipline is needed of course (especially with Javascript), but this book beats it to death where it should just relate it to AJAX and move on.
All the excitement about AJAX is warranted considering the stupidity of webapp development heretofore. It's really dumb to have to regenerate an entire web page when you just want to return some additional data or reflect a state change. How many production, revenue generating web pages have I seen where the mere click of an HTML select input causes the entire page to be redisplayed? Zillions. This stupidity is overcome by asynchronous part of AJAX. Do you know asynchronous JAX shit? That's the salient improvement over mere DHTML. There's a ton of websites desperately needing richer UI's and people who know asynchronous JAX shit will be in demand.
Re:Ajax Killed Himself (Score:3, Interesting)
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
Private Variables in Javascript ARE dead simple... (Score:1, Interesting)
var create_class = function() {
/* Private Methods */
var methods = {
method1 : function( self, pp, p ) {
/* Self = This */
self.prop1 = p;
/* pp is the Private Properties */
pp.pp1 = p;
},
method2 : function( self, pp, p ) {
alert( pp.prop1 );
}
}
var constructor = function ( parms ) {
var pp = {
pp1 : null,
pp2 : null,
pp3 : null
}
this.uber = my.parent.constructor;
this.uber( parms );
delete this.uber;
this.method1 = function( p ) { return methods.method1( this, pp, p ); };
this.method2 = function( p ) { return methods.method2( this, pp, p ); };
this.prop1 = null;
this.prop2 = null;
}
return constructor;
}
var myClassConstructor = create_class();
delete create_class;
var instanceOfMyClass = new myClassConstructor( { p1 : val1, p2 : val2, p3 : val3 } );
instanceOfMyClass.method1( "Hello World" );
alert( instanceOfMyClass.prop1 );
instanceOfMyClass.method2();