The Artima Developer Community
Sponsored Link

Java Community News
Ajax Anti-Patterns

2 replies on 1 page. Most recent reply: Apr 3, 2007 3:53 AM by Marc Levin

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 2 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Ajax Anti-Patterns Posted: Mar 21, 2007 3:04 PM
Reply to this message Reply
Anti-patterns aim to define design and coding practices that developers do well to avoid in a problem domain. Jack Herrington describes five Ajax anti-patterns in his latest IBM developerWorks article.

As Ajax and rich-client applications become more common, typical Ajax anti-patterns are emerging: Patterns of code and techniques that developers would do well to avoid. In his latest IBM developerWorks article on Five Ajax anti-patterns, Jack D Herrington describes why using a timer for polling is a bad idea, and why bad choices in dividing the work of client and server can lead to poorly performing applications:

  • Polling on a timer when you don't need to

    Many of the Ajax issues I see have to do with misuse of the timer functionality built into the JavaScript language. The key method is window.setInterval()... [that] tells the page to call back a particular function on a particular interval—say, every second... When it comes to these timers, [browsers] rarely deliver, primarily because the JavaScript language is single threaded. If you ask for a second, you might get the callback at 1 second or 1.2 seconds or 9 seconds or any other time.

    Ajax is asynchronous by its very nature. Don't you need a polling loop to see when a request is finished? It turns out, not so much... All the XMLHTTPRequest object provides is a callback mechanism called onreadystatechange.

  • Not inspecting the return results in the callback

    Many Ajax anti-patterns spring from misunderstanding the mechanism of the XMLHTTPRequest object. One that I often see is when users don't inspect the readyState or status fields of the object in the callback... I have noticed in Internet Explorer 7 that this problem is more acute than on other browsers. Internet Explorer 7 calls back to onreadystatechange a lot—and I mean a lot, even on small requests. So, it's worth having your handlers written properly.

  • Passing complex XML when HTML would be better

    Putting a lot of intelligence in your pages means putting a lot of JavaScript code there. And that has a big downside: browser compatibility. You really should test every non-trivial line of JavaScript code on every popular browser—or at least, the browsers that your customers are likely to use. And that means work... Wouldn't it be simpler to have the server return HTML instead of XML? ... The choice between whether to process on the server or on the client depends on the demands of the job.

  • Passing XML when you should pass JavaScript code

    With all the hype about having Web browsers read XML data sources and dynamically render them, you might think it was the only method available. However, you would be wrong, because very smart engineers have used Ajax transport technology to send JavaScript code instead of XML... Instead of reading XML from the server, [the client] reads JavaScript code. The code then uses the eval() function on the JavaScript code to get the data

  • Doing too much on the server

    A counter-argument to doing to little on the server is doing too much on the server. [You can, for example do on the client] table that sorts quickly, without a page refresh and without bothering the server to do the hard, uninteresting work of the sort.

What Ajax anti-patterns have you observed?

Dave Crane

Posts: 1
Nickname: davecrane
Registered: May, 2005

Re: Ajax Anti-Patterns Posted: Mar 22, 2007 4:28 PM
Reply to this message Reply
Jack proposes a script-centric approach as a smart idea - get the server to generate Javascript, and then use eval() to execute it when it comes in.

There's a great anti-pattern lurking within here, where the server generates lots of low-level JS, referencing DOM nodes by name, minor variables and function names, and so on, creating a very tight coupling between client and server tiers. If you're going to adopt this approach, please define a high-level API for your generated server code to talk to. (Jack, as ex-editor of the code generation network, will already know this, as its one of the core tenets of code generation to generate against as high a level of abstraction as possible).



Marc Levin

Posts: 1
Nickname: marclev
Registered: Apr, 2007

Re: Ajax Anti-Patterns Posted: Apr 3, 2007 3:53 AM
Reply to this message Reply
I always feel old fashioned when saying this, but I think good ol' remote scripting is a lot more powerful when doing stuff like this. i.e. having a hidden form submit target a hidden iframe and have the returned page invoke javascript that modifies stuff in the top level document (usually just replacing a chunk of the dom with a chunk from the returned page).

I've never quite been able to figure out why this has fallen out of favour - I've written a lot of funky well performing web apps like that.

Flat View: This topic has 2 replies on 1 page
Topic: JCP Posts Review Ballot for Java EE 6 Previous Topic   Next Topic Topic: Mike Chambers on the Browser/Desktop Hybrid

Sponsored Links


Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use