Asynchronous Requests with JavaScript and Ajax

An anonymous reader writes "I rarely read an entire article about a single object, especially one that is this simple. However, you will use this object over and over again in each page and application that you write that uses Ajax. This article shows you how to create XMLHttpRequest instances in a cross-browser way, construct and send requests, and respond to the server."

Comments

Great Ajax Resource

[ellisDtrails]

Google of course!
http://www.google.com/search?q=ajax&start=0&ie=utf -8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US :official/
http://blogsearch.google.com/blogsearch?hl=en&utm_ source=AdWords&utm_campaign=us-ha-en-blogsearch&ut m_term=blogsearch&utm_medium=cpc&utm_content=googl eblogsearch&q=ajax&btnG=Search+Blogs/

*cough*

[Anonymous Coward]

"I rarely read an entire article about a single object"

And I never read something pointed to by such an uninterested observer.

Hello world

[jcaldwel]

This looks like the same AJAX "Hello World" I have read dozens of times before. Nothing new here.

Re:Hello world

[ilyanep]

I think the point here is that it's supposed to work cross-browser

Re:Hello world

[jcaldwel]

I didn't even entertain the idea of using it before it was cross browser. Therefore, every one of the dozens of examples are cross-browser.

Re:Hello world

[KiloByte]

Actually, I thought they mean a way how to have it truly asynchronous -- ie, without building a whole TCP connection first, getting acks and what not. But no, this is just the very basic XMLHttpRequest.

So, would anyone be able to tell me how to send something to a server using a single half-trip? It may be a part of a persistent connection, any eventual ack can be sent through a separate channel, I don't really care about bandwidth -- all that matters is the latency between the user's action and the time server receives the command. Think "interactive app", where interaction means something faster than a matter of seconds.

The only way I can think of so far is trying to send dummy requests to command.1.is.foo.dns.my.server and have the DNS relay me these; however, this would be an insanely ugly hack. Any better ideas?

Re:Hello world

[wk633]

Every ajax 'hello world' example out there is cross browser. That exact same piece of code is reproduced in dozens of articles, perhaps thousands if you want to venture that deeply into Google's search results.

Re:Hello world

[mrchaotica]

Quick question for you: If you only need a "half-trip," how could latency possibly matter? Since it's not waiting for a response from the server, there's no way the client could possibly know how long the request took!

If you throw away a can, does it matter how long it takes to get to the recycling center?

Re:Hello world

[Bogtha]

You can't be looking very carefully then. Practically all the Ajax tutorials I've seen make beginner mistakes. This one's special because it's actually decent code.

Re:Hello world

[Elixon]

Yes, I found the article to contain the same info as many other tutorials. So I think that the object itself (and the article) is not as interesting to me.

Always the interesting part about this javascript object is its usage to solve particular problems...

But for the beginners it is very nice article to read. I can recommend. There were no such as nice articles available when I was building the communication library and trying to use XMLHTTPRequest for the first time in my XUL project.

Re:Hello world

[heinousjay]

Programming raw sockets in Javascript isn't coming anytime soon, nor would we want it, really. The security implications are tremendous.

I'm currently implementing a Javascript client for an application that mostly doesn't care about the responses. I just want the status line - 200 means it worked, 500 series indicates errors. That seems like what you're talking about. It's not as efficient as what you're looking for but over a network I imagine the difference is close to insignificant.

If you really don't care about the response at all, you can just ignore it once you've sent the request. If that's not it, I'm not getting you at all.

Re:Hello world

[jd0g85]

Consider looking here: http://xulplanet.com/tutorials/mozsdk/sockets.php

Mozilla (and Firefox) gives you direct access to sockets. I don't know if UDP is supported. This is great because, in theory, you could implement whatever protocol you wanted to in some clientside javascript.

Should work with unprivileged (ie from a website) javascript. (Opening a listening socket requires privileged code, eg a Firefox extension.)

Re:Hello world

[Anonymous Coward]

agreed, this article is so damn redundant (good place for it i guess). If he would have at least built upon all the previous articles and demonstrated how to achieve multiple asynchronous requests the article would have been worthwhile.

Re:Hello world

[KiloByte]

Schweet.

No Java, not Flash, no other crap. It still doesn't work on MSIE or Opera, but I can always fall back to terminally slow full http requests. These are way too slow for decent interactivity in many cases -- but I can claim it works and direct those who want it to work fluently to a decent browser :p

More seriously, I would prefer a cross-platform solution, but this is nice at least for some users.

Re:Hello world

[jcaldwel]

Mozilla (and Firefox) gives you direct access to sockets.

They what?!? * Evil thoughts *. Anyone know if they have a trusted-domain security sandbox like the Java classloader, or whether they give you free reign? I will have answered my own question, probably, in a little bit.

Re:Hello world

[Myen]

Err, not exactly - content (i.e. unprivileged non-chrome) doesn't get to even touch Components.classes. It replies with this in the JS console:
Error: uncaught exception: Permission denied to get property UnnamedClass.classes

To test, copy this into your address bar:
javascript:alert(Components.classes[ "@mozilla.org/network/socket-transport-service;1"] )
Then try the same again in JS console, without the javascript: prefix. (The JS console is trusted, because web pages can't evaluate in its context. Presumably :p)

And who invented the XMLHttpRequest class ?

[Anonymous Coward]

??? Who did it ?

Re:And who invented the XMLHttpRequest class ?

[Anonymous Coward]

The company that never invents anything did. And have been using it for years before it was hyped as ajax and web 2.0.

btw. Funny seeing IBM criticizing the people who invented the damn thing in the first place of implementing it differently than others have chosen to reimplement it.

Re:And who invented the XMLHttpRequest class ?

[reynhout]

I agree -- that bit of the article seemed rather poorly researched.

But, looking back at the real history, there are a few reasons it didn't attract wider usage several years ago.

Something like XMLHttpRequest had been on the minds of many people for a few years. While we diddled around about how to do it in a general cross-platform way, Microsoft went ahead and added their idea of how it should work. Unfortunately, it was available in WinIE only, and they wrapped it up in their ActiveX framework, which most web developers knew better than to get messed up with.

The Mozilla people saw through the shadows though, and it was added to the tree before Mozilla 1.0...if you remember how long the wait was for that release, you can understand why it looks like Mozilla was playing catch up.

After that, it was a marketing failure (coupled with a few years of total web stagnation). MS only seemed to think it was important enough for WinIE, and Mozilla adoption was slow. Back then, it wasn't considered ridiculous for web developers to use WinIE for anything other than testing, but ActiveX was (correctly) considered evil.

So to those of you who claim that it's been around forever and JJG doesn't deserve any credit for calling it "AJAX" and making it famous... You're all wet. Marketing failures are still failures. Just because Uranium has been around since the dawn of time doesn't mean nuclear fission isn't a potent technology.

PS: To be pedantic, the "XMLHttpRequest class" was invented by Mozilla. The ActiveX object "Microsoft.XMLHTTP", and the associated interface was invented by MS. (Which might explain why a return code of "4" means "completed, everything OK"..., but I digress.)

If you like this, try too AJAX Developer's Journal

[jg21]

If you liked this article then you will surely like AJAX Developer's Journal , just launched digitally/online and replete with how-to articles and interviews, all freely available. It's edited by Rob Gonda.

IBM articles; Security with Javascript

[WebHostingGuy]

While slightly off-topic, I do have to say that IBM's articles are some of the best on the net. They have very good writers and can explain things without resorting to techno-babble for the layman.

On another note, it seems that the current flavor of the month is Ajax. However, this requires that javascript be enabled. Is anyone running into the problem of finding a lot of users are forgoing this technology because they have (or have been told by their company) to disable javascript for security concerns?

Re:IBM articles; Security with Javascript

[masklinn]

I usually consider that 10% of the users have javascript partially or fully disabled either because they use javascript-less browsers (rare) or because of security issues (corporate environments). The trick there is to develop your web application with the Progressive Enhancements philosophy in mind: build a layered, Javascript/AJAX is merely a client-side behavioural layer added on top of the content layer (pure HTML) and the style layer (CSS), it relies on both but shouldn't be necessary for the application itself to work. It's merely applying the good ol' layers separation on your client-side web pages.

Following the Progressive Enhancements "way" raises the chances that your websites will degrade fairly gracefully when the upper layers are not available (old browser, quirks, ...) without "shutting down" the whole site for the user (or lower the cost/pain of having them degrade gracefully).

Re:IBM articles; Security with Javascript

[secondsun]

I work for a company that makes a virtual office web-app. We log some interesting statistics about the end users.

1% don't use IE, and all have javascript enabled.

So no, we have not run into the problem with people having javascript disabled.

Re:IBM articles; Security with Javascript

[Anonymous Coward]

I work for a company that makes a virtual office web-app. We log some interesting statistics about the end users.

1% don't use IE, and all have javascript enabled.

Does it require javascript and use IE-specific features? Does anything that is often used in combination? I mean this sounds like something that, if you use it, MUST work.

Statistics after the fact are sometimes a bit different...

Re:IBM articles; Security with Javascript

[Kjella]

I work for a company that makes a virtual office web-app. We log some interesting statistics about the end users.

1% don't use IE, and all have javascript enabled.

So no, we have not run into the problem with people having javascript disabled.

You left out the most important detail - does your site require IE/Javascript? Because if I heard about your service, here's what I usually do:

1. Read article, which is usually regurgitated press material
2. Google for user experiences or reviews
3. See that your app requires IE and move on

Re:IBM articles; Security with Javascript

[secondsun]

No it does not require IE.

It does require Javascript to use the application since we began logging.

Re:IBM articles; Security with Javascript

[Jasin Natael]

Well, graceful degradation is nice, but...

I think users who are disabling JavaScript are already doing themselves more harm than good. There are some genuinely good dynamic interfaces out there, and compared to the time and bandwidth savings they'll get by using them properly, the time required to install FireFox or a popup/ad blocker is negligible.

At least for intranet and company sites, there's a genuine demand for functionality that it's impossible to expose without full Javascript support. Consider a drag-and-drop interface where customer orders appear on the left-hand side, and the line items can be organized into a grid of dates and production stations (a piece of machinery or a particular set of workers) via drag-and-drop. I have a working AJAX app that does this, but I can't think how such an application would be useful in the absence of JavaScript. It would require literally hundreds of pageloads and a metric ton of typing (remember: No Javascript = No Calendar Picker) to do any meaningful analysis and manipulation, and the very act of using it would destroy the user's workflow/concentration, rendering the application less useful than the scrawled paper notes it replaces.

This is the direction the web is moving. There are a lot of consumer applications that would benefit from taking a more dynamic approach, especially when you combine the intuitiveness of drag and drop with the live feedback made possible by XMLHTTPRequest. I think that coddling to users without JavaScript is holding them back, as well as creating a lot of useless "busy-work" for web designers and developers.

Jasin Natael

Re:IBM articles; Security with Javascript

[Anonymous Coward]

Does you website require javascript to log information? Or does it degrade gracefully?

Re:IBM articles; Security with Javascript

[Anonymous Coward]

Yes

Re:IBM articles; Security with Javascript

[LiquidCoooled]

You might be right, but I'm not going to find out.

As a test, I just downloaded the frontpage for Digg.

Amongst the 275KB of data I found such useful files as:

spellChecker.js (13KB)

tooltip.js (16KB)

wz_dragdrop.js (37KB)

I am 100% certain that 90% of this bulk is not required by a normal user just browsing the site.
I have NO NEED to ever drag/drop on the front page, so why in the hell do I have to download the entire editing site initially?

Without any java running, the same page weighs about 40KB and looks the same.
I can still click everywhere and do everything (as an anonymous not logged in user) that I could before.

I realise digg is just one site and it may be better in other places, but its all just bloat and not needed.

Re:IBM articles; Security with Javascript

[rheotaxis]

The web 2.0 should be about getting more information, to more people, more quickly. In this regard, AJAX needs the backup suggested by the progressive enhancement ideas. Supporting text only browsers means more people can get information, more often, and often more quickly, if a text only mode is implemented with good design and development tools. I suggest that Ruby on Rails allows for quick and easy text only design, easily implemented and tested, which can then be enhanced in subsequent iterations of development.

Re:IBM articles; Security with Javascript

[masklinn]

And I'd add that, for all meanings and purposes, the Web (regardless of it's "versioning") is a wonderfully universal medium: thanks to a pair of assistive technologies, it's possible for blind, paralytics, deafs people, ... to access informations in a much easier, much pleasant way.

These assistive technologies don't always work well with some javascript stuff. Accessibility is important, and the baseline of accessibility is the base text-only medium, without all the bells and whistles but with the content and the basic services.

Even when it's a slower, longer, more cumbersome to use the service, page or application, it's still orders of magnitude better than not being able to reach the service at all.

Re:IBM articles; Security with Javascript

[ergo98]

While slightly off-topic, I do have to say that IBM's articles are some of the best on the net. They have very good writers and can explain things without resorting to techno-babble for the layman.

I respectfully disagree. Being in the IBM papers section was a sign of long researched, excellent papers maybe 4 years ago. Lately, however, most of them have been terrible pandering pieces. Invariably there's some anonymous "gee, I just came across some article" submissions to Slashdot and everyone else (a cynic would say that it's the authors themselves). I haven't bothered looking, but does IBM accept external submissions now?

In this case there are literally thousands of 'cross-platform xmlhttprequest' articles out there, many of them excellent (and many of them based upon copying what Google did, because of course Google invented xmlhttprequest). No Digg!

Re:IBM articles; Security with Javascript

[henni16]

A slightly related user's point of view (though I'm also a developer):
I am not "forgoing this technology" because of security concerns, I am getting pissed off because of sites that force me to have Javascript enabled when I don't want to:
Coming from "JS disabled, enabled if needed/useful", I usually have it enabled now but I don't want to.
Which means that I will likely show up in the logs as a "non IE, but JS enabled => no problem" user (I am referring here to another answer to your post).

My problem with Javascript:
I want to disable it because of layer ads, remotely included tracking scripts (like Google's urchin.js), annoying eye candy (snowflakes and whatever), security and so on. The "best" thing I encountered somewhere was a page remotely including some js for layer ads that used the click to close the ad to bypass popup blocking and open a popup. Great.

Don't get me wrong: I see uses for AJAX/Javascript, I was really impressed by maps.google for example.
Lots of Webapps might benefit by using it, especially Intranet or ASP stuff (I don't want to use an Office app with a server roundtrip after every click).
BUT: people who require Javascript because their menu URLs look like "javascript:goto('http://foo.com/bar.html')" or use it to open links in a new browser window because they never heard of "target='_blank'" should be drawn an quartered - though mostly because it breaks tabbed browsing ;-)

The consequences:

• I (have "always")used the "prefbar" mozilla extension with a checkbox for enabling (Java)Script/Referrer sending/cookies/etc
• I most likely have Javascript enabled; AJAX supporters may cheer
• I still only have it enabled because Flashblock says it needs it and there is more annoying Flash than Javascript ;-)
• Finally I was pissed of enough to bother to get the Adblock installation to work (had install troubles whenever I wanted to try it before) to be able to block stuff like Google's urchin.js and most layer ads
• And guess what? I don't want to generally block ads, but during the blocking of webbugs and scripts I don't like, I found myself blocking the ads "while being already at it"

=> Yes, I might be able to visit (and use) a Javascript requiring site, but if the site's scripts seem useless or annoying to me. it hopefully doesn't rely on advertising revenue.

Re:IBM articles; Security with Javascript

[Jasin Natael]

That does suck. Even with a good API, it's too easy to just throw the kitchen sink into a constructor or header file instead of including file links as needed. I hadn't thought about all the unnecessary JavaScript that flies around the web and never gets run, or worse, executes but never does anything useful.

The current common practice is to write a header file and just include it inline for every page on the site; This means that the <head> contents can't ever be changed by the individual script. One middle-of-the road approach that I use is to just keep an object as the page buffer and manipulate its array of lines with object methods like:

OpenTag(tagName[, options]); // Push tagName onto a stack and output <tag [options]>
Write(text[, tagName[, options]]); // Escape text and optionally enclose it
Tag(tagName[, options]); // Insert a self-closing tag
CloseTag(); // Pop a tag name off the stack and close it

It doesn't give you the flexibility of the DOM, but it's much faster and still ensures proper opening/closing/matching of tags, and consistent formatting/indenting of the markup. If the header lines are kept separate, they can be added or removed right up until the page is output.

Jasin Natael

Re:IBM articles; Security with Javascript

[Heembo]

On another note, it seems that the current flavor of the month is Ajax.

Flavor of the last 6 months, to be more exact.

However, this requires that javascript be enabled. Is anyone running into the problem of finding a lot of users are forgoing this technology because they have (or have been told by their company) to disable javascript for security concerns?

I rolled out some very serious Ajax apps to a large corporate hardware server producing customer, a LOT of executitives running Safari, XP IE, XP FireFox, and Opera..... and I tell you man, I'm SHOCKED that I did not see even ONE compaint yet. Without Javascript (and cookies for that matter) the web is a lonely disfunctional place! I wasa afraid like you, I have JavaScript, but it works on all browsers, it's easy to code, and it saves on server load. Go baby go!

Re:IBM articles; Security with Javascript

[Anonymous Coward]

If you want a web application to work unfailingly, you cannot use features that can be disabled by the client. Javascript is one of these. If you want it to work it absolutely must be done serverside. Javascript is for the birds.

Re:IBM articles; Security with Javascript

[Anonymous Coward]

I have two words for you: Mozilla Firefox NoScript Plugin

Happy Fun Time Loser Man Kill Chicken's Frog -- See the Moovie.

Re:IBM articles; Security with Javascript

[poopdeville]

In this case there are literally thousands of 'cross-platform xmlhttprequest' articles out there, many of them excellent (and many of them based upon copying what Google did, because of course Google invented xmlhttprequest). No Digg!

*cough*Microsoft*cough*

Re:IBM articles; Security with Javascript

[Anonymous Coward]

for me, it's simple. JS turned on, you are exposed to well over 90% of the most annoying (ads and Flash calls) and dangerous things on the web (malwarez toonumerous to mention). Turned off, it's fine. Some sites look screwy without it, but it's passable. Ones that actually REQUIRE it get tossed in the reject pile. It is the height of web master/site arrogance to inflict JS on your web site visitors. Do they think their site is the only one out there, or that people aren't using multiple tabs and pages to browse? Have they been just ignoring all the security issues?

In an ideal world, JS would be fine, but until those webmasters offer a real money backed security guarantee, right on their site, that requiring me to have JS turned on will result in nothing untoward happening as I browse, I will avoid the vast bulk of them. I consider any site that requires JS to be an active malicious malware site. I've just had it with inflicted active scripting from webmasters. JS makes the Sony "rootkit" look like an amateur attempt. It was a good idea that is just wrong now, and there's no security fix for it other than not using it.

Re:IBM articles; Security with Javascript

[ergo98]

I was being sarcastic.

Re:IBM articles; Security with Javascript

[cyclomedia]

there's a lot you can do to degrade gracefully, such as posting a form back to the user with missing fields highlighted using html+css. unfortunatley all the AJAX example code i've seen use try()catch blocks, which will break pre javascript 1.5 browsers, which may be rare (IE4), but if you want to use SOME javascript and not just have it go bang in said circumstances you need a little sideways thinking ... i.e. use if()else instead

here's my attempt:

http://www.cyclomedia.co.uk/ajax_degrade.asp

Re:IBM articles; Security with Javascript

[HaydnH]

Javascript/AJAX is merely a client-side behavioural layer added on top of the content layer (pure HTML) and the style layer (CSS), it relies on both but shouldn't be necessary for the application itself to work.

That's why I believe that AJAX is wank! If you're using the XMLHttpRequest() object you're relying on the clients having javascript enabled for the application to work.

Re:IBM articles; Security with Javascript

[phlamingo]

... a genuine demand for functionality that it's impossible to expose without full Javascript support ...

If only this were true ...

The internal corporate sites I'm used have a pretty good chance of running only with I-stinking-E, using whatever demon-inspired lock-in technologies they are teaching to Microsoft "programmers" these days.

It really twists my guts in a knot. Then, I smile, and do what I have to to get the job done.

Re:IBM articles; Security with Javascript

[Isofarro]

I think users who are disabling JavaScript are already doing themselves more harm than good.

A website should work without JavaScript - that's the whole point of a webstandards based approach to website design. If a site requires JavaScript to provide access to data, it is fundamentally broken.

Its amusing that AJAX is promoted as a means for making websites more usable, but surely this should not be at the cost of its accessibility?

Nothing wrong with building AJAX based applications, just make sure you do it properly and offer the equivalent core functionality without requiring JavaScript. Its called progressive enhancement, or Hijax. (Note, drag and drop widgets are not core functionality, core functionality is about completing the task the website is intended for, e.g. purchasing a book.

Re:IBM articles; Security with Javascript

[Anonymous Coward]

> I think users who are disabling JavaScript are already doing themselves more harm than good.

The guy who wrote that is in the rather large group of people who have little to no understanding at all of computer security, I'm afraid. If you'll note the rest of his text, he apparently believes that if you protect yourself against a few bad apples, you can treat the Internet as a happy, safe place to play in.

He advocates the fundamentally ignorant approach which is analogous to leaving your front door unlocked, but hiring a security guards to go out and watch certain known criminals, to ensure they don't approach your house.

Re:IBM articles; Security with Javascript

[Anonymous Coward]

A website should work without JavaScript
Yes. But there is a difference between a webSITE and a webAPP. It's subtle, but it exists.

Ajax is OLD, web 2.0 - please....

[chrisdrop]

I am sorry - i cannot believe how much hype there is over 'ajax'. This is something that has been going on for so long. In the past - we have done this using 1x1 frames and parsed the Xml with light Js libraries. I guess I must be getting old - I always sneered at the 'mainframers' that would complain and say 'that is nothing new - we have been doing that since 1876'. Now - I guess I see the same thing. A new marketing hype name - and the old technique is here

I hope that the next version of the web is much more than HTML pages that don't refresh with a full round trip. Really though - we did this at least 5 or 6 years ago..... I like google maps, Flickr and the others, but it is NOT a revolution. Someone innovate for real and show me a revolution if you want to justify the Ajax hype or the Web 2.0 hype!!!!

-Irate -
Chris

Re:Ajax is OLD, web 2.0 - please....

[Anonymous Coward]

Yup, maybe in a few years someone will rename CSS to "Vortex" and get people excited about the possibilities that style sheets offer.

Re:Ajax is OLD, web 2.0 - please....

[lagerbottom]

Yeah. I mean I understand your reluctance to embrace a tech that was able to be accomplished before (though I might suggest that using hidden iframes was a bit less elegant). However, what do we care about hype. I let it roll off me. I like using the XMLHttpRequest object ...and you can get creative in your web apps with it. To be honest, I think most devs just opted for a page reload most of the time before all these libs and such came around. So in terms of "something new"...well it is new in the regard that we are seeing an explosion of web apps using it as decent way to give some of the features that fat client devs take for granted.

eh, I don't know. I am fine with it

Re:Ajax is OLD, web 2.0 - please....

[Anonymous Coward]

Yep, why I remember the first time our Jacquard loom was Slashdotted. Kids these days!

Re:Ajax is OLD, web 2.0 - please....

[Anonymous Coward]

Baby steps, rarely is "innovation" revolutionary, Baby steps...

Re:Ajax is OLD, web 2.0 - please....

[dbucowboy]

It's not about the technology as much as the innovative ways it is being implamented.

Re:Ajax is OLD, web 2.0 - please....

[Anonymous Coward]

Did you mean implemented or implanted? 'cause I've had an aversion to being implanted with technology ever since that bright light one evening while I was driving home.

Re:Ajax is OLD, web 2.0 - please....

[Anonymous Coward]

I guess I must be getting old

Yeah well that line of arguing is as well. Gee I haven't read that on every single AJAX thread evar! If you're not going to add anything don't say it

Re:Ajax is OLD, web 2.0 - please....

[GeekLord]

Although very simples, AJAX represent a very important step: its the first ever functionality that actually allows a web page to function more like a traditional app. But we only took the first steps. It took YEARS for us to realize what the hell an asynchronous request represented, and when we finally did, most of people waited to see it implemented on a more usabe fashion. This is where the multiple libraries enter.

Here is a nice start: someone already posted this, but here it goes again: http://en.wikipedia.org/wiki/AJAX

Now, web 2.0 is not about changing what the web represents, that much is already established. The web 2.0 is about improving usability and response time, an when properly implemented, ajax can improve those factors by an order of magnitude. Well, I dont know about you, but where I came from, a ten fold is always a revolution.

So stop whining and help us make the web a better one!

Re:Ajax is OLD, web 2.0 - please....

[Decaff]

Although very simples, AJAX represent a very important step: its the first ever functionality that actually allows a web page to function more like a traditional app.

The first ever.... apart from Applets, Flash, ActiveX...

Now, web 2.0 is not about changing what the web represents, that much is already established. The web 2.0 is about improving usability and response time

Actually, the term 'web 2.0' is so vague it is meaningless. I am not sure anyone can clearly say what it is about.

Re:Ajax is OLD, web 2.0 - please....

[GeekLord]

Applets, Flash, ActiveX, XUL and others are heavy load, platform dependent, bloated components that crippled the user experience. For an instance, flash or java wouldn't let one use the simple "back" button of his browser. Those technologies are much more of a glue then a real solution. AJAX is practically free from dependecies, really light and transparent. AJAX is the reason of success of all modern websites, like flickr and gmail. By the way, most people I know migrated to GMail for it's 1GB, but sticked to it for it's features and light interface.

Web 2.0 may be a little vague but is getting clearer every day. Check this out.

Re:Ajax is OLD, web 2.0 - please....

[Decaff]

Applets, Flash, ActiveX, XUL and others are heavy load, platform dependent, bloated components that crippled the user experience.

Applets, Flash and XUL and not platform dependent, and aren't large.

For an instance, flash or java wouldn't let one use the simple "back" button of his browser.

Neither does AJAX. You don't get back to the previous page state that way. Many users find this confusing.

Those technologies are much more of a glue then a real solution.

It is the other way around - the web page was a glue connecting applets etc.

AJAX is practically free from dependencies, really light and transparent.

And means you have to download visible code to the client.

Web 2.0 may be a little vague but is getting clearer every day. Check this out.

Actually, it think it is getting more confused every day! As that very article you quote says:

" But there's still a huge amount of disagreement about just what Web 2.0 means"

I think Web 2.0 is nothing more than an arbitrary label for whatever is the latest fashion in web design. If your users can hack your website, it is apparently web 2.0 :)

Re:Ajax is OLD, web 2.0 - please....

[Anonymous Coward]

Sorry, but reading how great Web 2.0 is on O'Reilly's site is like reading about how great the new BMW 3-series is in BMW Magazine. O'Reilly is one of the sponsors of the Web 2.0 Conference--a convenient hype engine for their next round of books.

Re:Ajax is OLD, web 2.0 - please....

[GeekLord]

"Applets, Flash and XUL and not platform dependent, and aren't large."
Java, Flash etc are platform dependent. Try to use the same install package on MAC OS and Windows.
A typical flash swf has more then 100kb. Compare that to a 1kb ajax code and tell me what is large...

"Neither does AJAX. You don't get back to the previous page state that way. Many users find this confusing."
Try to develop a full site in flash, then you'll see real confusion...

"It is the other way around - the web page was a glue connecting applets etc."
No applets no glue. AJAX is clean. Its the web 2.0, clean, fast and functional!
And ok, I agree "web" 2.0 is a marketeer's label for something you can't really label, but I think there is a clear trend happening here, that's undeniable. You can name it whatever you want, or dont name it at all. But the web is changing and I just love it! ;)

Re:Ajax is OLD, web 2.0 - please....

[Decaff]

Java, Flash etc are platform dependent. Try to use the same install package on MAC OS and Windows.

I do this routinely - on MacOS/X, Windows and Linux. No problems at all.

A typical flash swf has more then 100kb. Compare that to a 1kb ajax code and tell me what is large...

Sorry, I don't get the point. Firstly 100kb is totally insignificant on modern machines. Secondly, 100kb of flash won't look small compared to 100kb of AJAX, and the way things are going, that won't take long to appear!

You can name it whatever you want, or dont name it at all. But the web is changing and I just love it! ;)

I really don't things are changing much. I have seen supposedly 'Web 2.0' things like Wikis around for years, and they have had surprising little impact. There will be a few sites like Google Maps and Wikipedia that will have an impact, but most organisation neither want nor need these ways of working - they are struggling to keep information under control, not open it up to vast amounts of user interactivity.

Re:Ajax is OLD, web 2.0 - please....

[Anonymous Coward]

You just need to look an an interface such as Cognos's Report Net to see the merit of AJAX. You honestly cannot tell the differance between this app and a window application! WYSIWYG report editing and not a single postback (see http://www.cognos.com/products/cognos8businessinte lligence/product-images/reporting-1.html for screenshot).
It's absolute genius. Sure this must be one brilliant implementation out thousands of very poor or not so incredible implementations of this technology. But is shows you exactly what can be done and what will be done in the future.
Pure inspiration.

Re:Ajax is OLD, web 2.0 - please....

[Anonymous Coward]

you know, not to pull this one out of the Bag BUT ol' MS has had the exact DHTML effects as they are touting as revolutionary since 99... I used to do the same old trick with a basic applet to establish real time communications with the server in 00. and I know Borland had several built into there doomed IAPI using JS as early as 98 as well... not only is this NOT news... its another example of how anything with the word Google attached to it becomes a watershed. Why are they a media/geek darling?? the kinder genteeler imperial guard?

Yeah, new news indeed

[masklinn]

I mean, the first articles explaining how to create cross-browsers XMLHTTP requests ain't have more than a pair of years anyway...

Wouldn't it be slightly more interresting if Slashdot promoted useful stuff such as the Dojo or Mochikit Javascript libraries/toolkits (others exist btw, those are just fairly stable and advanced), which actually:

• Make that kind of stuff easier
• Make that kind of stuff more reliable
• Give great tools/shortcuts for working with javascript
• Actually work

Just wondering...

Re:Yeah, new news indeed

[ChrisZermatt]

Better yet, QooxDoo. Best I come across so far, even though its still in its early stages...
http://qooxdoo.oss.schlund.de/

Re:Yeah, new news indeed

[masklinn]

Looks like desktop-UI emulation in web pages, which is not the goal of Dojo, Mochikit or Prototype.

Interresting nonetheless, so it's been bookmarked anyway.

What's next?

[Stan Vassilev]

Aren't we supposed to know that. This is Slashdot after all.

Next article: What is cmd.exe?

Re:What's next?

[cnettel]

Isn't the /. audience as a general entity supposed to have left Windows (if they ever used it) while the command interpreter was still called command.com?

Funny title

[Jugalator]

OK, here goes some /. nitpicking but it was a funny title: Asynchronous Requests with JavaScript and Ajax. Someone need a reminder of what Ajax is again (Asynchronous JavaScript And XML).

Re:Funny title

[Xugumad]

Ah, so what you're saying is the title should have been "Asynchronous Requests for XML with Javascript and Ajax"? :)

Re:Funny title

[Kjella]

OK, here goes some /. nitpicking but it was a funny title: Asynchronous Requests with JavaScript and Ajax. Someone need a reminder of what Ajax is again (Asynchronous JavaScript And XML).

Not to mention that it doesn't actually deal with XML, so it is not Ajax - it is just Asynchronous Requests with JavaScript. Can you say "buzzword applied without understanding or meaning"?

Re:Funny title

[volve]

Next you'll be saying that there's no such thing as an "ATM Machine" or a "PIN Number". The's unpossible!

Damn commies.

-volve

Re:Funny title

[DrEasy]

Maybe it's a "Gnu is Not Unix" infinite recursion acronym kind of joke...

Re:Funny title

[fbg111]

Not quite, sounds like the title was written by LISP-kiddie trying incorporate some recursion. Try this instead: 'Asynchronous Requests with Javascript and Asynchronous Requests with Javascript and Asynchronous Requests with Javascript and Asynchronous Requests with Javascript ..."

Pretty 101 - What happens when you hit the wall?

[Anonymous Coward]

I have seen this article in different formats everywhere, however I still read them just to see if there is ever a new spin.

It seems to me that everyone is happy to send a text string in one direction and then they proclaim they are the champion. When the reality is you will saturate your server with http requests if you keep everything functioning on such an atomic scale that each request is for but one piece of info from the server.

I wrote a simple article that goes 1 step deeper and actually talks about shipping complex data types over one AJAX request and parsing at the client.

Take a read if this stuff is interesting to you:

http://therustednail.blogspot.com/2005/11/ajax-tip -01-method-for-delivery-of.html

"with JavaScript and Ajax"?

[BarryNorton]

Isn't it: 'AJAX: Asynchronous Requests for XML (and other things) from JavaScript'?

Seriously, Sunday's a slow news day and chance for a slower-paced review, but this acronym was thrown around all last year - it's a bit late for a one-liner from some anonymous who doesn't even understand what he's talking about...

Implementing AJAX is so uniform

[Idimmu Xul]

that you may as well go with a library like CPaint http://cpaint.booleansystems.com/ . It saves a lot of time, and the principle of AJAX is so simple anyway you aren't really missing out on any 'under the hood' shananigans. CPaint combined with some of the JavaScript from Scriptaculous http://script.aculo.us/ means you can quickly knock up something impressive and responsive with a pretty user interface that will let you extort as much money as you like from any Venture Capitalist you can garner an appointment with!

What to do with XML results?

[ccady]

Bah. That's easy. The business of creating and using an XMLHttpRequest is well-documented and easy to do. What is far less well documented is how to access the resulting XML as a cross-browser XML DOM object. (Accessing it as text is easy.)

How does one access the results 1) as an XML DOM, and 2) in a cross browser way. I am currently investigating Sarissa.

I challenge someone to come up with a good article on that!

Re:What to do with XML results?

[berndtj]

I had this same problem. How about I just give you some code?

The code attached does exactly what you ask, and I included a function which parses the xml DOM into html DOM assuming of course that the XML that you fetch is XHTML. The code should work pretty much out of the box on mozilla browsers, you may however have to change the document encoding (of the document you are fetching) in order for it to work under IE as well (I include the following in my jsp header "pageEncoding='ISO-8859-1'"). I also added a request cache, you of course don't need this, but I was having some synchronization issues.

xmlhttprequest.js

Re:What to do with XML results?

[bahwi]

Use AJAX without the X. JSON works quite well when XML is overkill. Sometimes you will need the complexity of XML, but much of the time(including those examples in that article), XML is complete overkill.

Re:What to do with XML results?

[Bogtha]

It's not covered in many Ajax tutorials because manipulating XML with the DOM is the same as manipulating HTML with the DOM. Any DOM tutorial will suffice.

Re:What to do with XML results?

[Malc]

And there are a lot of little gotchas too. For instance with IE version: non-HTTP requests (e.g. file:// protocol) do not set request.status to 200. There are also situations where XML isn't converted in to XML (file:// or ftp:// protocol, or when the server's Content-Type is set incorrectly) - this has to be detected and the response text assigned to a separate XMLDOMDocument for parsing. I think only IE can create XMLDOMDocuments as well - other browsers only provide from the XMLHTTPRequest object.

Re:What to do with XML results?

[Myen]

For Mozilla-related things, there's a DOMParser constructor that may be useful. Use parseFromString() since you don't have access to nsIInputStream :)

(If you can, XPath is lovely for getting stuff out of DOM trees!)

Easier than the article

[esconsult1]

Just use the excellent prototype javascript library instead. Saves a ton of time. It's cross platform, dev language agnostic, and has super sweet functionality built in.

I guess you can use JSON, and XML data formats with prototype, but I just use plain old text to accomplish whatever I want.

Prototype is also used in Ruby on Rails and its PHP analogue CAKE, and also the excellent perl framework Catalyst

oh!

[darmey]

an article about exactly what I'm going to do at work tomorrow. Thanks, Slashdot, but no thanks.

Re:If you like this, try too AJAX Developer's Jour

[kurth]

My honest first impression was that ti was a spyware site, you know, the ones that look useful, but are really just there for the sake of serving ads?

Is Ajax all win-win

[William Robinson]

Ajax is around for quite some time and has been reported as one of 15 important tech concepts that might rule 2006. Google has demostrated how to use Ajax and so on.

I sincerely want to understand if there are any pitfalls. Is Ajax win-win for all of us? are there any security or any other concerns? What could be an argument against Ajax?

TIA for your answers.

Re:Is Ajax all win-win

[wk633]

- it's not very ADA complient

- it doesn't work the way the web is designed, as page->page->page, which can create problems. You can't page-page

- you have to be very careful if you ajax app is making changes to the DB, not just reading

- 'win-win' doesn't really fit. It's another tool, and like any tool it can be used in the wrong place. The risk is that as 'the' thing, it's going to be used everywhere, even a lot of places where it really doesn't make sense. Kind of like companies putting dumb Flash animations all over their pages just to show they can.

Re:Is Ajax all win-win

[lastchance_000]

I wish I had mod points for this. I'm a big proponent of the right tool for the right job, and Ajax isn't always the right tool, especially considering the parent's points.

Re:Is Ajax all win-win

[berndtj]

There are a few pitfalls.

1. The browser history becomes useless
2. Google won't find your content
3. Won't support older browsers

There are more I'm sure, but it's still early here on the west coast.

Re:Is Ajax all win-win

[DavidTC]

you have to be very careful if you ajax app is making changes to the DB, not just reading

I would argue that you have to be less careful with AJAX than traditional pages WRT that.

With traditional pages...let's say someone sees something wrong with one of the entries. They edit it. Oops, still wrong. They edit it again. Okay, there.

Later, they back up through the pages. What's this POST message? Okay, we say no there, and keep going...hey, wait, this is wrong again. Let me edit it. Hey, it's correct on this screen...

With AJAX, you can't get anything like that. The lack of going 'backwards' and 'forwards' in your editing is a good thing, because that doesn't work in the first place!

With AJAX, it's always 'here is the database'. If they leave that page, and come back, they probably get the same page(1), granted, but if that's the only way to edit the database it couldn't have changed. And they can't page around inside their own editing session, and can't end up with an inconsistent view between pages in the past and the current reality of the database.

1) And, of course, some AJAX things just always pull their info from the server, via javascript in the page onLoad, instead of generating the page with the correct info. Hence every viewing of the page will be correct as of the second the page was displayed, not when it was first downloaded into the browser.

Re:Is Ajax all win-win

[Bogtha]

it's not very ADA complient

Ajax is as accessible as any other form of Javascript - it's accessible if done properly, but there's a lot of people who either don't bother or don't know how.

it doesn't work the way the web is designed, as page->page->page, which can create problems.

The way the web is designed is precisely what causes one of the problems that Ajax solves. There are many tasks for which going from one page to another simply doesn't make sense. If I have a list of things and change the order of that list, I'm still looking at the same page. Conceptually I'm not going from one page to another. Slashdot moderation is another example - when you moderate a comment, it makes no sense to think of it as going from one page to another.

Yes, when you are using Ajax when you really are going from page to page, that can cause problems, however there are workarounds to fix that.

you have to be very careful if you ajax app is making changes to the DB, not just reading

Why? I've never heard that criticism before.

It's another tool, and like any tool it can be used in the wrong place. The risk is that as 'the' thing, it's going to be used everywhere, even a lot of places where it really doesn't make sense.

That's true, but you seem to be looking at the worst examples of Ajax and assuming that all Ajax must necessarily be like that.

Re:Is Ajax all win-win

[robgamble]

Keep your AJAX light and simple.

People keep forgetting that Ajax ties you to client-side Javascript. The browser is a terrible platform on which to deliver applications! JS development is far worse than coding on the server. Consider:

* You can (almost) never debug your JS code
* No strong typing... no compiler to catch even the simplest of mistakes and typos
* Rich use of JS performs very poorly
* Service packs and hot fixes break things all the time (XP SP1 introduced random characters into our rendered DHTML, MS had no clue why. More recently MSXML 4 now crashes making web calls to our servers, we use alternate MSXML versions just fine and machines that are not fully patched work fine on XML 4.0)
* Browser incompatabilities
* Timing issues

Net sum: use Ajax to perform occasional tricks, or to overcome a particularly meddlesome usability issue that is promoted by today's least-common-denominator browser UI controls. But for your sanity, make sure you are still writing a server-side application.

Re:Is Ajax all win-win

[wk633]

Ajax is as accessible as any other form of Javascript

True- perhaps it's just a new level of required understanding. Most of the web still hasn't caught up with really making things ADA. The people who make Web 1.0 sites ADA will probably make Web 2.0 sites complient as well- at least in as much as it makes sense. It doesn't make a lot of sense for google maps.

I recently saw a page that had a graphic with the company contact info in it (address, phone etc) and the alt tag was "Company Contact Info Image".

The way the web is designed is precisely what causes one of the problems that Ajax solves.

Sure, and your example of comment moderation is a good one. Also things like Java applets to create context sensitive dropdowns. Pick a country, and the region dropdown contains the regions for that country, e.g. No need for the bloat of a java applet just for that.

As for being careful with DB updates- I didn't phrase that very well. Like ADA, it's just something that people should be thinking about now, but many aren't. Any web designer who understands why you cannot rely on client side validation alone won't have a problem. More concrete example- I'm doing a project for myself in ASP.NET. ASP.NET Forms authentication is great, and takes care of all the 'you have to be logged in to see this page' stuff. But it doesn' take care of a specially crafted web service call hitting my DB, and in my case doing a delete. It's not an impossible problem, but if I were careless, it would be a big hole.

There's also an example in Pragmatic Ajax (beta book, print version coming out soon) of a google pre-fetch system hitting every link on a page to pre-load, and some of those links were ajax GET requests that deleted from the DB. Web site eating spiders!

That's true, but you seem to be looking at the worst examples of Ajax and assuming that all Ajax must necessarily be like that.

No, I think Ajax is very cool, and am building an app of my own with it now. And I'm looking at how it can fit into and enhance projects I'm working on. But the parent asked if there were any downsides, or if it was 'win-win'. So, in pointing out the potential losses, I perhaps sounded more negative than I really am.

XML isn't really needed.

[ankhcraft]

If you're just communicating with other parts of your app instead of 3rd-party components, why use XML? Append a script tag to the document, using the DOM. Put as many GET request variables in the src attribute's URI as you need. Return JavaScript code from the server. Array initializers, object initializers, whatever. You can even put an onload handler on the script tag so you can execute code once the request has completed. This is what I do. There is reason to continually generate and parse XML here. It's just an extra unneeded step. No need to use XML unless you're dealing w/ 3rd-party components that expect it or you need to data that isn't easily packed into GET request variables.

Re:XML isn't really needed.

[BarryNorton]

If you're just communicating with other parts of your app instead of 3rd-party components, why use XML?

Because you hope that you're not just developing a piece of disposable dot-com fluff, but something that will be maintained and extended, that will become useful as part of new projects, and maybe even to third parties?

Re:XML isn't really needed.

[oliverthered]

In 5 years the technology will have moved on, all software is disposable.

Re:XML isn't really needed.

[ankhcraft]

Okay, I have to reply, because now you're just rewording part of my statement in lieu of a useful reply.

I just _said_ that the XML isn't useful _unless_ you need/want communication with 3rd-party components that use XML.

Plus, you also seem to be hinting that one should always aspire to connect their app up to 3rd-party components or even that one should always do the work to make the app integratable w/ XML before even knowing that this is necessary or required.

I'm sorry, but this is just another example of wasted programming hours and wasted money spent on the same. If the app does not need it, nobody has asked for it, and suggestions to the contrary are not agreed with, don't build it.

Re:XML isn't really needed.

[BarryNorton]

No, I was saying the opposite - the difference that service-oriented architectures are making (over the component-based stuff I used to do in the Industry) is that people making these kind of apps can become service providers so much more easily. I.e. not that you'll want to integrate 3rd party components, but that if you write a nice web-app, people will want to use your underlying services within their own apps. Tell me I'm being naive and academic, but this is definitely the case with a lot of the first (or arguably second) generation Ajax stuff - take Google Maps, for instance...

Re:XML isn't really needed.

[BarryNorton]

In 5 years the technology will have moved on, all software is disposable.

Sorry, but one of the very first things I did with 'asynchronous messaging and Java' (in 97 back before we got around to making up stupid acronyms) was interface with old VMS systems. Software developers might move on, but very often their software stays around (a lot longer than it was originally designed/expected to)...

Re:XML isn't really needed.

[ankhcraft]

No, I don't need to tell you that you're naive or academic.
I need to tell you that you've done quite a brilliant job... discussing the wrong thing.
While you discuss SOA's and the like, you forget... that we are not discussing a SOA.
We are discussing whether or not to use XML for user-interface interactions with the back-end server when NO other requirements call for it. Most SOA's require XML.

So we are back to previous points of mine: There is no need to introduce an additional level of abstraction with parsing and generating XML, if no components in the system require it. If the app does not need it, nobody has asked for it, and suggestions to the contrary are not agreed with, don't build it.

Re:XML isn't really needed.

[DogDude]

There aren't too many websites that make sense to act as service providers. Most websites are simply just informational, or shopping carts. I provide our products data to all of the major search engines/shopping sites, but each interface is completely different. This idea of some kind of universal XML has *never* paid off, and I can't imagine it ever will. I agree with the parent poster... it's a lot of waste, both in programming cycles, and machine cycles/bandwidth to add in a layer that is unnecesary.

That being said, I've been using XMLHTTPRequest for many years for some internal stuff. No actual XML anywhere on the site, though. If I did waste my time adding in "XML", my app would be significantly slower.

Re:XML isn't really needed.

[ObsessiveMathsFreak]

If you're just communicating with other parts of your app instead of 3rd-party components, why use XML?

Because XMLhttprequest.open returns a DOM tree object. There's no other reason really.

Re:XML isn't really needed.

[BarryNorton]

While you discuss SOA's and the like, you forget... that we are not discussing a SOA

I disagree. If you're supplying data, i.e. something not human readable, over the HTTP stack, you're providing services - albeit more RESTful than SOAP-oriented ones...

Before we drift too far, I'm not saying that one should always use XML (in fact, if you look at my first reply in this article, you'll see that I brought up the point that AJAX doesn't have to imply XML before you did), but if there's any chance that your application is going to drift/develop, or that someone else will want to use your service, then I'd say you should take the time to at least make an XML encoding...

Re:XML isn't really needed.

[BarryNorton]

There aren't too many websites that make sense to act as service providers. Most websites are simply just informational

Semantic web zealots might say that if something is useful written into a webpage (to be human readable), it's useful to expose it aside from the presentation. There again, they'd probably want you to waste your time, (and 'precious' compute cycles ;), or ontological mark-up, not just XML tags...

Re:XML isn't really needed.

[ankhcraft]

There's no need to rely on XmlHttpRequest. You can take advantage of a method of data transfer that does not require any DOM objects nor glue code to interface to the algorithms that manipulate them (neither or your own nor any 3rd-party request library). The server may simply respond with the JavaScript data structures (variables, array initializers, object initializers). And now, all of your variable data is happily parsed into the runtime environment's symbol tables.

Re:XML isn't really needed.

[oliverthered]

"but very often their software stays around"
but it is eventually replaced with a re-write.

Sarissa tutorial

[Spy der Mann]

There ya go :)

From the department of redundancy department

[Stan Vassilev]

"Asynchronous Requests with JavaScript and Ajax"

AJAX means "Asynchronous JavaScript & XML", so if we'll be redundant, do it properly:

"Asynchronous Requests with JavaScript and XML and Ajax"

- From the department of redundancy department

Re:AJAX, I love it

[rdwald]

This is ajax technology. It has been spreading rampant around the web recently.
www.ajaxian.com is a great resource for AJAX type information.
also wikipedia - http://en.wikipedia.org/wiki/Ajax_(programming)
This technology, if used write, well revolutionize many web sites.
Realtime sports w/o flash (Already seen on ESPN.com Scoreboard)
Probably a few sites with stock market tickers.. etc.
I really love AJAX!

Were you trying to be Insightful or Funny?

Re:If you like this, try too AJAX Developer's Jour

[Mike Savior]

By all means a pretty site does not mean a good site, there's obviously great content you can find on minimalistic or ass-ugly pages- but is it just me or does for a site preaching the benefits of ajax, it's really disgusting-looking?

Much simpler/better cross platform Ajax Objects...

[mythz]

If anyone wants a lightweight, simple, cross-platform AJAX objects they should check this out: http://prototype.conio.net/ The well-written javascript (prototype.js) library is the basis for many innovative opensource AJAX frameworks/libraries including: - Ruby on Rails (built-in support) - http://script.aculo.us/ - http://openrico.org/ - http://bennolan.com/behaviour/

I don't like spam!

[belg4mit]

Waitress: ...or Lobster Thermidor a Crevette with a mornay sauce served in a Provencale manner with shallots and aubergines garnished with truffle pate, brandy and with a fried egg on top and spam.
Wife: Have you got anything without spam?
Waitress: Well, there's spam egg sausage and spam, that's not got much spam in it.

Re:I don't like spam!

[belg4mit]

Spam spam eggs and spam is redundant, get it?

Samy is my Hero

[TubeSteak]

This is how you use AJAX to create XMLHttpRequest instances.

The Story: http://namb.la/popular/

The Explanation: http://namb.la/popular/tech.html

Oh so rare, so rare

[SunPin]

What kind of post is this? All about http request?

I believe we have finally encountered negative information. Read this and you will know quantitatively less than you did before coming here.

XML Is Not Required: Use Key=Value Pairs...

[Anonymous Coward]

or fixed format, or unencrypted string, or encode the data in an encrypted string, or any of the formats defined for email, etc.

AJAX perhaps should have been labelled "AJA" or "A.J.", since AJAX is not limited to XML.

Parsing XML requires loading & execution of a parser and XML is computation intensive, so it is more efficient to restrict XML to those places where you must communicate with "otherworldly" apps (constructed by outside world). But you have many choices

This is the usual way to do AJAX

[Metasquares]

A more cross-browser solution is to fall back to pulling content from an IFRAME (either a hidden one already on the page, or, preferrably, one created with the DOM) when XMLHttpRequest is not present (in either Microsoft's browser or others). It's pretty trivial to write a Javascript class that will do this.

For that matter, the most cross-browser solution is to default to using normal page requests when Javascript is unavailable (by defaulting to those actions and using JS to intercept them in the onclick or onsubmit events). I wrote a whole site this way. It degrades almost perfectly without Javascript support. Granted, that won't work for sites like Google maps (without a fundamental shift in how their UI is presented, anyway).

overriding the constructor

[ydnar]

With JavaScript, the object that is returned by the newoperator is the return value of the constructor. Which means you can set/override pretty much any object/property with a pseudo-constructor that returns any arbitrary object (class).

Adding XMLHttpRequest to Internet Explorer:

if( typeof window.XMLHttpRequest == "undefined" ) {
    window.XMLHttpRequest = function() {
        var types = [
            "Microsoft.XMLHTTP",
            "MSXML2.XMLHTTP.5.0",
            "MSXML2.XMLHTTP.4.0",
            "MSXML2.XMLHTTP.3.0",
            "MSXML2.XMLHTTP"
        ];

        for( var i = 0; i < types.length; i++ ) {
            try {
                return new ActiveXObject( types[ i ] );
            } catch( e ) {}
        }

        return undefined;
    }
}

y

Re:overriding the constructor

[Anonymous Coward]

Is this code under GPLv3? ;)

Re:overriding the constructor

[Anonymous Coward]

yay, Article owned.

(meh, still don't like AJAX...why the hell are people making websites in flash and applications in html...)

Re:overriding the constructor

[ydnar]

BSD actually (see bottom of script):

http://www.livejournal.com/js/core.js

Re:overriding the constructor

[Malc]

Flash provides XPath support.

Re:If you like this, try too AJAX Developer's Jour

[Parham]

It took me less than 50 milliseconds to realize that site wasn't good... it's full of advertisements and there is little teaching going on. If I visited an AJAX-resource website, I'd like to see some code as soon as possible.

Old news is Still old News

[Mr.Dippy]

Wow. I built a couple of apps back in June of 2005 with basically that same methodology! Thanks IBM and Slashdot! Oh and it was cross browser compatiable as well.

55% Of Sites Use JavaScript In Some Form

[Anonymous Coward]

The remainder don't (click on "Research Reports" tab and then on "Tech Penetration" link).

My understanding is that half of Europeans run with JavaScript disabled but I have no hard figure.

I am dismayed at the number of sites that use JavaScript when it is unnecessary (clicking on a link, etc.). Perhaps there is some explanation for this, some use in it, that someone else can please provide?

Re:If you like this, try too AJAX Developer's Jour

[Anonymous Coward]

How are you supposed to read the articles when they're hidden by pop-over ads? I clicked on about a dozen, and they're all hidden by an ad titled "Learn from the AJAX Masters." Why go to the trouble of building a web site and creating content if you're going to intentionally make it unusable? Nice waste of time.

Re:If you like this, try too AJAX Developer's Jour

[wik]

Suppose the ads were served with ajax. Then you could claim it as a (profitable) example.

try AFLAX?

[MORTAR_COMBAT!]

http://www.aflax.org/

poke around in those (excellent) libraries a bit, maybe you'll find more basic socket handling facilities that you are looking for.

maybe "web 3.0" is closer than we think. servers pushing data to web clients.

Re:try AFLAX?

[dahamsta]

Uh-oh, server push. Fire In The Hole!

xajax

[Anonymous Coward]

I've found xajax to be very powerful and easy to use.

Re:xajax

[DavidTC]

I will second this. xajax rocks, espcially if you're actually a PHP programmer who's ended up doing AJAX by default.

Everything is trivally convertable. Like you have an order form. People write their address, submit a form, you check it, and show them an updated page?

Just change $_POST to some other variable, have it submitted via AJAX to there. All the form is in $foo['bar'], just like it used to be in $_POST['bar']. Then write out the changes to page to a div you already set up. (If you're really lazy, unset($_POST); and $_POST=$foo;)

Have a list form a database with a seperate pages for editing entries? Just make div somewhere, when they click on each entry, suck it into the div, do the editing, and clear the div when they click 'done'. You already have to code to make the page, so just strip out the surrounding HTML and use that. Feel free to make this a floating div in front of everything...you can even move it around via xajax.

And if you know Javascript, it's even better. You can pass arrays back and forth, which is incredibly useful where, for example, you formerly had to keep a Javascript and PHP array in sync. You can pass out random Javascript from PHP. (You cannot do the reverse, but that would be rather dangerous anyway.)

And with xajax 0.2, they've exposed almost all the PHP 'page changing functions' as Javascript also, so it works as a straight DHTML library too, without the round trip. This was my only annoyance with the first version...often I wanted to do something in pure Javascript, but didn't have any easy way to do that, because the user-accessable functions only existed in PHP, despite the fact all those functions did return XML telling xajax to call back-end Javascript functions!

No Thanks to AJAX Developer's Journal

[Anonymous Coward]

What does ethics have anything to do with professional reporting and journalism?
-- Fuat Kircaali, CEO of Sys-Con Media, publisher of several computer magazines

Yet another one of Sys-Con's online publications people should avoid for various reasons.

MOD PARENT -1

[arodland]

Redundant.

Firefox AJAX Debugger

[Val314]

pretty usefull: https://addons.mozilla.org/extensions/moreinfo.php ?id=1843&application=firefox

"FireBug is a new tool that aids with debugging Javascript, DHTML, and Ajax. It is like a combination of the Javascript Console, DOM Inspector, and a command line Javascript interpreter."

thanks http://weblogs.mozillazine.org/gerv/archives/2006/ 01/firebug.html for the tipp

For those that missed it...

[ZeldorBlat]

This is the follow up article to the one posted a month or two ago:

http://developers.slashdot.org/article.pl?sid=05/1 2/11/2327239

Fascinating

[Qbertino]

I find it fascinating how this Ajax buzzword took of almost the instant some new economy web consultant wisecrack coined the term in his blog. The stuff Ajax stands for all had been done before but suddenly everybody acted as if there'd be something new.
It's even admitted by it's 'creators' that the term Ajax is a buzzword. Being in the business of web conltant wisecracking myself I actually find it very usefull. From now on there is no chance whatsoever customers, clients and partners I talk to will get another chance to mix up Java and JavaScript.

My way. Sort of:

[unixbum]

A simple javascript function which I use on all of my AJAX Apps will create an XMLHttpRequest object in just about every major browser. Excuse the horrible bastardization of exceptions. From the looks of the article they are using something quite similar.

function createXMLHttpRequest() {
        try { return new ActiveXObject("Msxml2.XMLHTTP"); } catch(e) {}
        try { return new ActiveXObject("Microsoft.XMLHTTP"); } catch(e) {}
        try { return new XMLHttpRequest(); } catch(e) {}
        alert("XMLHttpRequest not supported");
        return null;
}

Re:My way. Sort of:

[Anonymous Coward]

You're forgetting these too.

"Microsoft.XMLHTTP",
"MSXML2.XMLHTTP.5.0",
"MSXML2.XMLHTTP.4.0",
"MSXML2.XMLHTTP.3.0"

Don't you just hate m$?

Re:If you like this, try too AJAX Developer's Jour

[JamesOfTheDesert]

I clicked on about a dozen, and they're all hidden by an ad titled "Learn from the AJAX Masters."

And ads that proclaim James Garrett as "The Father of AJAX" cast doubt on the whole site. Seems the site is intended to drive overpriced conferences.

um...

[Anonymous Coward]

The title reads "Asynchronous Requests with Javascript and Asynchronous Javascript and XML"

Apparently someone doesn't have a complete understanding of the whole 'acronym' concept

Besides this, Ajax primers are old news, people have moved on. I myself got Javascript Object Serialization to work, making storing javascript data absolutely trivial, much easier than mucking around with XML, thus essentially making the 'ajax' acronym obsolete.

The Irony... The Irony...

[Baldrson]

From the TIBET(tm) writeup on "AJAX":

Ironically, the real value in XMLHTTPRequest isn't that communication can be asynchronous. Form submissions, the previous way of handling server communication, were and still are asynchronous. XMLHTTPRequest actually makes it possible to support _synchronous_ calls and provides a single unified way to make either type of call.

Most writings on AJAX would have you believe that's enough -- make an asynchronous call, get an AJAX application. Unfortunately, as anyone who's done much programming with asychronous calls (aka threads) can tell you, making the call is the easy part -- it's coordinating the results that's hard. A simple real world example highlights "the sync problem".

The Sync Problem

Its a common client-side requirement to fetch a template containing static data along with dynamic data from a web service call, blend them into a single UI element, and then display that element in a portion of the user's currently displayed page. In this common case you've got two separate data sources meaning you have two separate calls whose results have to be blended only after both complete. When confronted with this reality most developers switch to making synchronous calls (taking advantage of XMLHTTPRequest's truly new feature to "cheat"). If you decide to hang in there and stay with the asynchronous call format that's great, but we've yet to see a single AJAX toolkit that offers you any kind of multiple-request coordination -- so you'll end up writing the synchronization logic yourself.

If you use TIBET its simple:

// set up two requests to make the async calls (you can have more if you like)
request1 = ServiceRequest.create(dc('async',true,'other','par ameters'));
request2 = ServiceRequest.create(dc('async',true,'some','para meters'));

// create a function to observe the completion signal we'll be sending below
response = function(aSignal) { alert('The requests are done'); };

// create an "And Join" saying both need to complete (TIBET also supports "Or Joins")
join = TPAndJoin.create('AllDone');
join.addObservation(request1);
join.addObservation(request2);

// tell our response function to observe the signal our join will send
response.observe(join, 'AllDone')

// activate the requests...TIBET handles the rest
request1.activate();
request2.activate();

Since TIBET was built before you could "cheat" via XMLHTTPRequest it's been designed to support asychronous event coordination from the start. TIBET uses event signaling and a set of types based on the Workflow Management Coalition's petri-net models for workflow event coordination to handle event synchronization. Because it uses events rather than XMLHTTPRequest callbacks you can use the previous example's pattern to join responses from both the server and the user since interactions with the user are asynchronous as well.

Re:The Irony... The Irony...

[linuxhansl]

When confronted with this reality most developers switch to making synchronous calls (taking advantage of XMLHTTPRequest's truly new feature to "cheat")

Way before this all was called Ajax I used the following simple method:

1. Keep a - client side - queue of requests to be made to server.
2. Whenever the current queue is sent to (and processed at) the server, the client places new requests into the queue.
3. When the server finished processing (or a timeout occurs) the queue (if not-empty) is flushed to the server.

In order to handle timeout every server request also has to be tagged with a version to detect (and ignore) delayed replies from the server.

Hence there's at most one server request outstanding, ordering is guaranteed, etc, at the expense of less interleaving of network RTT and processing time at the server.

If you dont understand all of this....

[hayriye]

* open(): Sets up a new request to a server.
* send(): Sends a request to a server.
* abort(): Bails out of the current request.
* readyState: Provides the current HTML ready state.
* responseText: The text that the server sends back to respond to a request.

Don't worry if you don't understand all of this (or any of this for that matter)

I think everybody understand all of this, if somehow involved with software development.

This article is useless like 90% of the DeveloperWorks articles.

Re:If you dont understand all of this....

[scdeimos]

Agreed. From TFA:

This is where that onreadystatechange property comes into play. This property allows you to specify a callback method. A callback allows the server to (can you guess?) call back into your Web page's code. It gives a degree of control to the server, as well; when the server finishes a request, it looks in the XMLHttpRequest object and specifically at the onreadystatechange property.

The author of this article obviously doesn't know how XMLHttpRequest works if they think that the remote web server is running code in your browser like this. The callback capability is implemented in the XMLHttpRequest object running browser-side.

Well THAT skews your results.

[Andy Dodd]

If your app requires JavaScript, then clearly, anyone who is logged as using your app WILL have JavaScript enabled.

Your logs won't show how many people wanted to use your app but didn't because they had JS turned off for whatever reason.

Re:Well THAT skews your results.

[kchrist]

Your logs won't show how many people wanted to use your app but didn't because they had JS turned off for whatever reason.

That's not necessarily true at all. The most primitive way to see them would be to redirect people with JavaScript disable to no-javascript.html and count the hits to that page. There are any number of other, better ways to count these potential users as well.

These kinds of stats are important for anyone running an app that requires JS. I'd be extremely surprised if they don't know exactly how many non-JS browsers they have hitting their site.

Re:Well THAT skews your results.

[secondsun]

We used to do everything as a link.
We found out that it was silly because noone had JS turned off. Therefore we made our app better by taking advantage of this fact.

Re:how are you gentlemen ?

[Anonymous Coward]

haha loopback, forgot about that one

Even better, with opera support

[ggpauly]

Based on Andrew Gregory's excellent XMLHttpRequest javascript object as well as other code from various sources credited within, is the Ring Ajax Code Kit.

This extends the overridden XMLHttpRequest with methods to invoke server scripts with generalized get and post methods and easy-to-use form-based get and post methods.

Another Ajax Article?

[Heembo]

Oh my - a slashdot Ajax articele! Oh wait, haven't we dont this before here? I mean, we have already talked about Ajax as a buzzword http://it.slashdot.org/article.pl?sid=05/05/24/159 211&from=rss as well as State-Of-The-Art Ajax-Office apps http://slashdot.org/article.pl?sid=05/09/29/000223 &from=rss we also got into Ajax on server load http://ask.slashdot.org/article.pl?sid=05/12/05/23 39256 - now why are we "getting back to basics" and talking about an entry-level IBM Ajax article that has year-old information on already well established techniques?

WTF is the big deal?

[Heembo]

Who the hell ever deals with the XMLHttpRequest object long-term over the course of real Ajax development? I simple wrote a few functions to deal with this in my toolkit, or I copy and paste from the last project, and bang, I'm done with XMLHttpRequest. I focus on the XML layer, application level coding, look and feel, database stuff... but I do not spend any real time on the XMLHttpRequest object. WTF is the big deal?

The title!

[amhmd]

Expanding the acronym AJAX, the title of the post would be:

Asynchronous Requests with JavaScript and Asynchronous JavaScript and XML.

Nice emphasis of the important elements.

What the heck?

[wetfeetl33t]

AJAX????
I thought all the hubbub about that died down months ago. I mean, what is this, 2005?

Re:If you like this, try too AJAX Developer's Jour

[Anonymous Coward]

Why? Dude... ITS AJAX. BFG.

Don't get me wrong, AJAX is useful, I use it. But COME ON! A whole journal devoted to AJAX?
Next some one will create a following for binary logic, and tout it as the "Next Biggest Thing". Get real.

Everyone else plugs theirs, so here's mine...

[fzammett]

A little shameless self-promotion, since no one else is shy about pushing what they think is good :) ...

Another nice introductory article to AJAX, including a working example webapp of a using AJAX with a Struts-based application:
http://www.omnytex.com/articles

A more "real-world" example of using AJAX: a Struts-based chat app:
http://struts.sourceforge.net/ajaxchat

The AjaxTags component of Java Web Parts, which allows you to add AJAX functions to a page in a purely declarative way using a extremely simple JSP taglib:
http://javawebparts.sourceforge.net/ (click on the Javadocs link and look at the javawebparts.taglib.ajaxtags package)

(Note that this AjaxTags is *NOT* the same as the project named AjaxTags that you may have heard of... this is an unfortunate naming conflict... this AjaxTags actually existed first, and this one is a subcomponent of the larger Java Web Parts project... it also has a very different focus than the other AjaxTags)

A useful article for non Java and .Net gurus

[FoxyFox]

Hi, In contrast to most Slashdot readers I found this article useful. Some of you forget that you are developing .Net and Java all the day, while there are also people like me that spend most time in C, Clusters, distributed file systems etc. The Article is very good, and I am already trying out "Web 2.0". It is one of the best tutorials I have read for a long time. The philosophy is: There are always Slashdot readers that are not updated in the J2EE world, and that like to read informative documentation on the subject.

Ugh

[kuzb]

They lost me as soon as I saw "Web 2.0" in large bold letters. For once, can we keep the marketing BS out of techincal articles? They're like sandpaper down the side of my face.

Re:Ugh

[FoxyFox]

Why are Code monkeys always so negative? The article is pretty good!

So I guess

[Bitsy Boffin]

Ric Romero has started working for IBM now?

you're joking, right?

[Anonymous Coward]

For me, the Web WITH javascript and cookies is a lonely, dysfunctional place. You developers need to get your heads out of the scripting sand and start coding for Internet users who turn off all of your disgusting scripting and other bugs.

This isn't off-topic

[Anonymous Coward]

The problem with enabling javascript or any kind of client-side scripting is the same problem as with cookies or Flash - once enabled, it is enabled globally, and the user can't prevent those technologies from being used against his interests.

Flash might be okay ... if the stupid ass web developers weren't using it to track users, or to bog-down their webpages with horrid flashing advertisements and blinking crap. Java script might be okay, if it wasn't such a damned security risk and burden on the client-side. Heck, even cookies might have an occasional good use or two - if the slavering web developers weren't wetting themselves all over in their haste to use cookies for tracking and other harms.

Yes, AJAX leads to (all of the above harms and more) which leads to unwanted tracking of users who simply want a fucking anonymous Internet experience, and thus ultimately leads to spam.

I don't care about all the groovy things Google is doing with Google Maps or some anticipated Microsoft-less web-based word processor, if enabling the technologies which will make Google Maps etc. work means I have also opened a door letting all of the other immoral web developers come howl at me with their devious garbage applications working against my interests. AJAX is like opening your door a crack to let a friend in, but 15 criminals then elbow their way in while the door is open. Who needs such garbage on the Internet?

AJA?

[roman_mir]

Before there was a word AJAX, there was a way to do the same thing, and I had to do it too: hidden frames + javascript. It wasn't XML though.

Just last Friday I had to use AJAX but without XML at work. Instead of XML, it is much easier to just do this:

[["key1","value1"],["key2","value2"],["key3","valu e3"],["key4","value4"]] - send this string as response and then in your javascript simply eval it. It will become a 2 dimensional array. If you want, you can unroll the array into a hashmap:

var arr = eval(strin);
var map=new Array(arr.length);
for(var i=0;i<arr.length;i++) {
  map[arr[i][0]]=arr[i][1];
}

now you can access values in the map by the associated keys:

map["key4"] == "value4"

Re:AJA?

[lcracker]

That's called JSON.

Cross domain issues

[kadnan]

One thing is noticeable that AJAX is useless if you try to fetch data from other domain,most probably you would get permission denied error. Alex of ajaxextended.com has written an awesome library which deals with this issue,and since he is not using builtin xmlhttp object,therefore you don`t need to create seprate instances for IE and Firefox.i have tried to create an AJAX based feedback form for my blog and it can be used on any website with zero installation,even on sites like geocities,one can experience it http://kadnan.blogspot.com/,by clicking CONTACT ME option,details are given at http://kadnan.blogspot.com/2006/01/customized-ajax -based-contact-form-for.html

Re:No Thanks to AJAX Developer's Journal

[Anonymous Coward]

Quoting a sentence out of a paragraph can do wonders, isn't it?

How do you describe a reporter knocking on your door, introducing herself or himself as a reporter and asking for an interview as harassment? Print and radio and TV journalists do it all the time. Why shouldn't online journalists be allowed to do this? You have a choice to grant or decline an interview. What does ethics have anything to do with professional reporting and journalism? What is "unethical" is to report the facts knowingly wrong. That's not professional journalism. It might be called irresponsible blogging. From what I read and decided (I checked the facts myself), there was nothing wrong with the story as long as it reported the facts.

Better wrapping, same voodoo code

[metalpet]

Exactly what version of MSIE would reject "Microsoft.XMLHTTP"?
Would those versions have any hope of understanding any of the "MSXML2.*" names?

I keep seeing the same voodoo everywhere ajax is found, and conscientious voodoo priests like the author of the code in parent post make a point to list not 2, but 5 possible names.

In my testing, it seems every version of MS' XMLHttpRequest object is linked to the "Microsoft.XMLHTTP" name, so there's no reason to ever want something more complicated than this:

if( typeof window.XMLHttpRequest == "undefined" ) {
        window.XMLHttpRequest = function() {
                        try {
                                return new ActiveXObject( "Microsoft.XMLHTTP" );
                        } catch( e ) {}
                }

                return undefined;
        }
}

It's not like anyone uses any new functionality that weren't present in the older versions.

Anyone managed to use POST rather than GET?

[Anonymous Coward]

I've been trying to get XMLHTTPRequest via POST happening for the last hour or so with no luck. Anyone have any guides or examples?

ActiveX - you must be joking

[sonofdelphi]

I am not an AJAX expert or anything but...
ActiveX...cross-platform?

Firefox does not support ActiveX objects by default, right?

Re:ActiveX - you must be joking

[init100]

You are partially correct. ActiveX is not cross-platform, but the three top statements in the function all do the same thing, in different browsers. The top two statements are for different versions of Internet Explorer, and the third one is for all AJAX-compatible non-Microsoft browsers (Firefox, Opera, Safari, etc). In other words, they are mutually exclusive.

Re:No Thanks to AJAX Developer's Journal

[Isofarro]

Yet another one of Sys-Con's online publications people should avoid for various reasons.

Hmmm, thanks for the reminder. They are the ones that did the hatchet job on Pamela Jones of GrokLaw. I actually was scanning through the website above looking for a subscription to this "Ajax developer" this morning, couldn't find it (saw a reference to an AJAX article written by Maureen O'Gara - name was familiar, but I didn't remember why).

I was going to try again later. I guess not now. Thanks.

Tool and library names

[sjames]

This is a bit off topic, but what's the deal with tool and library names lately. At one time we had simple descriptive names for standard libraries like libm or "the math library".

If the current trends had been in place when C was invented, instead of using libc and libm, we'd be using C with "C boogleblargle 1.2.5.3a now with the Quintrix (tm)" (that is, printf in it's own library), "C wallawalla FileStreams 7.3.5.4" (stdio minus printf in it's own library), "C credenza plus plus plus 12.9.3.4" (that would be strcat), and the all important godlike (said in hushed tones) "C FroBozz 1.4.75.9A" (AKA the fabs() function that doesn't mysteriously throw an exception if you do fabs(0.0) ). These would come to be abreviated as BB with Quintrix, Cc+plus+, and CFB1.4.75.9A Failure to pronounce the bolded A would be a heresy of course. God forbid we forget to mention the Quintrix even on the 5th reference in the same paragraph.

Perhaps I exagerate a little.