Burningbird

I guess my cut is that the xml part is important. You're now looking at a world of web-based applications where you are not having to be resent a whole screen of material to refresh the browser.

I think the main issue, as you point out, is that security model has not been thought through. Were you doing something like this in an applet, there are constraints on what you can go request, etc.

Another issue here is that you have wandered into the realm of highly interactive web applications with no real design paradigm. For instance, it is unclear how any design patterns are implemented let alone enforced. All of this stuff becomes important when you start to develop complex, distributed apps.

This could use clarification. You use all sorts of technologies that don't perform equally well across all browsers: CSS, JavaScript, and … well … everything breaks in some browser. The difference with "ajax" isn't that it's not cross-browser (or "proprietary," which doesn't mean much in the context of Mozilla) - it's that it (generally) moves content behind a new interface. I doubt you'd have the same issues with "ajax" if it were just used to supplement content, as CSS and JavaScript were first used.

Good point, Scott. It's the same with my absolute dislike of DHTML menus, hence my example.

As an anciliary device to a page, great, bring it on. But for critical functionality and navigation, being dependent on "in-place" modification is always going to filter out the handicapped, as well as those using non-compliant browsers.

I've seen how google is using some of this, as well as flickr. For the most part, the use is fairly innocuous, or even helpful (but usually not forcing a dependence on it). But then, I've seen others run with this and talk about 'in-page' editing of entries in weblogs, and I can't see the purpose for it. What is is about the use of the technology that provides something more traditional uses of technology don't provide?

Using tech, just to use tech — leaves me cold.

Inventing new names for old uses, leaves me even more cold.

Bud, your point is good, but I don't think the issue of design paradigms will be a biggy — I can see designers and front end and back end coders all managing to speak a common language. And design patterns are also staging a comeback.

But any time there's a dependence on JavaScript (or ECMAScript if you will) in a page, you create a filter. Most companies, don't want to filter. Heck, most of us don't want to filter.

For instance, I have a live preview, which is dependent on script. But you having JS turned off doesn't stop you from leaving a comment. It's a nice feature, but you can accomplish your task without it.

There's tradeoffs with the use of this "new" approach. I just hope the folks caught up in the buzz think on this.

The next big thing must therefore be frames, right?

I think the place for Ajax is in web applications which, according to precedent in the C language, one might refer to as having “volatile� session state. The distinction is that the server-side state of a session is not dependent solely on the requests sent by the session client, and you want to keep the user’s screen up to date without interrupting their interaction with it.

Chatrooms are the best example: the chat backlog must be periodically refreshed while the user may have entered an incomplete message. A full refresh would cleared that partial message and therefore is unacceptable. Traditionally there is no sane model for doing them on the web other than to use a frame for the chat backlog or for the text input. But you can use XMLHttpRequest to insert new chat in-place. Users without the benefit of Javascript can just refresh the page manually.

Webmail fits that defition as well: mail may arrive at any time while the user is looking at a previously rendered listing of his inbox. (GMail does not set a good example, according to what I know; I have not tried the service myself.)

This is right in line with your comment on how using of such techniques should compound the user experience, rather than constitute it.

For XMLHTTPRequest XML isn't required to be well-formed or anything, as far as I'm aware. Besides, what can it do which couldn't be done by a hidden iframe? *sighs* And besides, isn't an iframe more widely supported than XMLHTTPRequest?

I refined the above comment and wrote a longer piece at Chlorine hazard: do not mix cleaning agents, where I argue that Ajax can help both usability and accessibility at the same time and improve everyone’s situation.

Take a look if you want to.