Ajax Design Patterns 39
pankaj_kumar writes "A number of AJAX libraries and frameworks have emerged to purportedly simplify development of rich Internet Apps. None of them however can substitute a good understanding of what the recurring problems are, the potential solutions and what goes on behind the sleek facade of a browser to power these Apps . Michael Mahemoff, author of Ajax Design Patterns, said this best in his blog which became a popular wiki entry and later, this book." Read the rest of Pankaj's review.
| Ajax Design Patterns | |
| author | Michael Mahemoff |
| pages | 635 |
| publisher | O'Reilly |
| rating | 9 |
| reviewer | Pankaj Kumar |
| ISBN | 0-596-10180-5 |
| summary | Creating Web 2.0 Sites with Programming and Usability Patterns |
The Ajax Design Patterns book, with its more than 70 design patterns, documented in more than 600 pages with encyclopedic detail, is very effective in presenting the AJAX programming knowledge in a reader friendly format. In the spirit of seminal GoF Design Patterns work, it captures the essence of each of the topics with problem solving approach — first stating the problem in general terms and then presenting the solution, outlining the approach and discussing variations, alternatives, trade-offs and even listing actual uses in real applications. Btw, if you noticed I used the term topics in the previous sentence to refer to its 70+ "knowledge modules" and not patterns, mostly because I wouldn't categorize all of them as patterns. However, this disagreement on terminology doesn't take away anything from their practical usefulness and, for sake of consistency, I would continue calling them "design patterns".
A bit on scope and level of material presented in the book — most of the material is quite advanced and assumes good knowledge of technologies for writing web based applications: HTTP, JavaScript, (X)HTML, CSS, PHP and a bit of W3C DOM. The code fragments, and there are quite a few of those, are in JavaScript (for client side) and PHP (for server side). Most of the prominent AJAX libraries, toolkits and frameworks are also mentioned, often while discussing a particular pattern as a reference of actual use. The appendix lists them all at one place and highlights their main features. Though, the book carefully avoids to recommend any one as 'The AJAX toolkit'.
The book categorises the design patterns as Foundational Technology Patterns (those related to repainting the user interface, browser and web server communication, and event handling), Programming Patterns (those related to programming aspects of either end, browser or the service, of the application), Functionality and Usability Patterns (those related to functional widgets such as slider, data grid, progress indicator etc., page layout, visual effects and so on) and Development Patterns (those related to debugging and testing). Of course, the real value is in the details of each pattern, and not just the high level categorization or overview.
A reader of this review may be interested in knowing why should he or she buy the book when most of the content is freely available at the Ajax Patterns Wiki. Here is my take on this: although most of the content is available on the Wiki, the text in the book has gone through professional editing and is more readable. Also, the description of most of the patterns run into multiple pages, and it becomes hard to read long articles while connected to the Internet (I tend to click on links and wander away). As an additional bonus, the book includes illustrative diagrams, which I found quite helpful, and at times, funny. Most of the patterns included in the book taught me something new, I did end up with a list of favourites after finishing the book in less than a week: XMLHttpRequest Call: One of the most comprehensive treatment of XMLHttpRequest object and its various use patterns, limitations and alternatives. On-Demand JavaScript: How to do lazy loading of JavaScript code to improve responsiveness or get data from a different server. HTTP Streaming: How can a server keep sending data to the browser over an HTTP connection initially established by the browser. Call Tracking, Submission Throttling: How to protect your server from excessive load by very active users without compromising responsiveness. Browser-Side Cache: Ajax doesn't solve the inherent latency problem of the Internet. You still need the good old tricks to improve the user experience. Malleable Content: How to let the user edit some information on a mostly read-only page. One-Second Spotlight, One-Second Mutation: How to communicate change in a portion of the page without being obtrusive. Direct Login: How can you improve the user experience as well as the security of authenticating user using Ajax and JavaScript wizardry. Unique URLs: Going Ajax should not require your users to abandon joys of hyperlinking and the old and tried habits of navigating content by clicking on the familiar back and forward buttons.
So far I have only been talking about things that I liked but there are some things I would consider weak spots. I noticed a few minor typographical issues with certain code fragments, but they are rarely serious. For example the first code fragment on page 96 has uses variable requestTimer to store the return value of setTimeout() and then uses variable requestTimeout as argument to clearTimeout().
A good addition for a future edition could be patterns on AJAX program performance during development, deployment and runtime such as JavaScript compression to improve download times and execution speed and considerations on using multiple third party JavaScript libraries.
Another thing I found a bit annoying at times is presence of a lot of URLs all over the text with hints too brief to allow uninterrupted reading away from the computer. I would have preferred numbered footnotes, either in each page or at the end of each pattern, with URLs and a brief summary of its contents. Usually I read printed books when away from the computer and do not wish to go to the computer and type-in the URLs to just understand what is being said in the text. Although immensely helpful during online viewing, the embedded URLs are a hinderance during offline reading. This is one area where the structure of printed content should be different from the online content.
Overall, I would recommend the Ajax Design Patterns to all those who work or aspire to work on web development projects as an excellent reading and reference resource.
You can purchase Ajax Design Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
The Best Book Covering AJAX (Score:4, Informative)
Unfortunately, I've plunked down money for a bunch of hardcopy books on AJAX and the new fangled javascript tidings — yes, I know I could find most of the requisite documentation online and/or I even question the silliness of amassing a library over a simple API call and a few demonstrative examples. But if I were to choose one book to buy or keep on the subject, this would be the one, easily.
Why? Well, because the author takes a problem centric view after a basic tutorial (i.e., how to handroll your own remoting, simple code examples). Then, all the things you can do with the tools are detailed, within a templated question and answer framework, and unlike the reviewer here, I appreciated the inclusion of all the URLs so I could research further. Also, a big part of learning anything is just getting the terminology down, so that those can serve as "keys" for subsequent knowledge acquisition. Also, the author doesn't seem mentally tied down to a given platform (take note .NETers and Rubyists) and explains things from a purely algorithmic perspective.
This is a worthy title for anyone wishing to expand their AJAX knowledge, though if you're totally comfortable with online discovery, you could forego it.
Save $13.95 by buying the book at Amazon.com! (Score:0, Informative)
Save yourself $13.95 by buying the book here: Ajax Design Patterns [amazon.com]. That's a total savings of 31.01%!
Link to the AJAX design patterns wiki (Score:2, Informative)
Re:Whacky AJAX (Score:3, Informative)
Even the low level toolkits are still in their early stages, shaking out the initial design concepts and best approaches. So the situation in the higher level/GUI toolkits is going to be much worse. There's a very high risk of investing considerable code and project time into a toolkit only to discover that either it just doesn't fit with the project, or that the toolkit is still too quickly evolving to be a stable target.
That rapid evolution is a symptom of something that's going to bite you in the arse: they haven't got them right yet! If they'd got it right, then the evolution would slow down.
I've personally made a degree of use of the Prototype library, and become increasingly disillusioned with it when compared to the competing jQuery library. jQuery appears to be a much more elegant and future proof take on the problem.
I've also put a fair amount of code into making use of the event:Selectors library which I have subsequently completely thrown out.
My policy now is to only make use of the very minimum from the available libraries, while keeping a close eye on their development. AJAX/DHTML is reasonably light on lines of code anyway, so it's not as if you really *need* toolkits to get you through the projects. Eventually the best of breed toolkits will shake out and it'll be obvious what to use, when, and where. But that time hasn't come yet.
Re:"Disagreement on Terminology" (Score:3, Informative)
That's because you don't know what a pattern [cambridge.org] is. Note that nothing in that definition, that a pattern is "a particular way in which something is done" in any way references computing.
A pattern is a way of doing something, a common solution to a common problem. That even applies to knitting patterns - the problem is that you have wool and no jumper, you follow the pattern, you have a jumper. Nothing about the GoF book makes them C++-specific - in fact, most patterns are entirely language-agnostic. To claim that AJAX isn't "complicated enough" to deserve patterns is to fall foul of language snobbery.
Besides, who needs a book to learn AJAX?
People who don't yet know programming (or XML, etc) and want a single reference to learn from? I've known some truly great designers who wanted to get into client-side scripting, etc, but who had so far had little or no exposure to programming. Believe it or not, some people manage to make a good living doing useful work without ever touching a compiler or interpreter...
Re:"Disagreement on Terminology" (Score:3, Informative)
Now THIS is flamebait: Your post sounds like it comes directly from the "I've never done it, so it can't possibly be hard" school of thought.
See the difference? In the latter instance, I'm questioning your competence in a none-too-subtle manner, in order to evoke a heated emotional response. Aside from the "Okay, smarty" (which seemed pretty justified given your apparent belief that AJAX techniques can be fully mastered in fifteen minutes by a drooling monkey), the guy was just explaining his position.
I'm sure you're a top-notch programmer, and your approach to application design serves you very well. But what's up with this axe you're obviously grinding against all things AJAX-y?
>> I'd roll my own. If I really needed to write an application that constantly transferred huge amounts back to the client, it'd probably be a clue that a proper desktop client/server app would be a better architecture.
Of course, that loses all the advantages of developing it as a web app: no installation, multi-platform, the ability to access your data from just about any computer, etc. I don't see the advantages of a desktop app, unless the data being worked with changes infrequently enough to do client-side caching. But regardless, there are times and situations when you really want the sort of minimal barrier to entry that you can get with a web application.
Re:"Disagreement on Terminology" (Score:3, Informative)