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.

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.

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.

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 need 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.

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.

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!

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

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, Script.aculo.us, Dojo and Rico, but they only focus on the abstractions wrapping around XMLHttpRequest (in Prototype and Dojo) or simple DOM access (Script.aculo.us 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.

This is a review of Foundations of Ajax, from Apress. Full disclosure: I have met, and really liked, Nathaniel Schutta, not least of which reason is he quotes me.

Quick summary: Chapters 5-7 worth the cover price. Rest of the book could be shortened, and replaced with more of chapters 5-7.

The Foundation series from Apress seeks to give readers the fundamentals of a given technology. This book delivers very literally on that premise; perhaps too literally. The authors give the readers a long treatise on writing Ajax code using raw JavaScript while ignoring all of the higher-leverage frameworks that are typically employed. While instructive, it leaves the book feeling somewhat less than practical.

Chapter 1 is a history of the Universe through the lens of distributed programming. As a person who has tried to deliver that story in front of a live audience, I can readily attest that such a history is often lacking in detail and perceived as redundant by the audience. This chapter suffers from those problems, and while interesting, would have been better as a prolog than a whole chapter.

Chapters 2 and 3 introduce and explain the usage of XMLHttpRequest. These chapters are both the central premise of the book, and its greatest weakness. The authors explain in detail the vanilla JavaScript required to invoke the XHR object, to interact with the request/response streams, and to navigate the DOM (of both the web page and the response data). This is where the authors choose not to discuss the Ajax frameworks that can help you with the boilerplate code, and instead focus on rolling your own. And we really like for folks to understand the inner workings of a technology, so I say 10 out of 10 for effort. The balance of code and explanation is also spot on, with just enough of each to keep the reader interested.

However, there are some problems. The code presented in these chapters is brittle. The authors gloss over some rather important complexities. I’d give them a pass if they were then introducing frameworks that took care of the complexities for you; but since they don’t, it would have been nice for the code to go into more detail. Examples are ignoring the MSXML version of XHR when showing cross-platform invocation, failing to account for multiple concurrent asynchronous requests, and robust error handling. In the last case, the authors show how to inspect the status code of the XHR response, but don’t examine issues like request timeouts and corrupt data.

Chapter 4 really starts to pick up. This chapter introduces a ton of Ajax techniques in code format. It shows, in detail, how to implement your own Ajax effects like auto-complete fields, page polling, interacting with web services, and many more. The code is useful, but perhaps more useful is the effect of seeing so many techniques laid out for you, expanding your idea of what is possible in your web application. Very well done.

Chapters 5-7 should be mandatory reading for every Ajax programmer. These chapters lay out the toolkit of the series Ajax developer, introducing and explaining the uses of tools like: JSDoc, for code documentation, JSLint for error checking, JSUnit for testing, Venkman and the Microsoft Script Debugger for stepwise debugging, and a slew of tools for helping verify your XHTML/DOM/CSS. These chapters show how to treat JavaScript with respect and act as though it is a real programming language, which is exactly what it is.

In all, I think the book’s code focuses too much on plain JavaScript to be really useful for a working developer, and if the code-focused chapters had been condensed to a single chapter to make more room for extra details about the toolset introduced in 5-7, the book would be much stronger. However, it probably wouldn’t have been a good fit for the Foundation series, then, so it is hard to fault the authors. Recommendation: get the book, read the first half, and live the second half.

This week, I am off to Vancouver to teach Ruby on Rails Today’s in-plane reading is Bruce Perry’s Ajax Hacks, published by O’Reilly.

Quick summary:Chapters 4 and 9 are excellent and may justify buying. Skip the rest.

The “hacks” format breaks the content of a technical book into (in this case 80) individual entries. As I mentioned in an earlier review, I like this format because like most developers I learn best by example.

Unfortunately, the “hacks” metaphor breaks down in this book. Chapters 1-3 are not really hacks at all; they are mostly a raw-JavaScript Ajax tutorial, disguised as hacks to fit their form of the book. This is unfortunate because inexperienced readers may choose to use “intermediate” steps of the tutorial as “final” hacks in their applications. We have a bunch of great Ajax libraries; very few people should have to write raw-JavaScript Ajax. That said, it is definitely still worth learning raw JavaScript Ajax. You should always understand one level of abstraction underneath your primary work. Once you’ve learned, pick a library for your production work.

Chapter 4 (“Power Hacks for Web Developers”) is much better—a grab bag of techniques that will have something new for most readers, even if they have Ajax experience. This chapter also benefits from multiple authors, as you get to see different stylistic choices being made. Also, this chapter encourages more thinking about “what can I do?” instead of just “how can I do it?” There are several examples of mashups that combine existing web services under a single Ajaxy front.

Chapters 5-8 cover a variety of Ajax libraries: DWR, Prototype+Rico, Ruby on Rails, and Scriptaculous. First let me say that I think the choice of which libraries to cover is spot on. The only obvious omission is Dojo, and Dojo is so big and ambitious that a chapter overview in “hacks” format would be useless. And that leads me to the problem: These chapters are not collections of hacks, rather they are introductory chapters that have been wrestled into a “hacks” format. All of these topics have much better coverage online and in other books (which I will be reviewing as this series continues).

The Rails and DWR chapters have particular issues: Chapter 7 (the Rails chapter) is way behind on Rails, claiming coverage of Version 0.9.4. Thomas and Hansson’s excellent book Agile Web Development with Rails has a more up to date Ajax chapter, despite having a publish date that is nine months earlier. The DWR hacks (Chapter 5) miss almost everything that is cool about DWR. Hack #48 demonstrates accessing a custom object by having the object store values in a Map and do its own toJSON work. There is no mention of DWR’s ability to automatically marshal real-world Java beans, which are typically not backed by Maps. Hack #49 commits the cardinal sin of RPC, doing in multiple roundtrips what could be done in one. This is ironic, since DWR supports a batching operation which automates doing the right thing.

Chapter 8 rocks. Read it. Hacks #68 and #69 demonstrate not one, but two, different ways to “fix” the back button in Ajax applications. #70 adds timeouts to Ajax invocations. #75 and #77 begin to embrace the browser as its own MVC environment, creating client side caches and search indices. This is almost the opposite of what most people think of Ajax—using the flexibility of JavaScript to reduce communication with servers. Finally, my personal favorite, #73, clearly explains how to use dynamic script tags to cheat the browser security model, letting one page invoke services from multiple domains. (Use with caution, of course.)

In summary: Intermediate to Advanced Ajax developers should read chapters 4 and 8, and beginners should read something else.

Over the next two weeks, we will be reviewing Ajax books, and putting together our list of “must-have” books for developers. The first review is already posted here. We’ll be raffling off a set of the must-have books at the next run of the Pragmatic Studio: Ajax

Let us know what books you’d like to see reviewed.

My in-plane reading for the NFJS Omaha trip was the recently published JavaScript Anthology from SitePoint. I picked up a copy specifically looking for resources to recommend to Ajax developers.

There is a lot to like about this book:

• The authors clearly know their stuff, and in detail. Everything is demonstrated with code.
• The individual tips are well-organized, with a statement of the problem, solution, and discussion. I found the format easy to skim (for stuff I already basically knew), and easy to dive in where necessary.
• The authors provide lots of links to additional resources.

More than half of the book is devoted to effectively using the APIs that are present in a modern web browser, for manipulating the Document Object Model, forms, windows, ranges, DHTML, CSS, XHR, etc. These items will be of great value to anybody who has to write effective JavaScript in the face of browser variabilities. Most of the tips are captured as JavaScript procedures which you can easily adapt for your own programs.

Relatively less time is spent on the language itself—the intro chapter, plus concluding chapters on OO and performance. While these chapters are reasonable as far as they go, I wish they went a lot farther. Like most authors writing about JavaScript, the authors sound a bit apologetic in comparing JavaScript’s prototype-based inheritance to class-based OO. There’s no need to apologize! JavaScript provides very powerful abstractions. The best Ajax developers are embracing these abstractions, without constantly looking in the rear-view mirror at classes.

The most troubling part of the book, particularly for an Ajax developer, is the disconnect between the “procedural” style of most of the sample code, and the object-based (and functional) style of JavaScript you will see in libraries such as Prototype. Hidden in the Ajax wave is a set of programming techniques which go far beyond Ajax in their utility and importance:

• closures
• internal iterators
• metaprogramming
• AOP
• Duck Typing
• Functional Programming

You won’t find much on these topics here. In fairness, I am not aware of any JavaScript book that hits these. Your best bet for today would probably be to learn Ruby and transpose Ruby->JavaScript in your mind.

To sum up, this is a well-organized, solid book. It will be most useful for people writing and supporting “raw” JavaScript. Most Ajax developers should be using libraries to handle much of this low-level detail. That said, you always need solid knowledge of at least one level of abstraction beneath the one where you are working. Read the JavaScript Anthology to learn that next level down, and stay tuned for future reviews where I’ll cover some books that target Ajax more directly.