Slashdot Mirror
Ajax Design Patterns
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 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.
In my opinion, Spaghetti design pattern is the most important AJAX design pattern: :)
It may look like a mess. But, it works somehow and it tastes good as well
The latter being an example of something that really could not exist with Ajax. Amen! :)
...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.
mandelbr0t"Please describe the scientific nature of the 'whammy'" - Agent Scully
AJAX applications just aren't solid or stable, for the most part. We tried to integrate a number of them into our network here, and frankly each attempt went terribly. I'd like to think it was just one application vendor or AJAX toolkit that was problematic, but that wasn't the case.
= 17491660
We found a number of common problems with every AJAX application we tried. Just for the record, the applications included three CMS systems, a Web-based email system, two groupware systems, and three Web forums.
The first major problem with one of resource usage, on both the client-side and the server-side. Client-side, many AJAX applications consume far too much CPU time. From our investigation, it was due to the use of poor JavaScript algorithms that'd consume 100% of the CPU in some cases, for minutes on end. The applications "worked", in that they'd provide the correct result. It'd just take them far too long to get it done.
On the server-side, they'd again result in excessive CPU and RAM consumption. For one of the Webmail systems, we could only handle a fifth (yes, 20%) of what our old Perl-based system could. And that was on a quad-core Opteron system with 8 GB of RAM! The Perl-based system was on a couple of 200 MHz Pentium systems, each with 128 MB of RAM. Even after assistance from the AJAX-based Webmail system's vendor, we were only able to handle roughly 90% of the number of transactions of our older system.
The second major problem is that of usability. Many of the AJAX apps we tried didn't play well with browser tabs, for instance. Some even fucked around with text input areas, resulting in copy-and-pasting no longer working. One application even prevented the text within a text field from being highlighted! We thought these problems may be browser-specific incompatibilities, be we ran into this same problem with Firefox, Safari, Opera, and even IE6! After talking with the vendor, they admitted these were known problems, and no solutions were presently available.
The third major problem is a lack of quality. Many AJAX applications are poorly coded and poorly designed. I think the main reason for that is because it's such an unstructured technology. Even competent software developers run into problems that cannot be solved easily, and thus must resort to hackish techniques to overcome these inherent problems.
The fourth major problem was that the users hated the systems. Of the few systems we managed to roll out successfully, the users absolutely hated them. Their complaints were a combination of the above three factors. The AJAX applications would not do what the user wanted. The AJAX applications did not conform to common practices (eg. copy-and-paste, textbox text selection, etc.). The AJAX applications ran far too slowly, even on fast client machines. The AJAX applications just plain didn't work!
All of our AJAX trials were abysmal failures. That's why we're sticking with the existing Perl- and Java-based systems that we currently use. They perform far better on much fewer resources, actually do what the users want, avoid violating the most common of conventions, and they do what they're supposed to. I'm sorry to say it, but AJAX might just be the worst technology I have ever had to deal with.
http://it.slashdot.org/comments.pl?sid=215452&cid
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.
AZspot
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?
Bogtha Bogtha Bogtha
Do you write off these Perl and Java-based systems because abysmal systems have been written with those languages as well?
I think he writes off the Ajax systems because it seems that _every_ Ajax application they tried has some pretty serious problems. The performance issues of that one app he mentions really highlights this. After trying eight or ten or however many products using a certain technology from different commercial vendors, and then finding that they all exhibit the same sort of problems, I'd think the technology itself may be at fault.
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.
"Bad developers" are often said to be responsible for all the awful Ajax apps out there. But I don't think that's the right answer. I don't doubt that there are some bad Ajax developers, but even really great developers with years of experience and a lot of talent have a difficult time putting out good Ajax apps.
It can't be disputed that the crew at Yahoo! knows a lot about what it takes to develop and run a popular web-based email system. But their new Ajax-based Yahoo! Mail implementation is quite awful. It's slow, it interferes with multiple browser tabs, and it's hard to use. Their old system was a lot faster, compatible with multitabbed browsing, and more enjoyable to use. Plus I could use it with Lynx, which I can't do with the new Ajax version. So I think it's more a case of great developers being hindered by a sub-par technology. In this case, that technology is Ajax.
Barnes and Noble is selling this book for $44.99, but Amazon.com is only selling it for $31.04!
Save yourself $13.95 by buying the book here: Ajax Design Patterns. That's a total savings of 31.01%!
More I learn about it, less I want to use it..which is a conundrum because I am developing a project especially meant to use it. It seems that AJAX goes well with entire GUI toolkits so I started with simple transactions and then eventually fell victim to all the shiny features of Dojo - and then got horrified when things started acting like they shouldn't. For example, a nested element causes a to lose the cursor while typing. I don't know how to resolve that -- but -- going back to the drawing board ought to be the way to go.
What are some of your experiences with using AJAX toolkits like Dojo?
AJAX Patterns
From the review, looks more like it should be called BORAX Design Patterns because every time I hear the term AJAX I find myself involuntarily yawning.
From the review, looks more like it should be called BORAX Design Patterns because every time I hear the term AJAX I find myself involuntarily yawning.
Then you'll love "Agile Ajax Design Patterns 101 in Seven Days for Dummies in a Nutshell Super Bible Unleashed for Web 2.0"
Table-ized A.I.
heres a pattern:
First comes the "next cool way to do it."
Then comes the ide.
Cue the testing tools.
Untill theres a library way out in front, I'm just gonna keep learning selenium.
.sigless since 2003
The reason why Ora doesn't have such is that AJAX is basically Javascript topic, you don't need a book for it, nor you can't write one. Buy a good javascript, XHTML, XML, CSS book and you are fine.
Black holes are where God divided by zero.