Mastering Ajax Websites

An anonymous reader writes to tell us that IBM DeveloperWorks has an interesting article introducing the uninitiated to the world of Ajax. From the article: "Ajax, which consists of HTML, JavaScript technology, DHTML, and DOM, is an approach that helps you transform clunky Web interfaces into interactive Ajax applications. The author, an Ajax expert, demonstrates how these technologies work together. Ajax is more than just the latest fad -- it's your stepping stone to build better Web sites through efficient use of your time."

How about a new language

[zymano]

Instead of a complex hybrid why not a new language ? Half the opinions about Ajax is that it's not worth all the effort. Too complex.

What about Python or something new just for interfaces ? Something like Macromedia Flash ?

JavaScript code is the core code - What???

[danwiz]

From the article:
JavaScript code is the core code running Ajax applications and it helps facilitate communication with server applications.

Depending on JavaScript could be its downfall, since JavaScript has so many functional work-arounds for each browser. Even the article mentions (but dismisses) this problem.

From the article (again):
Microsoft's browser, Internet Explorer, uses the MSXML parser for handling XML (you can find out more about MSXML in Resources). So when you write Ajax applications that need to work on Internet Explorer, you need to create the object in a particular way.

"Particular Way" for browser one ... "Particular Way" for browser two ...
Sounds like in an inherently poor design.

Re:Ajax in action

[OverlordQ]

My only complaint about AJAX sites is it makes bookmarking something damn near impossible.

Why AJAX matters

[Geoffreyerffoeg]

AJAX isn't an end in itself; it's just a tool. It's like JavaScript. Back when the web was old, if you wanted to do data validation for a form (for example), you had to send the page to the server and wait for a new page as a response. When JavaScript became popular and well-enough supported, the webpage itself could check data before sending it to the server - although the checks couldn't be that complicated. AJAX is similar; instead of limiting yourself to either using a new page or client-side data, AJAX lets you use JS to access server-side data.

As a concrete example, play with Google Maps [google.com] for a couple of minutes, then try using a map from MapQuest [mapquest.com]. It will quickly start to annoy you that you can't drag the map and that you have to click to a new page to move the map around. GMaps isn't pure AJAX, admittdly, since it deals with picture data - it can just write the image tags to the page and move them around as you drag. But the side text and the map searches are AJAX - when you click search, you don't open a new page with the search results. You can keep using the map; the client will turn your search into an XML request, Google will process it, and send the results back as XML - asynchronously.

For another example, I wrote this week a dead-simple chat program (because I needed a specific feature). It was simpler to write a web app instead of a real app, because the latter would require networking, windowing, and whatnot - the web interface made GUI easy and manual networking irrelevant. Without AJAX, I would need to have the page reload every second to check if there are new messages - very distracting. I had the system asynchronously check for messages in the background, and when one arrived, update just that part without refreshing the page.

AJAX is a tool to be used when necessary. Don't freak out over it, but realize it's there whenever you need to use a more application-like interface instead of a page-like interface.

Re:JavaScript code is the core code - What???

[Anonymous Coward]

Depending on JavaScript could be its downfall ... Sounds like in an inherently poor design.

While I'm not a big fan of JavaScript, the incompatibilities you talk about aren't JavaScript's fault. They are due to different levels of JavaScript support in different browsers, and the addition of non-standard features by the different browser camps. AFAIK, XMLHttpRequest is not a standard. It was invented by Microsoft, and others found it so useful that all modern browsers now support it, albeit with slightly different APIs. That is the source of the incompatibilities, not JavaScript.

Re:How about a new language

[Fahrvergnuugen]

Well, as soon as we get all of the web browsers out there to adopt your so called "new language", we'll be all set. Your comment about Macromedia Flash made me laugh. Explain to me how Action Script interacting with the server with XML.send() is any different than JavaScript using XMLHttpRequest??

Obviously you're not a web developer ;)

Instead, how about a JavaScript 2.0? The language is only short a few key elements (like a native JSON serializer).

I started developing web based applications 7 years ago. At that time, JavaScript was really only useful for image mouse overs and was more or less useless and I refused to use it for anything.

Well, about 8 months ago I decided to give JavaScript another chance. All I can say is, wow it's come a loooong way.

I'm a bit skeptical of all of the frameworks that have popped up. They seem to overcomplicate things profoundly. I've looked at a lot of them, but haven't decided that any of them are less work than the solution I developed on my own.

My approach is to use JSON instead of XML. I have a server side script (can be any language, I used PHP for my last application) which acts as a listener script. The listener script accepts and sends JSON strings. The client JS composes and sends JSON strings with XMLHTTP request.

It's clean, fast and simple to maintain and expand. I think these claims of AJAX being "too complex" are ridiculous.

Re:Ever notice . . .

[Kickboy12]

I fail to see how anybody can be an "Expert" at something that is nothing more than a couple lines of code and a function or two. People seem to attribute "AJAX" to an entire javascript feature, when the part of the code that is actually "AJAX" is so small it's not worth mentioning. Not the mention the term AJAX seems overused and more complicated than it really is. It's basic javascript, nothing fancy or advanced or special.

There's way too much hype over such a small thing. It gets annoying.

Re:Ajax in action

[Bogtha]

Umm.. ctrl+click link for email.

...and that would work if Google hired somebody competent to write their Javascript. But they hired people who use spans and onclicks instead of <a href="...">s, thus taking the addressibility away, thus taking the bookmarks, tabs, etc away too.

Re:How about a new language

[trevorrowe]

How about a new language [instead] of a complex hybrid why not a new language ? Half the opinions about Ajax is that it's not worth all the effort. Too complex.

I think you just missed the whole point of ajax with that single statement....

Webbrowsers support javascript very well, and have done so for quite some time. Javascript has a nifty object that allows you to asynconously make requests without submitting a page, in the background so to speak. This request might fetch an XML document or might be a specially formated response to the developers liking. Javascript parses this. Then you use javascript to manipulate the DOM of the HTML page to reflect whatever new information you recived.

Why do we need to add or create a new language to do this? Javascript already proves it does an excellent job and any replacement language would have to do exactly the same thing that javascript is doing now? So you want to buy a new horse to replace the old horse, but the new horse isn't going to be any different? Just new?

Ajax, all the problems of time sharing, back again

[Animats]

I keep encountering dynamic web sites that sort of work, or have performance bottlenecks. When I close some pages on tribe.net, there's about 10 seconds of disk activity from the browser, during which time the browser locks up. (Does anyone know what they're doing wrong?)

A growing annoyance is a page that hangs during loading because its advertising site is slow. With plain HTML, page rendering isn't delayed for image loading. With AJAX, page load can be stalled while the ad server cranks. I keep seeing "Waiting for servedby.advertising.net" in the browser status line. Fortunately, I can just close the page and go to a competitor.

I just bought 40 backup tapes. First site had some problem with its dynamic stuff. Went to another site and spent money there.

Re:JavaScript code is the core code - What???

[insert_username_here]

The incompatibility you are talking about is the direct result of Microsoft implementing XMLHttpRequest with ActiveX, and everybody else implementing it as a native Javascript object. Microsoft are changing their implementation in Internet Explorer 7 to be compatible with everyone else.

You do know that Microsoft actually invented the XMLHttpRequest object, don't you (they then completely ignored it for years until Google realized its potential)? And since COM/ActiveX is the main way things get done in the Microsoft world, it's entirely appropriate (although, you're right, the security implications are huge).

I will be really impressed if Microsoft really is changing their implementation to an in-browser object instead of a COM object, as it means that they will have changed something they invented to fit in with everyone else - the exact opposite of their usual behaviour.

I'm all for bashing M$ when they deserve it, but give them credit where it's due.

Re:Ever notice . . .

[shobadobs]

Look at what Google Maps did for online mapping and tell me AJAX is "just a fad".

Okay. The word "AJAX" is just a fad.

The actual implementation will not be, and sites that use "AJAX" will range from the finely crafted interfaces to the usability nightmares.

Why this is a fad:

[Mitglieder]

You can tell this is a fad because 1) this technique has been available for years this with Java applets, iframes and dynamic script src includes 2) it's not beneficial for 99% of the websites out there 3) it requires extra work to make the process intuitive to users 4) it's more costly to develop in that it takes longer and requires more smarts, and most of the time it isn't going to pay for itself, because simply getting rid of a page reload in the age of broadband doesn't itself improve the underlying quality of the website. The success of most websites still has 99% to do with content and 1% or less with UI aspects. Look at Craig's List or this website. The reason the technique has become popular all of the sudden is because Google has been incorperating it alot and someone gave it a name. Before the name AJAX came along you would have had to describe it with a sentance and that doesn't fit in a headline. Before HTTPRequest you could have as easily done an location.replace() to a CGI in a hidden frame and had the CGI's response do a callback to a function in the calling window and it would work exactly the same way. When you use the location.replace() method you avoid the clicking sound and the history entry when calling the hidden CGI. You can even use an iframe if you want to avoid using a frameset. This technique has been available since the 90's. I might still prefer this method because it's more robust and there's no need for compatability checking.

Just finished a chat application using AJAX

[eyebits]

I've been working on a project that provides a web-based environment for people with a medical condition to get counseling and support online. Chat has been one of the desired features, but the various methods for implementing chat were presenting a problem. Java applets and Flash applications presented problems with time to load for modem users as well as issues with having the right versions of Java/Flash player installed on client. I thought setting up a Jabber server and letting folks use a client installed on their computer would be a good solution, but many (most) found it too difficult to install and configure a chat client. (These are older folks often with little computer experience.) AJAX came to the rescue. The "chat client" is part of the web application. It is as lightweight as the typical web pages being loaded. The exchange of messages between client and server require very little bandwidth. The chat application is just part of the same environment that the users are already comfortable using. I don't see AJAX as the answer to everything and, for the moment, having web applications chock full of AJAX doesn't make sense. But, it has come in very handy in the case of chat for the project I am working on.

Re:Ajax in action

[Bogtha]

ummm... if you think about it, there's a good reason why AJAX tends towards onclicks instead of hard links. Think about it, it will come to you.

Nope. Can't think of one. You do realise that it's perfectly reasonable to use Javascript with real links don't you? And I wasn't complaining about onclicks, I was complaining about spans and onclicks together being a half-arsed replacement for real links.

the 'broken' bits you mention (addressibility, bookmarks, etc) are features of web content, not features of web apps.

So basically I should stop wanting my basic browser features to work, even though other providers can do it, and even though it would work if they constructed their web application correctly?

In an application, especially one that tracks state, bookmarks can break the logic flow.

Only if you mix up the controller with the view.

Nobody complains that Word doesn't open up a doc right to the paragraph you last read. Why should a web app be any different?

Bad example, for two reasons. Firstly, we're not just talking about bookmarking, as I've already explained. Secondly, the analogy doesn't hold because nobody even mentioned bookmarking individual paragraphs. People would complain if you couldn't open individual Word documents directly from your file system, from your recent document list, etc, instead being forced to open Word, then use Word to find and open documents. The document is the unit of addressability here - whether that's a Word document or an email.