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.
"Disagreement on Terminology" (Score:3, Insightful)
...Because the seminal GoF work called them "design patterns". And in that book, they most certainly are. I just don't put Usability "patterns" in the same category as the GoF patterns; the scope and abstraction of the recurring problems are not even close to being on the same level. I don't think that it's about "consistency", but rather a simple word play to put AJAX programming on the same level as C++. Sorry, AJAX just isn't that complicated, and trying to make it sound big and complicated is just more Web 2.0 hype. Besides, who needs a book to learn AJAX? Unless I missed something important, a few paragraphs and a couple code samples explain things just fine.
mandelbr0tRe:"Disagreement on Terminology" (Score:3, Insightful)
Re:"Disagreement on Terminology" (Score:4, Insightful)
Just because they are applied to a different concept, it doesn't mean that they aren't patterns. If you object to the leap from programming to usability, then surely you must also object to the term being used for programming in the first place, seeing as the term "design pattern" originated not in computing, but rather in architecture [wikipedia.org].
The basic concept of a design pattern is that there's a standard approach to solving a common problem, and you describe it and name it. By giving them names, you can talk about the thing you are working on at a higher level and you don't need to worry about the specifics as much when thinking about the overall project architecture. The term "design pattern" is valid for many different areas, basically anywhere where there's something too complex to keep entirely in your head in one go. As part of a web application, various solutions to usability problems certainly qualify for the "design pattern" moniker.
Re:Most commercial AJAX apps have serious problems (Score:2, Insightful)
Every single criticism here applies not just to typical Ajax applications, not just to typical web applications, but to typical applications. The software development industry is not focused on quality, thus quality is rare. You mention that you currently use Perl and Java-based systems. Do you write off these Perl and Java-based systems because abysmal systems have been written with those languages as well? No, you judge each application on its own merits instead of assuming that just because the average developer is incompetent that all developers using those systems are.
Now how about you stop copy & pasting this troll in every story that mentions Ajax?
Re:"Disagreement on Terminology" (Score:4, Insightful)
AJAX is distributed computing. Distributed computing is hard. Ergo, AJAX is hard. If you're building a real application and not just adding flaming and spinning icons to a web page, you are doing nothing conceptually different than any other remote procedure call. The problem is, most people don't know how to write software in any language that handles that environment well. I know because I usually come in an clean up after them. I've had to do it in just about every language and with every rpc protocol. It's the same mistakes everytime. Your comment is like saying C++ isn't that complicated because it's Java without automated memory management. First of all, AJAX is a PITA to debug, you may have to step through code in a number or separate environments in order to debug a single round trip, like all rpc calls. GWT makes this easier, but that's done by having the programmer develop the client side code in the same environment as the server side code and coming with it's own special debugger. Avoiding more debugging and having to debug really hard to find problems is the point of understanding patterns. I'd much rather see the new AJAX dev on the team reading this book instead of AJAX in 24 hrs or something.
Besides, who needs a book to learn AJAX? Unless I missed something important, a few paragraphs and a couple code samples explain things just fine.
Ok smarty, which AJAX framework would you choose? GWT, J2Script? Would you handroll your own? What sort of data structures were you planning on using to get the data across the wire? Should your AJAX calls be fewer in number with larger payloads or would your application benefit from many calls with small payloads?
The AJAX environment may not cover the scope of the C++ one, but that doesn't mean that anyone is going to walk in and start using it properly. I doubt you can claim that you've never had to scrap an unworkable design. Due to AJAX's limited scope and nature, rpc calls from JavaScript, it is entirely appropriate to emphasize good distributed computing patterns. It's no different than a book on CORBA in C++ that discussed patterns. Web Services, both AJAX and SOAP, are CORBA and RPC all over again. That's why SOA is just Same Old Architecture. The patterns are mostly the same, it's just different capabilities and different transports.
Re:Whacky AJAX (Score:3, Insightful)
In other word, for a long time, commercial backup will be required. That means things like ASP.NET Ajax (Atlas. Note: Microsoft, stop working on fancy Ajax things, as nice as they are, and fix add display:table-cell to IE already), ComponentArt, Telerik, and so on (just to name a few: I am not familiar with commercial offering in other languages, as they tend to be slightly rarer, for obvious reasons) tend to work better than the "Free" (as in freedom) counterparts.
Open source projects especialy, strive because of the interests developers have in their projects. But making a widget/ajax toolkit, is plain and simple, not fun, for the majority of programmers. Its one of the worse environment (among the mainstream ones) to work in. Thus you need paychecks to further them. Obviously, considering there are a lot of open toolkits, SOME people find it interesting. Just not enough to do something thats reliable in a mission critical environment (admitedly, while SOME, and not all, commercial offerings are there, they are only barely).
Thus, as sad as it is, google around, take out your credit card, make sure you pick a vendor that has some kind of garentee/priority support, and go for it. And if its for an internal app, use something like Flash/Flex, or anything that can get you away from the horrors of xhtml/css/javascript.