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:

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.


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.'

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.

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.)

There is a reference for AJAX sans Activex in AjaxClientEngineDiscussion 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:

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

Degradable Ajax web design

An article on making web functionality available for users, independent of their browser settings.

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

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


EditText of this page (last edited November 22, 2011) or FindPage with title or text search