May 03 2006


Relevance Review #8: Pragmatic Ajax

Pragmatic Ajax, by Justin Gehtland, Ben Galbraith, and Dion Almaer

Reviewer's Disclosure: I (Stu) own a company with Justin, and am very good friends with Ben and Dion.

Quick Summary:Strong introduction to Ajax; excellent comparisons building simple Ajax functionality with a variety of the best client and server side tools.

I would divide Pragmatic Ajax into five parts:

  1. Introduction and Background (Chapters 1-4)
  2. The Client Side (Chapters 5-7, with a few asides)
  3. Intermediate Concepts (Chapters 8-10)
  4. The Server Side (Chapters 11-15)
  5. The Future (Chapter 16)
Each part is reviewed below.

The introduction and background chapters are strong. This material is similar to material in every other Ajax books, with a couple of distinguishing features. Chapter Two builds a Google-Maps-like application. While I don't think most developers will use Ajax to build mapping applications, this is just cool. The other, more important feature is the choice of a very simple example: the Zip code lookup. Chapter 3 introduces a form that automatically populates a city and state as the user enters a Zip code. I like this example (and use it myself when training) because the basic code is incredibly simple. As a reader you can focus on the Ajaxy parts, without getting bogged down in the complexity of the sample itself. Rather than introduce a ton of new examples as the book goes on, the authors re-implement this example about a dozen times throughout the book, comparing and contrasting wire formats, client libraries, and server libraries.

The client side chapters build the Zip code example several times. Along the way they introduce client-side helper libraries, remoting options, validation, bookmark and back button support, visual effects, progress indicators, and update indicators. These chapters are the most important part of the book, in that they (a) make a strong case for introducing libraries and (b) choose good libraries to introduce. The examples are built using Prototype/Scriptaculous and Dojo. When you consider both code quality and integration with server side technologies, these are among the most important libraries out there. Do not build Ajax applications in raw JavaScript!

The intermediate chapters answer the question "I can build a basic Ajax application, what happens now?" Chapter 8 introduces a variety of tools for debugging Ajax applications inside various browsers, including logging, DOM inspection, and step debugging. Everyone should learn these debugging tools--I am constantly surprised to discover developers troubleshooting their Ajax apps with nothing more than their browser and intuition. Chapter 8 also sneaks in yet another cool Ajax framework, MochiKit. Chapter 9 shows how to make your Ajax application "degradable," i.e. functional in non-Ajax browsers. Chapter 10 introduces JSON and JSON-RPC as an alternative to XML.

The server-side chapters compare and contrast different server-side choices for Ajax: PHP (Sajax and XOAD), ASP.NET (Atlas and Ajax.NET), Java (with DWR), and Rails. The authors made three smart choices that make these survey chapters work better than similar chapters in other books:

  1. These are the right four choices to cover
  2. All the examples are the same Zip code lookup, so you can focus on the language and tool differences
  3. You don't have to wade through pages of setup instructions unrelated to Ajax

The futures chapter covers several emerging technologies and standards that haven't hit their stride yet, e.g. E4X, Canvas, and SVG. At least one of these technologies will be very important in the next generation of Ajax apps, but I am not sure which. :-)

Last Word:Pragmatic Ajax and Ajax in Action (reviewed here) complement one another nicely. As of today (May 3, 2006) I believe these are the two must-have books for Ajax developers.

May 03 2006


Relevance Review #7: Professional Ajax

Professional Ajax, by Nicholas C. Zakas, Jeremy McPeak, Joe Fawcett

Quick Summary:Emphasis on irrelevant Microsoft technology plus unlucky timing weaken an otherwise solid book.

Pro Ajax starts strong. The first chapter, "What is Ajax?" is a nice conceptual introduction. Chapter Two, "Ajax Basics", rightly treats the "A" in Ajax as the most significant evolutionary step. The authors work from basic HTTP, through frames, iframes, and XMLHttpRequest. Chapter 3, on Ajax Patterns, shows you a variety of ways asynchronous invocation can be used. Taken in isolation, Chapters 1-3 make a nice mini-book on Ajax.

Chapters 4-6 cover XML. These chapters are not nearly as useful as the first three, for two reasons:

  • The coverage is basic, and belongs in an XML book, not an Ajax book.
  • The conceptual clarity of the first three chapters disappears when the authors are talking about XML. Particularly mystifying is the coverage of Representational State Transfer (REST) on pages 163-166. A reader not already familiar with REST might come away thinking "REST is just like plain old HTTP, except you have to manage links with XLink."

It is nice to see a chapter on JSON (Chapter 7). The explanation is clear, and the authors quickly get to an important point: You don't have to eval JSON! You can (and probably should) use Doug Crockford's library to avoid evaluating arbitrary code in the browser.

Chapter 8 teaches how to create widgets. This chapter is worth reading, because it takes four examples from concept to working widget, including HTML, CSS, client-side, and server-side code. Most Ajax programmers will be widget consumers, but if you plan to be a widget author, or just want to understand how the pieces fit together, you will appreciated this chapter. Chapter 9 builds a more complete example (AjaxMail) and is also worth reading.

As you can probably tell from the individual chapters above, I wanted to like this book. And I do like the Ajax parts (about half the book IMO). The problem is the authors' approach to the server side. Ajax is a client side technology, but to use Ajax you need a server to talk to. This poses a problem for authors, who have to make a choice:

  1. Don't talk about the server side, and let readers make their own choices
  2. Pick a single server side technology and stick to it
  3. Present a variety of server-side options
The authors of Professional Ajax chose to present a variety of options. This approach backfires, as you have to wade through page after page of server-side configuration unrelated to Ajax. Here are some of the topics I found inappropriate in an Ajax book:
  • Configuring Microsoft IIS
  • Installing ASP.NET
  • Creating a .NET Web Service
  • Connecting PHP and MySQL using Microsoft ADO
  • Installing the Java SDK
  • Using Microsoft ODBC to connect to Microsoft Access from Java
There is a bizarre Microsoft bias here. I wouldn't be surprised by a book that said "We're gonna use .NET because it rocks." But what we have here appears to be an honest attempt to use a variety of different technologies, ruined by an unspoken assumption that servers run Windows.

Would the book be better if the authors dropped the non-Microsoft examples, and just came right out and titled it "Professional Ajax for .NET Programmers?" I think so. Unfortunately for the authors, the Microsoft world changed out from under them between writing and publishing. Microsoft's Ajax strategy now appears to be built around Atlas, which does not appear at all in Professional Ajax.

Last Word:Useful for developers building Ajax with yesterday's Microsoft technology. Would be nice to see a new edition of the book that covered Microsoft's Atlas.

Apr 26 2006


The Real Contribution of Rails

Ruby on Rails has had an enormous impact on the web application development ecology. Like a hungry non-native species without a natural predator, it has gone from interesting niche player to seeming world-beater nearly overnight. There have been many pontifications, discussions and arguments about the relative technical merits of Rails (and, by extension, Ruby) and how they stack up against the reigning king of the hill, Java.

It seems to this observer that these discussions overlook the primary contribution of Rails to the technical ecology. See, the technology ecology is a lot like the savannah. There are roving herds of developers of all stripes wandering out here in the tall grasses. I won't go all Bruce Tate on you and start making similes about which developers are which animals; just keep the picture in your head. Tall grasses, wandering developers. The problem with this idyllic picture is that there are a lot of sick, diseased animals out there in the savannah, but they drag down the herd and continue to consume valuable resources because they can hide in the tall grasses. You just can't spot which ones need to be culled.

This is where Rails comes in. Like a hunting call ("dynamically typed! dynamically typed!"), Rails flushes the weak, the diseased, the misinformed, and makes them stick their heads up over the top of the tall grass. Where they can be easily picked off by the avid hunters. People like James McGovern and his ilk, whose biases are so strong, whose allegiances so deeply rooted, that mere fact cannot be used to persuade them to keep an open mind. It is here that Rails excels.

To be clear, I'm not talking about bad developers. There are lots of bad practicioners of any craft; Rails won't highlight them (though it will do the converse, as I mention below). I'm talking about the people who claim to be deep thinkers and thought leaders but can't tell innovation from insulation, evolution from convolution. Rails makes those people say silly things that make it obvious that they aren't thinking critically anymore. (And, no, I don't mean "Java sucks, Rails is hawesome, anybody who disagrees with me is a dope". I mean, anybody who says things like "Rails isn't a good platform because Ruby doesn't have public and private members" is just making stuff up so they can take your money.)

But it is even better than that. Rails represents a lighter, meaner way to develop a certain kind of application. It represents a focus, an eschewing of clutter, a purity of vision. It is the kind of tool that can easily demonstrate which members of a team are technical professionals, and which ones are frustrated rock stars trying to pass the time until RCA calls.

And I'd like to make it clear that Rails isn't the first, nor the only, tool to provide this kind of leverage. There are many others; but there have been few, if any, to have the perfect storm of technical viability and incredible hype which enables it to penetrate the deflector shields normally raised around the IT departments of America.

So Rails really lets two groups peek up above the tall grass; 1) the weak and diseased, who get picked off for the greater good, and 2) the hale and hearty, who get voted to be King/Queen of the Herd. This is Rails' greatest contribution, the one that will last longest, because eventually Rails itself will be usurped and something else will come along to pick at its sun-bleached carcass. But the ecosystem it will have left behind will be healthier because of its contributions.

UPDATE: added bullet numbers to last paragraph to make clear what two groups I was talking about.

Apr 21 2006


Relevance Review #6: Ajax for Dummies

Ajax for Dummies, by Steve Holzner

Quick Summary: Very basic, uneven, a few painful errors. If you are looking for a very basic introduction, try Head Rush Ajax instead.

Albert Einstein famously said "Make everything as simple as possible, but no simpler." Ajax for Dummies tries to make Ajax too simple. As a result, the presentation is uneven, spending tons of time on really basic stuff, then darting past important complexities. In the first third of the book, truly basic questions are painstakingly answered:

  • What is an if statement?
  • What are variables?
  • What are browser events?

More complex concepts, necessary to understanding the examples, get minimal treatment later on. A few examples:

  • JSON is used in a few places but never identified or explained. (The sample code often creates multi-object arrays one line at a time.)
  • Objects, constructors, this, etc. get one paragraph.
  • Closures (not named as such) are explained in less text than the if statement gets.
  • The difference between false, undefined and null is never explained. (Judging from the source code, the author is not clear about the difference.)
  • JavaScript prototype is not explained (and is not a term in the index).

The other major concern with this book is the technical errors. I didn't spot many, but the few were significant.

  • On the difference between GET and POST (p.106): "if you use ... the GET method, your data is pretty public. As it zings around the Internet, it could conceivably be read by others. You can protect against that by using the POST method instead of GET". This is wrong in what it says, and in what it misses. (Google for "GET VS POST")
  • More GET abuse: The drag-and-drop example (p.192) shows you how to use GET to update a user's shopping cart.

The commitment to "wishing it simple" produces some misleading advice. With regard to code-centric Ajax, the author says (p. 114):

I'm not really an advocate of using JavaScript sent to you from the server in Ajax applications, except in one case -- if the server you're dealing with you gives you no choice.

He then proceeds to build an example that connects to Google Suggest, which returns its data as script. The reader is left to wonder why Google sends back script. Weren't they "dummies" enough to follow the author's advice? What the author doesn't know, or at least isn't telling the reader, is that the Google Suggest API is designed to support the dynamic script tag technique for cross-domain access without a server proxy. More realistic advice to the reader would be this:

(Hypothetical) The issues around whether and when you should use code-centric Ajax are far too advanced for this book, but here's how to do it anyway. P.S. Here's a loaded pistol; now go play outside.

Wrapup:Ajax is not for dummies.

Apr 21 2006


Ajax and Server Scalability: Theory and Practice

In theory, there is no difference between theory and practice. In practice, there is.

Ajax Scalability In Theory: Ambiguous

In theory, Ajax cuts both ways in terms of server scalability:

Ajax helps server scalability: Ajax server interaction is more flexible than page-centric interaction. That flexibility gives you better ability to optimize around whatever measure you care about -- including server load. Tim Bray makes a specific instantiation of this argument here.

Ajax hurts server scalability: Ajax lets us offer new and better services that we could not offer before. Those services are not free, but we accept the server load as a price of doing business. This is the argument that Billy Newport is making.

Ajax Scalability in Practice: Bad

Ajax encourages widespread adoption of a gizmo (XMLHTTPRequest) that facilitates hitting servers multiple times, with no user interaction required. "Widespread adoption" means that that average Ajax developer will not be an expert at distributed systems design. Even with experienced developers, mistakes will be made, and their damage can be magnified by Ajax. A few weeks ago I wrote a defective page whose symptom was duplicate requests to the server. As many as the browser would allow. As fast as it could. Forever. Luckily I write automated tests...

And the Winner Is... Server Vendors

I am not sure why everyone is spending so much time discussing the theory. After all, in both theory and practice, practice is more important than theory. In practice, Ajax is going to put a hurt on servers everywhere. This is not to suggest that Ajax is a bad thing, just that lots of people will do it badly.

Apr 21 2006


Relevance Review #5: Ajax in Action

Ajax in Action, by Dave Crane and Eric Pascarello.

Quick Summary: This is an excellent book.

I liked almost everything about this book. Some specifics:

  1. The authors have deep and wide experience designing and building Ajax applications, and this experience goes way back before the term "Ajax" was coined. The authors have been there, and are sharing hard-earned lessons.
  2. This is a book about ideas, not just a technical manual. The ideas start immediately in chapter 1, where the authors introduce their "defining principles" of Ajax. Chapters 4 and 5 are also "idea" chapters. Chapter 4 re-evaluates how MVC can/should work in an Ajax world. Chapter 5 discusses different data-exchange patterns that are possible with Ajax. Understanding these patterns is critical to designing an Ajax app, and they are poorly understood. In my travels I have found that most people are (unknowingly) using what the authors call "content-centric interactions". Usually they are surprised to find out that other patterns even exist!
  3. The case studies are detailed, and pull in a variety of useful concepts that are not specifically Ajax. Along the way you'll learn design patterns (3.2), refactoring (throughout!), reflection (4.5), and profiling (8.2). Some readers will find this information to be old hat, but with the popularity of Ajax I suspect many readers will be seeing these concepts for the first time.
  4. The ideas are nicely interwoven with technical detail. For example, Chapter 7 (Security) deals in specific technical details, e.g. the Mozilla PrivilegeManager, various workarounds for the "server of origin" policy, man-in-the-middle attacks, and public key crypto. But these details do not stand in isolation. Instead, they build up to a neat discussion of why coarse-grained APIs are easier to secure (7.4).
  5. As the authors state in 1.2.4, "[Ajax] is real coding and requires discipline." If you are writing Ajax you need take JavaScript seriously as a language, and know the tools you have available. The two appendices to the book provide exactly the information you need to get started.

The only negative I would point out is actually more of a call to action. Most developers should use an Ajax framework or library, and all developers should write tests. Unfortunately, there is not much book coverage (here or anywhere else) on either of these topics. Of course, the problem here is picking which specific things to cover: There are dozens of frameworks that you might cover, and several of them embed their own testing framework. I hope (and expect) that 2006 will see a new crop of books that target individual frameworks.

Conclusion:Ajax in Action will age well, and still be valuable when the next generation of Ajax books comes along. Read it, and keep it on the active shelf.

Apr 21 2006


Present-Proofing Your Web Application

The future is about scale?

The April 2006 issue of JDJ includes a short piece from Michael Juntao Yuan titled "Future Proof Your Web Application Using Clustered Cache Services."

Michael implies essentially the following argument:

  1. Compared to *anything else*, Java EE has easy clustering (most web apps need only flip a switch!). And there are lots of clustering choices.
  2. Clustering == Scalability
  3. Scalability == Future-Proofing

I like this argument, not because I agree with it, but because it got me thinking. Especially about #3, that (scalability == future-proofing).

The future is about change!

Future-proofing is about being prepared, so that future events do not render IT investments worthless. I worry about three categories of things that might happen in the future:

  1. We need to do exactly what we do today, but 100s of times more of it.
  2. We need to adopt up-and-coming techonologies. Right now a good example would be Ajax.
  3. We need to do radically new and different things

The first category is what Michael is talking about: doing lots more of what we already do. Certainly this is important, but usually it is the least important of the three categories. The most important is the last one: being ready to do new and different things. (Or am I wrong here? Which of the futures categories is important to you? What platform choices do these different categories imply?)

Who Cares About the Future?

The other thing I would call into question is future-proofing in general. Forget future-poofing, what most projects ned is some present-proofing! Make sure your entire development effort is systematically on-time, on-spec, and on-budget. Then, worry about the future. I know far too many projects that were always ready for the future, but somehow never got around to even shipping in any particular present.

Apr 13 2006


The View from Hell

I was on a client site today, integrating Rails' Continuous Builder plugin with an existing CruiseControl setup. We're pumping our own custom test reports out as well as rcov HTML reports, and shoving that all into the Build Artifacts directory. We wanted to make a couple of changes to the standard web pages that CC serves out, just to make the pages more suitable to our project. CruiseControl, being a Java app, uses JSPs for the view. Here's what I expect to find when I look at a JSP:

A JSP file that contains a mix of Java and static HTML, whose output is a bunch of HTML and maybe a little CSS thrown in for good measure.

Instead, this is what I find:

The CruiseControl JSP starts by slurping up some XML stored elsewhere and feeding it to an XSL stylesheet. The XSL spits out an HTML page, but the HTML has no HTML in it; its just a big JavaScript block. The JavaScript uses DOM manipulation to write out a combination of HTML and CSS. And some more JavaScript. Really. I'm not making this up.

Somewhere along the way, this must have either seemed like a good idea, or this represents the cruft of a hundred generations. But the sum total effect was that I was so intimidated, I couldn't change the pages even if I had still wanted to. Complexity as Force Field. Shields up, Captain!

Apr 12 2006


Prototype Presentation at the Ajax Experience

I will be giving a presentation on Prototype at The Ajax Experience. Actually, I will be doing several talks, but this is the one I am most excited about. Prototype makes Ajax and JavaScript fun, and is a great study in JavaScript style. The abstract isn't up over at TAE yet, so I am including it below.

Prototype: Ajax and JavaScript++

Prototype deserves its fame for Ajax support, and for easy integration with the Rails platform. In this presentation, you will learn to simplify Ajax development with Prototype as we work through a series of examples that demonstrate:

  • using Ajax.Request to manage XMLHTTPRequest
  • automatically updating pages with Ajax.Updater
  • polling with PeriodicalExecuter
  • managing forms with Form.serialize
  • responding to inputs with Event.observe
  • simplifying DOM updates with Insertion

But there's more! Prototype exemplifies modern JavaScript coding style. You will see how to take advantage of "Prototype as JavaScript++" by

  • using JSON for parameter passing
  • defining classes with Class.create and Object.extend
  • using Ruby-inspired extensions to the JavaScript object model, such as Array.each

Apr 12 2006


Relevance Review #4: Head Rush Ajax

Relevance Review #4: Head Rush Ajax

Head Rush Ajax, from O'Reilly, by Brett McLaughlin.

Quick summary:Fantastic introduction to the basics of Ajax if you can stand the format. Have one copy for your team and hand it to the new programmers during their orientation.

The Head Rush (and Head First) series are wildly popular. I can't argue that. What I can't figure out, really, is why. I'll let my wife explain it for me. Honey?

My wife: Is that the next book you are reviewing? You're only on page 3. You're going to be up a while.

Me: It sure is. Head Rush Ajax. Nifty title, no?

My wife: I guess. Hey, tell them to get rid of the picture of that goofy guy over in the margin.

Me: Uhhhhh....(flips through rest of book really fast to demonstrate goofy guy on every page)

My wife: Don't people find that insulting?

Me: Uhhhhh........(doing best Butthead impersonation)

Yes, this is an homage to the Head Rush conversational style...its like a meta-review, see?

So, these series use informal language, tons and tons of pictures, lots of diagrams, and every font in the I-just-discovered-the-font-menu-in-Word-2003 pantheon. They explain this up front by saying that your brain really only pays attention to tigers. And Comic Sans, apparently. And, honestly, I can't argue with Brett or Kathy Sierra on this: they've sold a ton of books, and people seem to dig it. Let's just say that I could have used one less picture of the Project: Chaos guy who looks like a well-armed Devo fan.

As for content, it is hard to imagine a book that nails its target audience better. They say the book is for the programmer who has done a lot of HTML, and a little JavaScript and CSS, and no Ajax. They specifically say it isn't a reference book, nor for advanced programmers. They are right on both counts. Which is why we recommend having a copy to hand to every fresh face your Web 2.0 startup hires straight out of middle school or the J2EE Enterprise ecosystem.

I actually love the technical content here. Its a perfect primer for Ajax. They cover:

  • creating XMLHttpRequest objects across all browsers
  • Invoking them asynchronously and synchronously (with bonus material clearly delineating the two)
  • Harvesting the results while checking for readystate and status codes
  • Utilizing XML as the request/response payload
  • Extensive DOM navigation techniques
  • How JavaScript is loaded and parsed in a page execution context
  • JSON vs. XML for data transmission
  • Security issues like SQL injection and rogue eval() calls

It is the perfect beginner's mix of how to get stuff done without screwing up. In addition, the code is robust, and the descriptions are filled with helpful tips about the kinds of status codes you might expect, how to defeat IE URL caching, and little stuff that drives the beginning programmer crazy because they are hard to Google.

Unfortunately, because of the format, it takes a whopping 395 pages to get through that list, while another book would probably do it in under 50. Which is why, having read it now, I'll not crack its glossy, shiny, brightly colored cover again, much as I enjoyed the author's writing style, wit, and dedication to his craft.

Finally, at the end, there is a brief introduction to the idea of Ajax toolkits with a half-page example of "using" each. They hit the right candidates: Prototype,, Dojo and Rico, but they only focus on the abstractions wrapping around XMLHttpRequest (in Prototype and Dojo) or simple DOM access ( and Rico) without even mentioning that these libraries do so much more. Dojo, in particular, needed at least a sentence describing it as the most ambitious JavaScript library ever created.

Probably the only other downside to this book is that all the server code is PHP. There is nary a mention of other server-side possibilities, and therefore no examples, either. Which means the text doesn't even mention the possibility of other kinds of Ajax apps (using remoting, or even code-centric Ajax). They also, strangely, don't mention SAJAX or XOAD, the two major PHP Ajax toolkits. If you're going to do an entire book on PHP and Ajax, and then have an appendix listing Ajax toolkits, it seems appropriate to mention the shaded part of the Venn diagram.

In all, I'd highly recommend this book to the new learner. Said learner should definitely have a little HTML background and have written at least a couple of lines of JavaScript. No CSS or DOM experience required. At the end of the book, that developer will be able to write simple Ajax apps, understand the value of Ajax frameworks, and draw a tiger from memory.

Popular Tags