Ajax Web Applications

AJAX is a term coined for Asynchronous JavaScript And XmlLanguage, 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 DocumentObjectModel;
data interchange and manipulation using XML and XSLT;
asynchronous data retrieval using XmlHttpRequest;
and JavaScript binding everything together.

It is the result of realizing that ThinClientHasFailed. Quoting from "Ajax: A New Approach to Web Applications", February 18, 2005 by Jesse James Garrett (the guy who coined the term "AJAX") at http://www.adaptivepath.com/publications/essays/archives/000385.php :

: "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.

: "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." -- PaulGraham, http://www.paulgraham.com/web20.html

Google is using this approach heavily, in their Gmail service and GoogleMaps, to give examples. However, the AJAX approach can lead to difficulties in AccessibleWebPageDesign (http://www.standards-schmandards.com/index.php?2005/03/01/16-ajax-and-accessibility and http://www.accessifyforum.com/viewtopic.php?t=2660).

It's also being used/discussed heavily by the RubyOnRails community.

Ajax makes RoR directly competitive with traditional enterprise desktop tools, such as VisualBasic, DotNet, or EnterpriseJavaBeans. In 1/5th the source code, 1/2 the development time, and 1/20th the deployment effort. Your KnowledgeWorkers request features, managers bubble UserStories up to your OnsiteCustomer, and the feature appears in everyones browsers, in a day or two. RoR makes Ajax EventHandlers easier to code than traditional GET and POST event handlers.

AJAX and TestDrivenDevelopment

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 JavaScript, and test that it has generated the correct strings. This requires parsing that XHTML and JavaScript . See TestDrivenAjax for a survey of these techniques.

They create new problems (see GuiTesting and WebTesting). 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 JavaScript.

Why? I've happily been using tools like TestSimple and other JavaScript 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 JavaScript debugger that works.

MicrosoftWay

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 JavaScript support doesn't follow the basic architecture implied by the language -- such as, for example, a normal JavaScript 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 InternetExplorer 6, instead of creating an XmlHttpRequest 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 JavaScript "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 http://dbappbuilder.sourceforge.net/ajax.js and it's used by http://dbappbuilder.sourceforge.net/Rel.php 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 JavaScript-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 XmlHttpRequest originated in IE5 which came out how long ago? 1998? It was Mozilla that decided to make it a native JavaScript 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 DomLevelThreeLoadAndSave? we can argue about who's following the spec, but for now all we have is a DefactoStandard? with XmlHttpRequest.

Anyway, in any good AJAX framework, the creation of XmlHttpRequest objects is usually done via a FactoryMethod 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 AjaxWebApplications working. Did Microsoft invent XmlHttpRequest? 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.]

InternetExplorer 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." (http://www.sitepoint.com/blogs/2005/09/14/xmlhttp-to-go-native-and-other-ie7-goodness/) 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 MozillaFirefox, SafariBrowser, 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 XmlHttpRequest 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 http://www.thecounter.com/stats/2005/September/browser.php 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 CascadingStyleSheets box model. If you code your JavaScript & 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, XmlHttpRequest 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 XmlHttpRequest. 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 NetscapeNavigator 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 GoodThing.

There is a reference for AJAX sans Activex in AjaxClientEngineDiscussion

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 AspDotNet to develop AjaxWebApplications. And a beta for a toolkit is expected in later 2005.

Other ways

ZapThink? mentioned another big stream of development for RichInternetApplication is in the use of MacromediaFlash.

If you use PhpLanguage and do not need to do POST, then remote scripting as characterized by AjaxWebApplications do not need to use XmlHttpRequest. This leads to other possibilities being opened such as allowing AJAX calls to other pages and domains. Another benefit is InternetExplorer 6 can be used without an ActiveX (but browser security cannot be set to high). See a Nov05 tutorial at http://www.phpit.net/article/ajax-php-without-xmlhttprequest/

Ajax limitations and concerns

Does not work if JavaScript is not enabled (10% of internet users)

There were 10 mistakes/problems/limitations related to Ajax, as listed at http://sourcelabs.com/ajb/archives/2005/05/ajax_mistakes.html The items have been reworded as:

Visual clues problems
Broken back button (Some question Back wisdom anyhow - BackIsNotUndo)
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 http://swik.net/Ajax/Ajax+Mistakes

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 http://encytemedia.com/blog/articles/2005/10/13/dispelling-the-myths-of-javascript-degredation

Blogs, Books, Tutorials, Wikis

http://www.ajaxian.com/ - the premiere Ajax news blog co-edited by DionAlmaer, BenGalbraith?, and RobSanheim
http://www.ajaxinfo.com/ (libraries, online community)
http://ajaxblog.com/
http://ajaxpatterns.org/ (will become Ajax Design Patterns from OreillyAndAssociates)
http://codinginparadise.org/
http://developer.apple.com/internet/webcontent/xmlhttpreq.html
http://developer.mozilla.org/en/docs/AJAX
http://www.onlamp.com/pub/a/onlamp/2005/06/09/rails_ajax.html (Ajax on Rails)
http://www.pragmaticprogrammer.com/titles/ajax/ (PDF beta book from PragmaticProgrammer folks)
http://www.sitepoint.com/article/remote-scripting-ajax (tutorial)

I'd love to see this Wiki develop some direction around AjaxWebApplications 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 WardCunningham). I note, for example, http://blogs.zdnet.com/BTL/?p=2612 [dead link removed].

Personally I think that would destroy this wiki, MashUp 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 QedWiki. Anyhow, I seriously doubt this wiki will ever be turned into a MashupMaker. QedWiki, or any good WikiIde that allows constructed services to run on the Wiki itself, however, would be a fantastic MashupMaker.

Ajax has been around what 7 years now? and is still unreliable jittery crap. Time for the "Web GUI overhaul" I keep ranting about (LimitsOfHtmlStack). 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 LimitsOfHtmlStack. 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, http://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 HtmlStack 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 VisualBasic with it. This is not necessarily endorsing VB as a grand developer tool, only using it as a capability test.

Like http://shiftedit.net, http://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 http://www.sigmawidgets.com/products/sigma_visual/VisualJS/UIBuilder.html

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/JavaScript 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: RichInternetApplication, KissWebServices, AjaxClientEngineDiscussion, RemoteGuiProtocols, WebTwoPointOh, and maybe BrowserAbuseSyndrome

CategoryXml, CategoryJavaScript, CategoryWebDesign

NovemberEleven