posted 17 years ago
I think AJAX is perfectly acceptable for a chat app....
A little story...
My company, and the company at which some of my friends work, have blocked/banned use of most common chat apps except the company-hosted, internal-only app. This interfered with the most important task of arranging lunch.
I had done a lot of web-based programming, and had once, 2-3 years ago, had one occasion to hear about... not even use... XmlHttpRequest. It occured to me that I could possibly develop a browser-based chat that we could use to set up lunch. Even without having "AJAX experience", the development was quick (this stuff was surprisingly easy). The chat works, and the only reason we don't use it today is that I don't have a good stable place to host it for free.... and I don't want to bother reworking it. We found the "demo" page of a site selling an AJAX chat, and we use that instead.
After I was mostly done with the chat site, I saw something on Slashdot (or somewhere like that) talking about AJAX, and found out I had been doing AJAX development without knowing there was even a term for it ;-) The next day, one of my lunch pals asked me "hey, did you use that AJAX stuff to do that chat?"
</story>
Anyway, back to the actual topic: the AJAX chat sites I've seen have been fine. Chat with a desktop client may seem almost instantaneous, but it's really very much asynchronous, even with a desktop chat app. You type a message, hit send, and can immediately begin typing another message, whether or not the first message has been displayed on your friends screen, or even on your own (ever notice a lag with some IM clients between hitting send, and seeing your own message in the chat history part of the window? I have...)
When I was developing my chat, I realized that the developer has a lot of control over how much lag the user could experience:
you can control how frequent the polls to the server are for new chat messages... in my case, a parameter to window.setInterval(), and whenever the user posted a new message you can avoid redrawing the chat area if there are no updates you can optimize things on the server to make each response get processed fast... mine was just for my friends and I, so I kept everything in memory (part of why it needed to be on a very stable host) you can control how much content has to be transmitted with each update... in my case, I didn't bother to optimize this, and resent the entire chat history with each refresh
anyway, with the little bit of optimizations I did, the lag was less than we have sometimes noticed on Yahoo! IM or AIM.
Tell me, what did you mean by "whenever someone types a message he/she has to wait for the response to come back" and "The problem is ofcourse asynchronous response"? The "asynchronous" part is the beauty of it - the user can be typing a new message, while in the background, the app periodically checks for and displays any new messages.... makes me think (after all this rambling) maybe I missed the point of your question...
-- Jon
[ April 04, 2006: Message edited by: Jon Egan ]