AJAX is a term coined for Asynchronous Java Script And Xml Language, a way of enriching a web application by putting more behavior in the browser through a combination of the following technologies:
standards-based presentation using XHTML and CSS;
dynamic display and interaction using the Document Object Model;
data interchange and manipulation using XML and XSLT;
asynchronous data retrieval using Xml Http Request;
and Java Script binding everything together.
It is the result of realizing that Thin Client Has Failed. Quoting from "Ajax: A New Approach to Web Applications", February 18, 2005 by Jesse James Garrett (the guy who coined the term "AJAX") at www.adaptivepath.com 
:
"Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year -- Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps -- are Ajax applications.
"(For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.
jgwebber.blogspot.com (Broken Link 2005-09-20)
"Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon's A9.com search engine applies similar techniques."
Basically, what "Ajax" means is "Javascript now works." -- Paul Graham, www.paulgraham.com
Google is using this approach heavily, in their Gmail service and Google Maps, to give examples. However, the AJAX approach can lead to difficulties in Accessible Web Page Design (www.standards-schmandards.com and www.accessifyforum.com ).
It's also being used/discussed heavily by the Ruby On Rails community.
Ajax makes RoR directly competitive with traditional enterprise desktop tools, such as Visual Basic, Dot Net, or Enterprise Java Beans. In 1/5th the source code, 1/2 the development time, and 1/20th the deployment effort. Your Knowledge Workers request features, managers bubble User Stories up to your Onsite Customer, and the feature appears in everyones browsers, in a day or two. RoR makes Ajax Event Handlers easier to code than traditional GET and POST event handlers.
AJAX and Test Driven Development
To test at the unit level - hence to write proactive test cases - do not focus on the final result in a web browser. Treat the unit as a generator of long strings of XHTML and Java Script, and test that it has generated the correct strings. This requires parsing that XHTML and Java Script . See Test Driven Ajax for a survey of these techniques.
They create new problems (see Gui Testing and Web Testing). In particular the server side of AJAX is easy to test drive; the browser side... not so much. You also run into some unique problems related to Java Script.
Why? I've happily been using tools like Test Simple and other Java Script based testing frameworks to test client side scripts?
I've only tried one package, JSUnit, and found it to be of very limited utility for client-side testing. Specifically, it breaks Venkman, the only client-side Java Script debugger that works.
Will the nature of MS ruin AJAX intentionally or unintentionally?
The Microsoft way of implementing AJAX is different from other browsers'.
You really mean, the other browsers way of implementing AJAX is different from Microsoft, who invented it.'
Perhaps he or she really means that the Microsoft way of implementing Java Script support doesn't follow the basic architecture implied by the language -- such as, for example, a normal Java Script class for each DOM object (where "normal" means "has well-behaved prototype and constructor objects"). Or perhaps he or she really means that the Microsoft way of implementing AJAX precludes running any sort of Venkman-like debugger that works.
How not surprising. When scripting Internet Explorer 6, instead of creating an Xml Http Request object directly you must create an ActiveX object to implement the HTTP request (and the user must have ActiveX enabled). Thus, an AJAX app for both Microsoft and non-Microsoft users needs browser detection code. Yuck.
The requirement to enable ActiveX is the most objectionable aspect of this.
I wonder if Microsoft will cooperate with Ajax. Ajax is a risk to its desktop control. If apps can run as web-apps, then there is less need for desktop apps and bean-counters will start to think about not paying the "Microsoft Tax". They thus have an interest in throwing monkey wrenches into Ajax via browser bugs (not fixing or adding), patent suits, etc.
{When I look at raw AJAX code, I see a lot of IF statements based on different browser versions, resembling:}
function AjaxDrawFoo(...) { ... if (ie6) { // code for IE version 6 } elseif (ie7) { // code for IE version 7 } elseif (opera5) ...
{The AJAX interface tries to hide version issues, but man does the implementation code look ugly and future-version risk prone. This is one reason why I suggest a new dedicated GUI/CRUD browser be created based on a new GUI markup language. The HTML-based browser family is being stretched way too far. -t}
[What do you expect to accomplish by suggesting such things? If you want to have any impact at all, you need to implement it yourself. By the way, good AJAX frameworks isolate and abstract out platform (browser) dependencies. Bad ones don't. This is true of everything intended to be multi-platform, not just browsers and their languages.]
But with this approach it's difficult to get it right. The Ajax approach is poor network and client/server factoring, almost like every app re-downloading its own operating system on each session. It's a silly state of affairs. If you beat a dead horse with a big enough club, it will move, but only because the club was so large.
[There are bloated frameworks for everything. Avoid them. I created a simple AJAX Java Script "framework" (tongue firmly in cheek) -- nothing more than a handful of functions -- that does everything I need. I've used it successfully on a number of projects. You can have it. It's at dbappbuilder.sourceforge.net and it's used by dbappbuilder.sourceforge.net But, that's hardly the point. The point is: How do you expect to accomplish anything with suggestions and complaints? Again: If you want to have any impact at all, you need to implement it yourself. Code rocks, talk walks.]
I meant the GUI framework, not just the communication framework. To nearly match the power and behavior of desktop GUI's, it will probably need roughly 100k lines of code. As far as "complaining", if enough people realize we are all doing it the stupid way, then somebody skilled at lower-level GUI engine API's and C++ may start something. I'm not a C++ whiz and don't wish to start. Many people seem to just be accepting the goofy HTML++ stacks as the way to go.
[You presume matching the "power" (?) and behaviour of desktop GUIs is desirable. One of the reasons (obviously not the only one) for the popularity of Web-based applications is because they are not like desktop GUIs. Some aspects of desktop GUIs, such as only updating portions of a page or screen, are obviously desirable -- hence AJAX. Others are not, such as the complexity, non-intuitiveness, and steep learning curve frequently encountered by desktop application users.]
As one who has developed both kinds, I find that managers and customers keep wanting desktop-like features in intranet web UI's. And desktop idioms offer more design options. Web is more constrained. True, there are badly-designed desktop apps, but that's true of any tool.
[Yes, managers and customers occasionally request desktop-like features in intranet Web UI's. Sometimes these features are a good idea, and I implement them with Javascript I've downloaded or written. Many times, these features are a bad idea. When I see bad ideas, I show the managers and customers a better idea. Many times they like it. Sometimes they don't. When they don't, I implement their ideas with Javascript I've downloaded or written. But most of the time, managers and customers don't care how you solve a problem. It doesn't matter whether it has a desktop-like interface or a Web-like interface. The users are used to both. All they care about is whether it solves the problem or not.]
It's often difficult, buggy, and version-sensitive to get Java Script-based widgets to work right. They tend to break on the next browser version release. I test them based on how *I* move the mouse or keys, but find out somebody does it different or has a browser setting that breaks them. I'm tired of reinventing GUI idioms that have been around for 15+ years. I want to implement business solutions, not write mouse timers.
A completely uninformed developer tries to look cool with an anti-Microsoft bash. "How not surprising." Hate to break this news to you, but Xml Http Request originated in IE5 which came out how long ago? 1998? It was Mozilla that decided to make it a native Java Script class when they finally realized the potential of the class about a year ago. So, let's not re-write history, eh? Maybe some day when browsers are implementing a real standard like Dom Level Three Load And Save we can argue about who's following the spec, but for now all we have is a Defacto Standard with Xml Http Request.
Anyway, in any good AJAX framework, the creation of Xml Http Request objects is usually done via a Factory Method to abstract you from the actual browser specific instantiation of the class. So this whole discussion is pretty much pointless unless you're just out to bash MS.
I beg to disagree. This whole discussion is very much relevant to ANY developer attempting to get Ajax Web Applications working. Did Microsoft invent Xml Http Request? Yes. Kudos to them. The rest of the community has demonstrated how to take advantage of this advance without drinking the rest of the Microsoft koolade, to Microsoft's chagrin. Even a stuck clock tells the correct time twice a day.
{Not necessarily, MS's clock has 13 hours.}
I agree. New ideas can and do originate because of or related to MS technology. However, as soon as such things become a visible threat to MS, then it will move to "correct" the situation. You can create a zit on MS without fear; but if you infect a whole limb, you risk becoming the next Netscape. MS is historically a control-freak.
[MS certainly is shamelessly self-interested, but if you want 'control freak' look to Apple (who historically controls all hardware and much software, and who has recently - 2010 April 8 - banned use of third party languages for iPhone/iPad apps). Anyhow, MS is so big that often the right pseudopod knoweth not what the left pseudopod is doing. I imagine it is quite difficult to manage.]
Internet Explorer aspects
September 14, 2005: "AJAX developers, rejoice! Microsoft has officially announced that XMLHttpRequest will be a native object in IE7, meaning it will work even when ActiveX support has been disabled in the browser for security reasons. This brings the browser's support for remote scripting--the technology at the heart of AJAX applications--up to the same standard as that offered by Firefox, Safari, Opera, and similar browsers." (www.sitepoint.com ) Good news, but you'll still need the additional ActiveX code for some years if you want to support IE6 users. (And you'll still need additional code if the event model in IE7 is still different from that of non-Microsoft browsers.)
Or you can just ignore those other browsers and code for IE6. The number of people without access to IE6 is tiny.
I think you're missing the point. AJAX code for IE7 will be not be the same as it is for IE6. AJAX code for IE7 will match that of Mozilla Firefox, Safari Browser, etc. (though I'm not sure about IE7's event model). It's IE6 that's the oddball. Get ready to not code for IE6.
I thought they were just adding native Xml Http Request to IE7. I seriously doubt they'll remove the "Microsoft.XMLHTTP" ActiveX control from IE7, and I can't find anything on the web that suggests they will. Read www.thecounter.com and tell me IE6 is an "oddball".
The number of people who use IE6 is immaterial to my point. 1) IE is the only browser for which you need to code an ActiveX control to specify an HTTP Request. 2) IE6 (or IE5+ ?) is the only modern browser that uses its particular Event model. 3) And IE6 (IE4+ ?) is the only modern browser with its particular notion of the Cascading Style Sheets box model. If you code your Java Script & CSS for Mozilla, you're coding for several different modern browsers. But if you code for IE6, the results turn out as expected only in IE6. Therefore, I say IE6 is the oddball.
Those "several different modern browsers" together make only a small fragment of the audience. Calling the dominant browser "oddball" doesn't seem very realistic. Plus, Xml Http Request was a Microsoft invention in the first place. Their way is the "correct" way by definition.
It will be more realistic when IE7 is released to the public and web developers become accustomed to developing for it. IE7 will discourage the use of ActiveX for Xml Http Request. IE7 will, I think, allow you to set CSS3 attributes for the box model you want. And if we're really lucky, IE7 will use Mozilla's event model. Then IE6 will seem as odd as Netscape Navigator 4 does today.
I predict IE7 will be backwards compatible with IE6 and most web developers won't become accustomed to much of anything.
Sad but probably true. Web developers still check for document.all, which is left over from IE4.
Try not to let it get you down. De facto standards are a Good Thing.
There is a reference for AJAX sans Activex in Ajax Client Engine Discussion
please continue explorations in that page if possible, and let us know the opporunities and limitations presented in that scenario.
Atlas is the code name for the new MS technology that will allow further evolution of Asp Dot Net to develop Ajax Web Applications. And a beta for a toolkit is expected in later 2005.
Other ways
Zap Think mentioned another big stream of development for Rich Internet Application is in the use of Macromedia Flash.
If you use Php Language and do not need to do POST, then remote scripting as characterized by Ajax Web Applications do not need to use Xml Http Request. This leads to other possibilities being opened such as allowing AJAX calls to other pages and domains. Another benefit is Internet Explorer 6 can be used without an ActiveX (but browser security cannot be set to high). See a Nov05 tutorial at www.phpit.net
Ajax limitations and concerns
Does not work if Java Script is not enabled (10% of internet users)
There were 10 mistakes/problems/limitations related to Ajax, as listed at sourcelabs.com
The items have been reworded as:
Visual clues problems
Broken back button (Some question Back wisdom anyhow - Back Is Not Undo)
State change assumption with link clicks
Async changes that are unexpected
Cannot share URL info with other users
Less responsive browser weighed down by code
New and unfamiliar UI for web applications
Localized changes with global impact
problematic "batch" operations in a form
Async changes can affect scrolling
Missing some widgets such as editable, scrollable grids
Since the above was published, there have been substantial community interest, and an expanded/revised (editable) list is located at swik.net
I have find my favorite entry in a "quick glance". With Ajax, it becomes very difficult for the support person to know what exactly has happened to a distressed user. Server information is insufficient to tell what the Ajax engine has done (with users help).
A "crashed client" is always a potential problem with any kind of remote interface. Some kind of refresh mechanism perhaps should be built into the framework.
What works in browser version N may not work in version N+1 because Ajax relies on some obscure features (obscure meaning outside of "primary" usage such that it's not tested well or bugs related to it ignored).
Degradable Ajax web design
An article on making web functionality available for users, independent of their browser settings.
http://particletree.com/features/the-hows-and-whys-of-degradable-ajax/
Anyone interested to summarize and share some views on the advice given?
I did not get a response here quickly. But found something which is relevant to a response. See encytemedia.com
Blogs, Books, Tutorials, Wikis
www.ajaxian.com - the premiere Ajax news blog co-edited by Dion Almaer, Ben Galbraith, and Rob Sanheim
www.ajaxinfo.com (libraries, online community)
ajaxpatterns.org (will become Ajax Design Patterns from Oreilly And Associates)
www.onlamp.com (Ajax on Rails)
www.pragmaticprogrammer.com (PDF beta book from Pragmatic Programmer folks)
www.sitepoint.com (tutorial)
I'd love to see this Wiki develop some direction around Ajax Web Applications and Mashups. This is a revolution, and it plays to the historical strengths of the technology and community of this wiki, including at least some of the regulars here (including Ward Cunningham). I note, for example, blogs.zdnet.com [dead link removed].
Personally I think that would destroy this wiki, Mash Up is just a buzzword for a bunch of content stolen from other websites and mixed into completely unrecognizable pieces so that you can make more money from your Adsense clicks.
I think most people would disagree; I certainly do. Mashups do what real applications do: they hook services together in useful ways to create new services that have a gestalt value greater than the sum of their parts. Check out Qed Wiki. Anyhow, I seriously doubt this wiki will ever be turned into a Mashup Maker. Qed Wiki, or any good Wiki Ide that allows constructed services to run on the Wiki itself, however, would be a fantastic Mashup Maker.
www.zeroplayer.com
Ajax has been around what 7 years now? and is still unreliable jittery crap. Time for the "Web GUI overhaul" I keep ranting about (Limits Of Html Stack). HTML5 is supposed to be the new savior, but it targets "web toys" more than business GUI's. (Oct. 2010) --top
Sorry, top, but gotta disagree Yet Again. Ajax is useful in building browser-agnostic web applications right this very minute, and I know that for a fact. You see, I am doing it even as we "speak." Without Ajax I'd be hosed.
I've yet to see it reliable. When you can control what's installed on your test machine, sure, you can make it work "good enough". But the real world is more varied. Java applets are still the choice for "enterprise" http-based fat-clients. And if/when it gets good enough to challenge the desktop, MS will yank the carpet from under it using techniques such as those found in Limits Of Html Stack. They are not going to go quietly into the night.
Top, AJAX is reliable. It works. Google has built a gaggle of AJAX apps that run reliably on the majority of browsers. See, for example, maps.google.com . I'm starting to see AJAX-based internal business apps, and they're looking good.
Google apps suck as far as reliability, integrity, and compatibility despite a mountain of resources Google has to throw at them, unlike a small and medium companies. People use them because they are free, not because they are good. Maybe it will change, but I still see too much suckage. And "internal business apps" may be able to get away with it because their desktop platforms can be controlled somewhat, such as browser versions. Plus, do-able and "easy to do" are not the same thing.
Amazing. Top, I think you live in a world of your own.
Native desktop apps spoiled me, I guess. Maybe the newer generation tolerates UI suckage more? I don't dispute that Html Stack apps can be made decent with enough blood, sweat, tears, and cussing. But on the good side, sucky technologies generate IT jobs.
As a test case, see if one can build something similar to desk-top Visual Basic with it. This is not necessarily endorsing VB as a grand developer tool, only using it as a capability test.
Like shiftedit.net , coderun.com , or Eclipse E4? It's straightforward. Anything you can do on the desktop you can do in a browser, because current browsers give you everything you'd get, presentation-wise, from a typical desktop-based operating system.
I am thinking more about the GUI building capabilities, not code editing.
Ah. See www.sigmawidgets.com
Interesting. I couldn't get the grid widget to work right, though (although perhaps I have been "doing it wrong" somehow). And one would have to use it for a real project or two and see how it works on different browsers and versions to judge quality. I've seen demos of similar things 10 years ago, but they never took off. And, they couldn't get the data-edit-grid right either.
I tried the TreeGrid (I think it was) and it worked well.
I cannot see your desktop. Anyhow, perhaps we are coming at this from different angles. Your shop may have a dedicated AJAX/Java Script developer who can specialize and concentrate on AJAX and GUI tweaking. I'm in a smaller sub-shop where we wear multiple hats and don't have the time to perfect just AJAX skills. We can't specialize and need GUI's to be relatively easy to get working without fuss and muss because we have business logic, databases, server babysitting, app help-desk and other technical factors to contend with. One could argue this is not a good organizational structure, but that's beyond my control. Many organizations choose to organize that way and look for ways to make such work smoother.
See: Rich Internet Application, Kiss Web Services, Ajax Client Engine Discussion, Remote Gui Protocols, Web Two Point Oh, and maybe Browser Abuse Syndrome
See original on c2.com