Sick of creating web sites that reload every time a user moves the mouse? Tired of servers that wait around to respond to users' requests for movie tickets? It sounds like you need a little (or maybe a lot of) Ajax in your life. Asynchronous programming lets you turn your own web sites into smooth, slick, responsive applications that make your users feel like they're back on the information superhighway, not stuck on a dial-up backroad.

But who wants to take on next-generation web programming with the last generation's instruction book? You need a learning experience that's as compelling and cutting-edge as the sites you want to design. That's where we come in. With Head Rush Ajax, in no time you'll be writing JavaScript code that fires off asynchronous requests to web servers...and having fun doing it. By the time you've taken your dynamic HTML, XML, JSON, and DOM skills up a few notches, you'll have solved tons of puzzles, figured out how well snowboards sell in Vail, and even watched a boxing match. Sound interesting? Then what are you waiting for? Pick up Head Rush Ajax and learn Ajax and asynchronous programming the right way--the way that sticks.

If you've ever read a Head First book, you know what to expect: a visually rich format designed for the way your brain works. Head Rush ramps up the intensity with an even faster look and feel. Have your first working app before you finish Chapter 1, meet up with the nefarious PROJECT: CHAOS stealth team, and even settle the question of the Top 5 Blues CDs of all time. Leave boring, clunky web sites behind with 8-tracks and hot pants--and get going with next-generation web programming.

"If you thought Ajax was rocket science, this book is for you. Head Rush Ajax puts dynamic, compelling experiences within reach for every web developer." -- Jesse James Garrett, Adaptive Path

"A 'technology-meets-reality' book for web pioneers on the cutting edge." -- Valentin Crettaz, CTO, Condris Technologies

Rating:

Rating:

Rating:

Just don't read it.,  January 17 2007
Submitted by Anonymous Reader   [Respond | View]

What a mess. Same information again and again and again. I am at page 109 and when I think what I have learnt till now its very little.

I was impressed by other head first books (SCBCD, Design patters etc) and I bought this book expecting that it would be of the same standard.

I must say that this is not the book for any professional.

Tnx


Awesome book to grab... I makes AJAX so simplified ...,  December 02 2006
Submitted by anandram   [Respond | View]

Hey o'reilly has done a great job by introducing starters book in form of head first and head rush...this book Head Rush Ajax made be to learn from the scratch....It makes us feel that AJAX is just a script as simple and interesting as other interesting languages...




Headrush... in 40s (review),  November 28 2006
Submitted by Martin Cleaver   [Respond | View]

In My review (https://martin.cleaver.org/blog/2006/11/27/headrush-ajax-book-review/) I quickly summarize the paradigm for someone who's familiar with web technologies, is wondering what they'll get from the book, and wants to know whether to buy vs. get it from a library.






very dissapointing,  November 27 2006
Submitted by Anonymous Reader   [Respond | View]

I was very unimpressed with this book.

Sixty pages of the same thing repeated to me over & over & over just to get to the stupid updatePage() function in the first chapter alone.

It was so bad that I returned it to Barnes & Noble and did not bother to read the rest.

Outside of the scope of the very poor client-side code conventions that were so eloquently articulated in a previous post. I was completely appalled at the quality of the PHP code that was supplied.

Given the fact that newbs will be reading this book, this is just further incentive for PHP developers (and aspiring PHP developers) to continue throwing out garbage applications.

This book was not worthy of the time it took me to go to the store, much less, the time I wasted reading the first chapter.

After reading Head First Design Patterns I apparently had my expectation set too high, however, I'm very disappointed.


Re: Not a good book,  November 21 2006
Submitted by Anonymous Reader   [Respond | View]

I found at least one mistake in your post:

>ID attributes are not added to SPAN elements to >style them. Classes are used for styling.

IDs can be used to style <span> elements. This mistake makes me question your credibility on the subject of web design and coding, on top of the fact that I loved the book, and found it enjoyable as well as informative.


Wonderful,  August 27 2006
Submitted by Anonymous Reader   [Respond | View]


A great book!

I really don't understand the comments of Michael (posted earlier). This book is really great.

I like studying form good books, not on screen (like those on-line courses), and without a teacher which I am depending on getting 'the picture'. And very important for me, as a not native English speaking person, a book that I can 'read' and 'understand' without searching through a dictionary all the time or trying to understand all kinds of 'weird' expressions.
In my opinion the 'Head First'-series do a great job in achieving learning and understandig 'hard' technical subjects on your own!

***** I can also recommend 'Head First Design Pattern' (I can't explain how thankfull I am that this book is written).



Not a good book,  June 07 2006
Submitted by Michael   [Respond | View]

The book is intended for someone familiar with HTML and some knowledge of CSS and JavaScript. I am the intended audience. When I wrote this, I had read the first 90 pages of the 400 page book.

This book employs a new learning style, there are many pages in the introduction bragging about it. It doesn't work, at least not for me.

There is so much repetition, non-nutritive filler and attitude, that new information is delivered in drips and drabs every few pages. I found the constant flood of useless information made it hard to concentrate. Even though I was very interested in the subject matter, the presentation style bored me and angered me at the same time. More on this below.

Every computer programming book starts with a "Hello World" example. And for a good reason. The way to learn a programming language is to start small (and nothing is smaller than a Hello World example) and build on it. That is not the approach taken here and it is a big reason why this is a bad book. The book starts with a medium sized example (mistake one) and then instead of presenting it as a whole, bits and pieces of it are presented across the first 60 pages. You couldn't take a worse approach if you tried.

As someone familiar with the old web programming paradigm, I was yearning for an example showing the exact same functionality done the old way and the new Ajax way. Side by side. The book doesn't do this. It doesn't do it at all, let alone side by side. The reader is never shown the whole project. How can you get your mental arms around an application you can't see? Not seeing the whole thing together made it harder for me to mentally envision where all the pieces go.

It seems to have had the same effect on the author(s) as shown in the disgraceful choice of variable names, which do not make it obvious where the piece fits into the puzzle. The lack of a naming standard is amateurish. At one point the same string of characters is used as a JavaScript variable, the ID of an HTML element and the NAME of an HTML element. Thus when the reader sees that character string, they have to work to figure out, based on the context, which of the three things is being referenced.

In making the case that Ajax style programming is better than classic web applications, the point is repeatedly made that with Ajax only the parts of the web page that need to be updated are. This point screams out for an example, but there is none.

Some of the screen shots are of Netflix.com showing the window that pops up when you mouseover the name of a movie. Nowhere is this mentioned in the text. This is a huge opportunity missed. Personally, I find the Netflix functionality very interesting. Instead, the entire beginning of the book uses a lame and cutesy example of selling snowboards, something so brutally artificial that it doesn't generate any interest on its own. There is a place for artificial examples, but if you're going to devote a lot of time to an application, it should be one that has, at least, a hint of usefulness.

-----Writing style-----------

No doubt O'Reilly is proud of the new writing style used in this book and, I suppose, other "Head Rush" books. It's bragged about in the introduction. I wasn't impressed.

The style involves tons of repetition, even of simple easy trivial facts. This is both insulting to the reader and a waste of time and ink.

The style includes lots of corny jokes along the way.

The style results in lots of whitespace. That is, there is very little information on a single page. My guess is that 3 pages or so in this book is equal to one in a book written in a more conventional style. So what? Sometimes when learning a topic, you need to see the forest. This book teaches one tree at a time, making learning more difficult. Tree. Tree. Tree. Makes is harder than necessary to see the forest.

When I read a computer book, I write in it. This helps me learn and makes, what I consider the important points, easier to review later. However, the books' style includes scribbles already. I had to read it with a red pen in hand, black doesn't stand out.

From the code samples page at headfirstlabs.com: "If you've ever read a Head First book, you know what to expect: a visually rich format designed for the way your brain works. Head Rush ramps up the intensity with an even faster look and feel..." I found the intensity lowered and the learning process extremely slow.

O'Reilly studied how people learn. They should, instead, have studied how people explain. A good explanation can be learned using any printing style. A bad one is bad, no matter what. The grammar in a letter does not improve if its printed on fancy paper with many colors and fonts. Bad is bad. I guess that measuring a good explanation is hard to do. Another symptom of this problem is the web page where Head First Labs recruits new authors. Requirements:

* Be passionate about a topic and want to help others learn it
* Understand their "style" and design
* Write quickly (you can do something artistic, such as writing a book, well or quickly. Chose one. O'Reilly has.)

Being able to explain things well, is not on this list of requirements.

To me, being a good explainer is the only thing that matters. It is even more important than knowledge of the topic at hand (which can always be learned). Someone who explains things well, will explain any topic well. I don't have to have read Mark Minasi's OS/2 book to know that it is well written. All his computer books are well written, regardless of the topic. Computer topics can always be studied and learned. Explaining things well can not.

I see this pattern over and over again - just because you know something doesn't mean you can explain it. Two separate skills. In baseball, the hitting coach doesn't bat cleanup. The pitching coach does not close out the game in the ninth inning. Knowing something and doing it are two different skills. In baseball terms, this seems brutally obvious. Likewise, knowing something and explaining it are two different skills. In college the best professors aren't the smartest ones, they are the ones that teach the best.

----Specific Gripes-------------

I didn't start nit-picking the text until page 30.

Page 16: As part of the example, they use pre-built JavaScript. Huge mistake. For one, the reader is never shown it. For two, what it actually does is simple and trivial, there is no need to hide it away. If it was hundreds of lines of code, this might be the right approach. Here it is the wrong approach.

Page 16: The error handling is wrong. If the request object is not created a message is externalized, but the application keeps on running. It will fail when it tries to reference methods or properties of the non-existent request object. There is no mention at all of the function passing back a return code indicating whether the object was successfully created or not. Makes me wonder if the author is even qualified to write this book.

Page 30: The explanation of exactly what the Open method does is poor. After calling it, we still need to "make the connection".

Page 31: Why is the application coded with so many JavaScript functions? Why does it need any functions other than than the callback one to update the page? There are pros/cons to dividing code into functions, a subject that is not discussed.

Page 32: At this point, I'm dying to know how you get an response back from an asynchronous call. Page 32 and the subject has not yet even been mentioned.

Page 33: The web form does not submit "everything" to the PHP script, in fact, it submits nothing. There is no explanation of how a normal button differs from a Submit button. Normal buttons are critical to the application.

Page 35: At this point I'm dying from the repetition. The same trivial points are belabored over and over and over.

Page 38: A web appl?

Page 41: There is no need for the "url" variable. Why is this a function vs. in-line code?

Page 45: Carries the cutesy bit too far.

Page 46: Introduces the last piece of the puzzle. Page 46 is way too late for this.

Page 48: Format. The issue of the data format for the data in the responseText property is never mentioned. Is it one long string? In this case we are only getting a single data item. What if we were getting back multiple data items? How are numbers represented?

Page 49: Bad learning technique. Introduce the missing concepts, then the code that implements the concept. Don't introduce the code by itself.

Page 50: A brutal example of poor naming standards. The request object is called "request". It should be "objRequest" or "Requestobj" or "myrequest" or "request1", something different than "request". In fact, since it is a request object, the worst possible name for it is "request". "xyz" would be better.

The code here is dealing with functions, objects, methods, properties, variables and HTML elements. Without a naming standard, it is harder than necessary to keep track of what's what. In the old Tarzan TV show, the boy was named "boy". Same thing here.

The book suggests assigning each element to a variable so that it can be "easily" referenced later. Easily is a code word for less typing. If you can't type, you shouldn't be programming. The use of variables introduces complexity that is NOT needed and does not belong in what is supposed to be a simple, introductory example. Call a spade a spade at first. In later examples, it can be referred to as "s" if typing "spade" is too much to ask. The lack of a naming standard just makes this worse.

ID attributes are not added to SPAN elements to style them. Classes are used for styling.

Page 51: The code in text-utils.js is not shown. It should be. The use of a JavaScript library of functions is too complicated for a first example. It gets in the way of learning and demonstrating Ajax.

Page 52: Nowhere in the book was the issue of case sensitivity in JavaScript raised.

Page 53: Again, bad variable names. A step below "xyz". The same name is used both for a JavaScript variable and an HTML element.

Page 59: The text admits that the application coded so far contains a bug.

Page 61: Again, bad error handling, the application keeps running despite a fatal error. At this point there has been no discussion of error handling.

Page 62: We still have not yet seen the entire application.

Page 67: What does this application bring to the table? Why are we covering it? What does it do that the first example did not?

Page 70: I found the application too artificial, trivial and boring. And it doesn't exploit or illustrate Ajax well.

Page 71: Why do we need several JavaScript functions?

Page 74: The address and order textareas should be disabled until the phone number has been entered.

Page 77: The function that gets the customers address is called getCustomerInfo. Not getCustomerAddress. Why?

Page 78: The description of the onChange event is poor. Is it invoked every time a character is entered? After all changing "212" to "2127" is a change even though its not yet a full telephone number. If not, then how does it differ from the onBlur event?

Page 79: Why should we clear the form every time it's loaded? What problem does this solve? It should be a later enhancement, not part of the first go round. Also, forms don't' get loaded, web pages do.

Page 80: The textareas have both names and IDs. Why? The names don't seem to be used for anything. And continuing the pattern of poor names, both the name and ID tag of each element are given the same name. And the name does not describe what the thing is (an HTML element). Ugh.

Page 82: There is no document variable, it is a document object.

Page 83: Many gripes with one line of code: var phone = document.getElementByID("phone").value
There is no need to assign it to a JavaScript variable. If you are going to use a variable, the name should be js_phone or var_phone or something to indicate that it is a JavaScript variable. The HTML IDs should start with "el_" or something to indicate they are HTML elements.

Page 85: At no point is the format for the phone number addressed. Are spaces and dashes and parens allowed? If so, how remove them. If not, then say so and validate the input. What is the JavaScript escape function? Again, there is no checking of whether the request object was actually created.

The "Say What" at the bottom of the page is symptomatic of how the book does a poor job of explaining things. It does not start small and build. Instead it starts with a forest and explains each tree. The blind man and the elephant.

Page 86: The text says that the error checking "makes sure nothing went wrong". This is not true.

Page 88. Code introduced on page 16 is explained here.

----Errors----------------

The credits list six people responsible for technical review of the book. Despite this, the first 60 pages had two brutally obvious mistakes. And, due to the writing style, 60 pages in this book is equivalent to about 20 in a regular book.

* Page 54: It says that the JavaScript request object tells the web browser information (wrong). Elsewhere, it says the reverse, that the browser tells JavaScript information (correct).

* Page 56: It says that JavaScript may return a value of 5.9499995 instead of the desired 5.95 (the number is a price and thus has to be reported with 2 decimal places). Then it discusses how to work around this. You multiply by 100 to get 594.99995 which is rounded off to the nearest integer: 594. Ooops. Then it says to divide by 100 to get 5.94 which is the desired result. Ooops again. The desired result was 5.95, not 5.94.

This is also on the web at
computergripes.com/ajaxbook.html


Learn The Fundamentals,  June 03 2006
Submitted by S. Stanicki   [Respond | View]

Other reviews have supplied the synopsis, and table of contents for this book, so I'm just going to put my 2 cents in regarding the Head Rush/Head First format.

Some people might think it's too cute, but to get an entry level understanding of a technical topic, there is none better than this series. This is the second book in the series I have owned. The other is 'Head First Java'. If you are serious about learning something new, understanding fundamentals is the key, and teaching the fundamentals is what this series is about, and it excels at.

In the future, I will pass up the 'Dummies' and 'Idiots' books for quick fixes that I might forget, and look for a Head First/Head Rush book to gain a better understanding of concepts.



Learning can be enjoyable yet effective,  April 25 2006
Submitted by barryhawkins   [Respond | View]

Programmers are flooded with choices about which technologies to pursue in order to maintain a marketable skillset. Even in a particular area of programming like web applications, one must choose carefully where to invest time. Ajax (https://en.wikipedia.org/wiki/AJAX) , to the regret of some and delight of others, has emerged as a means of providing rich, responsive web applications that are highly cross-platform. However, when arriving home after a 10-hour day at the office programming, who has the energy to plow through yet another new facet of emerging technology? If a developer is going to invest their free time in self-driven career development, should it not be at least remotely enjoyable? Judging from the content of O'Reilly (https://www.oreilly.com) 's new release Head Rush Ajax (https://www.oreilly.com/catalog/headra/) , their answer is yes.

Like its forerunner the Head First series (https://www.oreilly.com/store/series/headfirst.csp) , the Head Rush line approaches learning a given technical topic with the principles derived from studies in cognitive science, neurobiology, and educational psychology. It comes as no surprise that the classic approach of turgid, monotonous, visually-fatiguing tomes is not the ideal way to have someone learn a topic. Learning is aided by having variation in the way content is presented. This book moves between presentation of information, application through interactive exercises, and review questions that stimulate the reader and invite them to continue in the book's journey through Ajax. Each exercise is also tied to a storyline, where the reader has a person with an application that needs to be enhanced by the application of the skills being learned.

Head Rush Ajax scales well. Ready-to-run scripts for the more technical components of the sample applications are provided so that a reader with only a background in HTML and CSS will not experience barriers to participation early in the book. This facility does not come at the expense of the experienced web developer; anyone who knows their way around a PHP script and databases is free to write the server-side code on their own. Some readers may look upon the choice of PHP for the back-end scripts as regrettable, particularly those with Java and .Net backgrounds. However, the focus is on Ajax itself, and not the particular back-end platform providing the HTTP responses. Those who look upon that sort of thing with scorn typically view Ajax as a novelty itself, so the number of complaints about using PHP should be relatively low; the dissenting voices will have probably passed over Ajax for the time being anyway.

The author never takes himself too seriously; the informal tone of the book is comfortable, like having a conversation with one's colleagues at the office. The balance of levity and solid technical content is refreshing, making this volume of some 400 pages reach its end surprisingly soon. Retro cartoon graphics and narrative comments like "Now, everyone hates you. You're an idiot, and all this Ajax stuff was a waste of time" when a URL caching error is uncovered make for a genuinely enjoyable read.

The Document Object Model (https://www.w3.org/DOM/) , or DOM, has long had a reputation for being an unwieldy and problematic interface to manipulate. The tree metaphor used in this book along with the series of progressive exercises present the DOM in a refreshingly approachable manner. By the end of the DOM-specific coverage, an entire application has been created that is highly dynamic yet involves no Ajax-specific coding. The critical role of the DOM in effective use of Ajax is driven home without being heavy-handed.

The choice between using XML (https://www.w3.org/XML/) and JavaScript Object Notation (https://www.json.org/) (JSON) for receiving data via HTTP responses is another entertaining treatment of a topic that is often grounds for argument between practitioners of web development. The author comes across with a pragmatic viewpoint, preferring JSON as the simpler choice that is most often adequate and does not bear the high ceremony that accompanies proper handling of XML via the DOM. Two of the sample applications choose opposite means of receiving their data, once again fleshing out a topic in a concrete manner rather than pontificating about the virtues of either approach.

The progression of the book is masterful. The types of issues that typically plague web applications are addressed in the order they tend surface during the lifecycle of a real-world application. Proper functionality is the first stage, followed by enhanced functionality, then onto issues with synchronicity, security, and more complex domain model requirements. A reader can pass through an encapsulated representation of application lifecycles by working through the book from start to finish.

The goal of Head Rush Ajax is to have the reader learn Ajax, not master it. At the conclusion, the author appropriately offers topics for further exploration in the form of two appendices. The first appendix covers Ajax toolkits, user interface libraries, DOM utilities (most of which are built plugins for the browsers in use on desktops every day), and JSON libraries. Links to the project sites provide easy access to pick up where the book's coverage leaves off. The second appendix provides deeper insight on the internals of two JavaScript utilities provided for use in the exercises throughout the book. One is an Ajax-specific set of common infrastructure for typical Ajax applications, while the other provides convenient methods for DOM manipulation. Head Rush Ajax is a most enjoyable launchpad into the world of Ajax web applications, well worth the investment in time and money.

See larger cover