Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ajax Design Patterns

samzenpus posted more than 7 years ago | from the read-all-about-it dept.

Book Reviews 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.

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.

cancel ×

39 comments

Update on the link (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17545084)

The review links to B & N, but it seems that Amazon has it considerably cheaper [amazon.com] (see the "Used and new..." listings). Why does Slashdot consistently link to an online store that is one of the most expensive around?

the most important AJAX design pattern (1)

AtomicBomb (173897) | more than 7 years ago | (#17545142)

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 :)

Re:the most important AJAX design pattern (1)

CastrTroy (595695) | more than 7 years ago | (#17545874)

Plus, you wouldn't want everyone analyzing you JavaScript code and figuring out how your application works.

Most commercial AJAX apps have serious problems. (0, Troll)

Anonymous Coward | more than 7 years ago | (#17546234)

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.

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= 17491660 [slashdot.org]

Re:Most commercial AJAX apps have serious problems (2, Insightful)

Bogtha (906264) | more than 7 years ago | (#17546380)

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:Most commercial AJAX apps have serious problems (0)

Anonymous Coward | more than 7 years ago | (#17546644)

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.

Re:the most important AJAX design pattern (1)

Overly Critical Guy (663429) | more than 7 years ago | (#17547236)

Ugh, I thought we were rid of the term "AJAX" by now.

Ajax Design Patterns (1)

gavinpquinn (1026592) | more than 7 years ago | (#17545288)

I think Ajax is a beautiful thing. I really do think the web has taken a turn for the better with sites like yahoo [yahoo.com] , Flickr [flickr.com] and Grapheety [grapheety.com] .

The latter being an example of something that really could not exist with Ajax. Amen! :)

"Disagreement on Terminology" (2, Insightful)

mandelbr0t (1015855) | more than 7 years ago | (#17545336)

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

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

Re:"Disagreement on Terminology" (2, Insightful)

boldtbanan (905468) | more than 7 years ago | (#17545454)

And that's really what this seems to present. The designs described on the associated website (I haven't seen the book) aren't "patterns" in the OO/GoF sense but more like templates/methods for solving specific problems. I think the author is using "patterns" as a buzzword here to draw more attention.

Re:"Disagreement on Terminology" (1)

truthsearch (249536) | more than 7 years ago | (#17545628)

Sounds like "recipes" might have been a more appropriate choice of words.

Re:"Disagreement on Terminology" (1)

revelous (1048792) | more than 7 years ago | (#17545748)

isn't that what ajax is basically about?

Re:"Disagreement on Terminology" (1, Funny)

truthsearch (249536) | more than 7 years ago | (#17546030)

If you use ajax in your recipes I'm definitely not ever coming over to your house for dinner.

Re:"Disagreement on Terminology" (3, Insightful)

Bogtha (906264) | more than 7 years ago | (#17546244)

I just don't put Usability "patterns" in the same category as the GoF patterns

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:"Disagreement on Terminology" (3, Insightful)

GOD_ALMIGHTY (17678) | more than 7 years ago | (#17548148)

Sorry, AJAX just isn't that complicated, and trying to make it sound big and complicated is just more Web 2.0 hype.

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:"Disagreement on Terminology" (1)

mandelbr0t (1015855) | more than 7 years ago | (#17548434)

Obvious flamebait, but what the hell.

AJAX is distributed computing. Distributed computing is hard. Ergo, AJAX is hard.

AJAX is a tiny component of the overall distributed application. The distributed application is not written in AJAX. AJAX isn't even a language; JavaScript is. Maybe some people who write AJAX code actually wrote some RPC stuff too, but I'd wager they're just a 13-year-old web monkey. RPC is distributed computing. RMI, CORBA, even XML web services are distributed computing. JavaScript is just glue. Get over it.

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?

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. I mean, most AJAX people don't even realize that the server-side input doesn't need to be written in XML. Guess what? if you're receiving so much data back from the server as to need to process huge XML documents, it's just a fast to do a post-back.

In short, AJAX solves nothing but the most trivial of UI issues. It's about the worst possible choice to solve pretty much anything it's been used to do. Show me an non-trivial AJAX solution, and I'll come up with 3 others that are more portable, use less network resources and are more secure. web20 hype. web20 hype. web20 hype. Are we clear?

mandelbr0t

Re:"Disagreement on Terminology" (2, Informative)

An Onerous Coward (222037) | more than 7 years ago | (#17549112)

Nah, that wasn't flamebait. That was just some guy disagreeing with you.

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" (4, Interesting)

GOD_ALMIGHTY (17678) | more than 7 years ago | (#17550280)

AJAX is a tiny component of the overall distributed application. The distributed application is not written in AJAX. AJAX isn't even a language; JavaScript is. Maybe some people who write AJAX code actually wrote some RPC stuff too, but I'd wager they're just a 13-year-old web monkey. RPC is distributed computing. RMI, CORBA, even XML web services are distributed computing. JavaScript is just glue. Get over it.

In the day and age where I have clients who all now want web apps, but still want all the functionality of a desktop app, you better believe AJAX and this Web 2.0 crap is here to stay. AJAX is also going to stay because the tools are better. I've been avoiding Javascript for years, I can't stand figuring out all the browser quirks, I'd much rather write a Swing app. Google's Web Toolkit changed that. It's a seamless framework for cross-browser applications, I can use CSS to style my UI and Swing like components in a Java IDE to write the actual code. The lack of decent tools is why CORBA didn't take off. Hello World is no less complex in AJAX than CORBA or RMI, it all has to make it across a network and back. It's just that the tools are better, which was probably helped by the lack of complexity in the underlying protocol, but c'est la vie. The web browser is now a rich client. You may believe HTTP is a most horrid protocol for doing RPC or that Javascript is a most horrendous environment for writing anything other than hello world, and I would agree. Like I said, this is all simple CORBA again, but with a universal client app container (the javascript/dom/css capable xml browser) instead of a hand coded top-to-bottom desktop app.

Why wouldn't it make sense to do it this way? We've moved to application containers on the server end to instrument applications with basic infrastructure, why not do it on the desktop too? How is a data structure serialized via a Javascript call to an HTTP request that returns another data structure in an HTTP response any different from RMI, CORBA, MSRPC, XML-RPC or SOAP? Same basic process, so what if Javascript is just glue? By that premise, so is every other language that uses C libraries. Javascript is a scripting language that can be used to draw interactive UI's. The fact that Javascript is not really a great environment to write really interactive UI's doesn't change that. How is GMail any different from early desktop email clients? And I don't even have to actually touch the Javascript if I use existing GWT components, I can write the whole damn thing in Java.

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.

Personally, I'd recommend GWT for Java devs, but to each his own. My question is what if your client requires a web based app? Are you going to tell them you're only going to write that kind of app in a proper desktop environment? CORBA was a damn good architecture too, but how many CORBA apps to I get paid to write? And it's not like our company wouldn't win the work, we've got several people who've rolled their own CORBA orbs. AJAX is here to stay because it fulfills the requirements today. Half the crap on teh Intarweb today would be kicked off if my view of engineering aesthetics were adhered to.

I mean, most AJAX people don't even realize that the server-side input doesn't need to be written in XML. Guess what? if you're receiving so much data back from the server as to need to process huge XML documents, it's just a fast to do a post-back.

You are correct here. That's why I'd recommend a framework, better not to confuse them with your hand rolled hiding of all this. After all, you don't intend on maintaining this thing forever do you? It's also the reason I like CORBA over SOAP, that and SOAP is freaking reinventing every CORBA spec out there, It's not like the CORBA way is any more painful or that the tools couldn't be written just as easily as the SOAP ones. And why the hell would I want firewall-piercing applications anyway? That's not a feature of SOAP, it's a bug. You're statement is also the reason I said I'd rather see someone reading the patterns book than an AJAX in 24 hrs book. I'd rather they understood how to use AJAX than were able to write their own implementation.

In short, AJAX solves nothing but the most trivial of UI issues.
I wouldn't call the user facing end of the application trivial, but yes, UI layouts and events usually aren't the hard part. I don't see you're point. If it's such a trivial part of the application, then why would you care that AJAX was doing it anyway?

It's about the worst possible choice to solve pretty much anything it's been used to do.
It can be run from a browser without a plugin. Minor UI tweaking can be accomplished with CSS. I'd kill to load up a CSS page and have it layout and decorate Swing components. Something like Jaxx, but without the XML, just load up a .css as a resource like a propertybundle. Wouldn't have to recompile to tweak pixel settings, use hit a reload hotkey in the app. If my requirements include a web based app with no browser plugins, I fail to see how AJAX could be the worst choice.

Show me an non-trivial AJAX solution, and I'll come up with 3 others that are more portable, use less network resources and are more secure. web20 hype. web20 hype. web20 hype. Are we clear?
More portable? GWT apps can run identically in Firefox, IE and Safari out of the box. How much more portability did you want? What does that extra portability buy you? What does it cost in terms of development and support? You might use slightly less network resources, but only if you count the AJAX app code. Otherwise, you're going to consume a similiar amount of bandwidth or at least face the same challenges. If you passed bloated objects to RMI, you'd easily send more traffic than a lean HTTP request. HTTP headers aren't that big. And what is inherently more secure about a desktop app talking over the network than a web application talking over the network. I'd put both on SSL if security was an issue. Again, anyone familiar with the patterns in distributed computing can compensate for the deficiencies of the environment. How to apply those patterns to new technologies is not always obvious, especially if the tech isn't the best for the task.

But let me be clear. You're just hatin on AJAX cause your sense of engineering aesthetics are offended. Fine. Whatever. AJAX has serious benefits, it works and it's portable today. It's an easy way to get a rich client to a customer whose environment you have no control over. It leverages existing infrastructure and free's the developer to do other things. It wins because it's the most useful thing relative to it's proximity to the lowest common denominator, not because it's good tech. Develop good tech that can be used effectively by 13 yr old web monkeys and you'll win. Until then, quite'cher whining.

Re:"Disagreement on Terminology" (2, Informative)

Tim C (15259) | more than 7 years ago | (#17548972)

I just don't put Usability "patterns" in the same category as the GoF patterns

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" (3, Informative)

mahemoff (1049494) | more than 7 years ago | (#17554000)

Hi, this is Michael, the author of Ajax Design Patterns. I won't repeat what others have said already regarding the broad definition of patterns that this book assumes. Suffice to say, patterns didn't start with GoF and in fact, the basic idea - documenting common solutions in a consistent format - has been used in way or another for many decades, predating even Alexander's work. Here, I'd just like to add a couple of clarifications:
  • I understand where you're coming from if you consider the title to be stupendously hyped - "Ajax" and "Patterns" is buzzword squared. Well, the book is definitely about Ajax as most people (including Jesse James Garrett, coiner of the phrase) define it. As for "patterns", others have already stated why the Ajax Design Patterns are reasonablly called "patterns", but for those who think that the "patterns" term sells a book, this is not 2001 :-). There was a period between around 1999 and 2002 when dozens of books came out with "patterns" in the title, using it legitimately or not. I watched the trend closely as I have been working with patterns since 1997, and I subsequently watched as patterns then settled back to being a standard tool of our industry and no longer a hype term that sold books by its name alone. In fact, I spoke to an acquisitions editor for a prominent publisher in 2004, and she told me her company has an outright policy of not publishing anything to do with patterns - it was old hat by then. Fortunately, O'Reilly went with it because patterns is what I had set out to achieve on my blog and wiki prior to the book contract, but I don't think anyone saw patterns as a marketing tactic in the past five years.
  • Though not the original pattern reference by any means, GoF has an important place in the history of patterns and has been vital to my own development. I was therefore pleased that one of the authors, Ralph Johnson, took a special interest in the book, conducting a series of review sessions [softwareas.com] on the book draft with his architecture group at Illinois. The MP3s are online (see previous link). While certain individual patterns come under scrutiny for their pattern-ness, the group overall takes it for granted that these are patterns and focuses on the content. This is actually the wish I expressed in the appendix to this book, anticipating the whole "pattern" debate...what's really important is the content, not the form. Patterns just happen to be a useful way to present reference material of this nature IMO.

You can take your AJAX and shove it up your ass! (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17545684)

Nobody wants AJAX. Nobody. It has been an absolute disaster for web users. Firefox has been patched no less than 100 times [mozilla.org] because of the holes it creates. The web browser gods are angered by this morphing of static pages into insecure applications. Enough's enough, web monkeys. It's time to burn the AJAX witch!

The Best Book Covering AJAX (3, Informative)

Naum (166466) | more than 7 years ago | (#17546264)

To date, IMV.

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.

Best AJAX design pattern (-1, Troll)

Anonymous Coward | more than 7 years ago | (#17546414)

not using it at all.....it's such a toy, just like Ruby

Save $13.95 by buying the book at Amazon.com! (0, Informative)

Anonymous Coward | more than 7 years ago | (#17546730)

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 [amazon.com] . That's a total savings of 31.01%!

Whacky AJAX (2, Interesting)

dino213b (949816) | more than 7 years ago | (#17546828)

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?

Re:Whacky AJAX (2, Informative)

elbobo (28495) | more than 7 years ago | (#17548024)

My take on DHTML widget toolkits is this: It's too soon.

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:Whacky AJAX (2, Interesting)

wranlon (540319) | more than 7 years ago | (#17549928)

I spent a lot of time between '99 and '02 developing an DHTML toolkit [imnmotion.com] (example [imnmotion.com] ). In the summer of 2002 I started working on a rewrite of the widget toolkit, and ultimately created something else - Engine [imnmotion.com] . I wrote an article about the decisions that lead me from the widget-heavy MDI toolkit to service and component orientated Engine toolkit: The Separation of Functionality from Content [imnmotion.com] . Dojo, and the other toolkits that are pretty similar to it, have a lot of neat aspects and very clever widgets. However, there are a lot of corner-cases when dealing with managing events through the DOM and script, and its very easy to miss those situations. I think the Dojo foundation is doing some good work, but, the examples I've seen where Dojo has been implemented has left something to be desired. Also, after refining my approach and using it in high traffic areas (particularly the Web Analytics [imnmotion.com] and window component [imnmotion.com] ) I've found it to be much easier to maintain and add/remove as the situation warrants.

Re:Whacky AJAX (2, Insightful)

Shados (741919) | more than 7 years ago | (#17550400)

My experience with AJAX toolkits, is probably going against Slashdot's ideology, but for the sake of giving diverse arguments: the web is a complex world, full of bugs, mishaps, problems (even in the best browsers), and intimate knowledge of all of em is required to do complex (very complex) things. That is simply not something anyone but the most dedicated programmer can do as a hobby.

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.

Re:Whacky AJAX (1)

mcalwell (669361) | more than 7 years ago | (#17554312)

I stick to simple libraries that abstract away the guts of browser type and the mechanics of XMLHttprequest, and give me something I can return an array of data from the back end to do with what I wish. Having said that, I generally only use a smattering of AJAX to facilitate the use of a page - though it's definitely essential, and my apps could not compete with desktop apps at all without the functionality that AJAX provides. I've found that scripting the DOM manually really isn't that tricky if you're prepared to do the legwork, and to date, I've not got to a point where there was something I wanted to do but couldn't find out how to do.

Link to the AJAX design patterns wiki (2, Informative)

HvitRavn (813950) | more than 7 years ago | (#17547974)

AJAX Patterns [ajaxpatterns.org]

From the review (1)

cpt_rhetoric (740663) | more than 7 years ago | (#17548382)

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.

Re:From the review (0)

Anonymous Coward | more than 7 years ago | (#17549188)

very nice....we make sexy time now

My buzzwords can beat up yours (1)

Tablizer (95088) | more than 7 years ago | (#17551920)

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"
         

Re:My buzzwords can beat up yours (1)

cpt_rhetoric (740663) | more than 7 years ago | (#17560540)

Nicely done. With that and the other book I can wean myself off of Lunesta quickly.

selenium (1)

des09 (263929) | more than 7 years ago | (#17554052)

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 [openqa.org] .

Bad buy (1)

netpig (37704) | more than 7 years ago | (#17559588)

I bought this book. Wanted Ora's with same title, but could not find such. So picked this one after long comparsion and once i got it, it was a real disappointment. Writing style, content, etc, this guy should not be writing books.


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.

Re:Bad buy (1)

mahemoff (1049494) | more than 7 years ago | (#17560138)

I think you're talking about a different book, because this is an Ora book (one of several ORA books on Ajax - there's also Ajax Headrush and Ajax Hacks).

Re:Bad buy (1)

netpig (37704) | more than 7 years ago | (#17560374)

Auts. You're right. Mine is 'Ajax Patterns and Best Practicies' from apress.com.
(ISBN: 1-59059-616-1)

Doesn't change the fact that this is worst book I've bought. :-(
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...