Jesse James Garrett  

Why Ajax Matters Now

September 16th, 2005 by Jesse James Garrett :: see related comic

In the earliest days of the Web, designers chafed against the constraints of the medium. The entire interaction model of the Web was rooted in its heritage as a hypertext system: click the link, request the document, wait for the server to respond. Any designer who asked if the basic call-and-response interaction model of the Web could be defied was met with the flat answer “No.”

Eventually, with the evolution of browser technology, that “No” became a “Yes, if…” Yes, if the user has the right browser and the right operating system. Yes, if the user’s connection is fast enough. Yes, if the user has the right plug-in or the right runtime.

For some designers working in some environments, “Yes, if…” was good enough. But for the overwhelming majority of designers, the caveats and restrictions were simply too great. So they returned to the task of making the Web work the best it could within the hypertext interaction model, developing new conventions for Web interaction that allowed their applications to reach audiences who never would have attempted to use desktop applications designed for the same tasks.

The rise of Ajax represents the new and widening recognition that the days of “Yes, if…” are numbered. It’s analogous to the realization we had a couple of years ago, when it became apparent that maturing browser support for CSS and XHTML would finally allow designers the flexibility and ease of maintenance the Web had always promised but never quite delivered. In both cases, the technologies aren’t new; what’s new is our ability to make the most of them on the broadest possible scale.

Proprietary solutions are never as compelling for Web designers as open standards are. Web designers are passionate about the Web as a medium, and that medium doesn’t belong to any technology provider.
It’s something that all of us, working together, are helping to build. For many Web designers and developers, crafting a new medium is what attracted them to the Web, and what keeps them engaged with the Web regardless of the ebb and flow of stock markets. Technologies that don’t work on a Web-wide scale are, by definition, not participants in this process.

What’s the difference between Oddpost and Gmail? One followed desktop interaction conventions, required a particular browser and a particular operating system, and gained a cult following. The other came along four years later, followed Web interaction conventions, worked across all modern browsers — and transformed its entire category. Some might argue that Oddpost is the more sophisticated solution. But Gmail is part of the larger Web in a way that Oddpost never could have been.

Gmail demonstrated to the entire industry that we don’t have to compromise anymore. Sure, there are still plenty of challenges, both for designers and for technologists, in creating Ajax applications that really work effectively for users. But the new wave of Ajax applications reflects the industry’s newfound (and still increasing) sophistication. We’re smarter about the Web than we were before, and that alone opens up new possibilities for interaction designers.
Those possibilities, and the unexplored ways we can evolve Web conventions without the constraints of the old hypertext interaction model, are why the recent Ajax explosion signals a new chapter in the history of Web design.

_Jesse James Garrett is the Director of User Experience Strategy and a founder of Adaptive Path. He is the author of the widely-referenced book The Elements of User Experience._

99 Responses to “Why Ajax Matters Now”
Paul Brown wrote:

Maybe I’ve had my head in the sand for the last few years, but I openly confess that this is the first time that I’ve encountered the name “Ajax”. The principles behind it, however, are familiar and I have used them before, but not usually with JavaScript. The main problem as I see it is if you’re not sending and recieving pages to and from the server then the whole Back / Forwards / History architecture becomes lost.

That in itself isn’t necessarily a crisis, but I prefer that the user has some indication that this will happen, so I’ve always performed asynchronous web applications using visible applets, so that the user is (hopefully) aware that the “page” they are on isn’t changing, only the applet that they are using within it. The Ajax approach is slightly reminiscent of a self updating frameset where the required parts of the page are updated, but the rest is still usable in the meantime and I’m sure that few people will fight that particular corner.

As I have already confessed I am not familiar with Ajax, so perhaps I am missing the point, but I have to ask, Jesse:

1. Why JavaScript? The lack of decent IDE’s and slower running are not a problem for simple things, but surely a fully fledged application is easier to develop in Java?

2. Doesn’t Ajax break the navigation model that, whilst flawed and far from perfect, at least pretty much everyone understands?

Ok, then, everyone. I’ve got my fire-proof underwear on ready. Start shooting.

Michalis Kamburelis wrote:

Paul, wikipedia has a nice article with many links about Ajax: [].

My personal opinion about Ajax is along the lines of the Dawn’s (well, I’m a developer after all :) : this *is* a nice technique, but it’s a little difficult to admit it, because tools for this technique more-or-less already existed since a long time.

The problems with Ajax are the same as problems with frames/iframes and JavaScript: broken back/forward button, inability to bookmark an exact state of a page, not searchable by google. But now, that this technology is somewhat more recognized, I guess that we can create tools (and eventually new protocol standards) to overcome these problems.

Marian Steinbach wrote:

As an interaction designer, I agree with Jesse, AJAX is opening up a great box of new interaction possibilities. To me, Flickr is another great example where AJAX simplifies intraction (as it doesn’t take the user out of his current context) and improves the flow.

However, I would love to see results from user testing on this. Are users ready for stuff like that? This week’s OK/C comic takes a rather critical positioin towards AJAX. The question is: Who has actual data that supports any opinion pro/contra AJAX web UIs?

Paul Brown wrote:

Thanks for the link, Michalis, and thanks for proving my expectations wrong. I was fully expeting a tirade of angry developers heaping coals on me for being so stupid as to question the latest “big thing”. I’m glad to have been wrong.

Josh Seiden wrote:

If your arm is broken and the doctor gives you a cast, you may grow to like the drawings and doogles your friends make on the cast. You may even appreciate your ability to wack your little brother in the head with your new body-club. But I bet you’re happy when the cast comes off.

The page is dead? Good riddance.

This does mean is that web designers will need to learn a new way of thinking. State transition, which was primitive on the page-based web, has now gotten more complex. State recovery, which was handled with back buttons and bookmarks, must now be managed in a more mature way–must be baked in to the structure of your application, rather than supplied from without. But if the application design is done well, users will not miss the *back button*, of all things.

Reed H wrote:

Javascript is the only way to screw around with the contents of the page (as a DOM built from HTML).

Flash is good too, (Flickr for example) but then your dynamic stuff is stuck in a little box and none of the text/brower/OS tools are available in that box. To some extent, same with Java. Java is, unfortunately, in practice awkward and slow when loading, and on many browsers, broken.

Reed H wrote:

Michalis, I also agree. But I’m an applications developer also :) I see AJAX as too constrained and limited, and still has to work around and fight against the fundamental document-request web architecture (HTTP).

I say, develop a new protocol and write new software. (So some of us did, see: http//
Of course, if you’re trying to actually deploy something *tomorrow* that needs these capabilities, accessible by everyone *tomorrow*, that approach is not realistic. But I think we need to do it for the future.

Jason wrote:

There are reasonably well-implemented methods of creating Ajax apps that don’t break the back/forward button or the history of a browser; a few of them are mentioned in that Wikipedia article, and a few of the toolkits out there (Dojo springs to mind) help implement the techniques. That being said, I’m also anxious for the day that browsers implement more intelligent back/forward buttons (perhaps by allowing apps to provide events tied into them on specific web pages).

sloan wrote:

I think some of the questions here point to the wider issue… you can only control the page and not really the browser. I think the browser itself needs to become more open. We have to duplicate menus, navigation buttons… basically everything IN the browser itself for our own pages. It is incredibly inefficient. But we don’t want one site developer to make the browser an unidentifiable thing… so what’s the compromise?

Robby Slaughter wrote:

The “If…” is still here. “If you’re willing to break the fundamental page model of the web and rely upon a staggering amorphous pile of poorly connected, semi-reliable technologies, you can get a few fancy interaction elements”. AJAX is *not* a technology. It’s a colossal hack.

That doesn’t mean you can’t make use of it now to edge out your competitors (and I’m reluctantly available for hire to help you do so), but ugly hacks call for refactoring, not for use. The web is long overdue for an overhaul.

XUL and XAML are much more interesting approaches to this problem. What’s wrong with doing things the right way?

Michalis Kamburelis wrote:

XUL and XAML are fine for me. Well, actually, XUL is great because it’s from open source and XAML sucks because it’s marketed by M$. But, basically, they are technologically OK.

However, they also have the *same* problems as Ajax, and as any frames/iframes + JavaScript approach: broken back/forward button, inability to bookmark etc. So they are not better than Ajax, if you want to stay within “web fundamental page model”.

They are more powerfult than Ajax, that’s a sure thing. But the problem is that XUL and XAML are even less available than JavaScript. As long as modern web browsers are concerned, right now JavaScript is not such big compatibility hell, compared to XUL to XAML:

XUL is only for Mozilla and derivatives. I surely use them (currently this means Firefox and Epiphany). But I would like to support also other browsers. Even if I would not care about poor IE lusers (but I have to care about them, because they are so numerous), there are still other browsers like Konqueror. And they don’t support XUL at all.

XAML is (will be ?) only available for M$ crap, so this is obviously also not a compatible solution.

Summing my point: Well, I agree with you, possibility to use XUL instead of Ajax hacks would be great. But, as the current state of browsers is concerned, using Ajax (= yes, JavaScript + iframes hacks) is right now more reliable, i.e. supported by more browsers.

Robby Slaughter wrote:

The grand plan is clearly to merge the web and desktop experience. Microsoft’s plan is via WPF (Windows Presentation Foundation), which they will allow to run “everywhere” with WPF/E. XUL is comparable, but not nearly as ambitious.

The XAML implementation will *not* be a JavaScript/iFrames hack. It will be WPF (Windows Presentation Foundation), running fluidly in a client-side application in .NET. This doesn’t mean you can’t create server-based applications that “live” in the browser. In the case of IE, XAML will run inside an ActiveX control. Microsoft has promised that this will be extended to “other platforms”, and even demonstrated a WPF->XAML app running in Safari on Mac at PDC 2005.

FYI, There are open source efforts to build XAML-interpreting engines, most notably

Saravanan wrote:

Some are told as SAJAX, XAJAX and so many which one standard? or explain the differece between the above things?

Where i get sample / example scripts?

Robby Slaughter wrote:

AJAX is not a technology. It’s an umbrella term for a suite of techinques for creating web interfaces that are “richer” than just plain-old links and forms.

Strictly speaking, using a mouseover image to create a menu option is AJAX (due to the *J*avaScript involved), but there are more impressive efforts like Google Suggest (

Search the web for “AJAX” for more information, code samples, etc.

Michael A. wrote:

This is a very useful post. Thank you so much. Regarding the comments, well thank you too. Most of them confirm what many non developers (term used by one person was “lusers”-they apparently forgot who actually owns the Web. No one and everyone. However, “Visitors” (i dislike the term “Users” to describe a human being) are certainly the ones in charge.

Why do so many Web designers, back end developers, usability professionals, etc., seem to have such a need to “own” the Web, as if there weren’t a much more significant aspect to this relatively new phenomena? It’s called “context” or “the big picture” and technology is as important as all the other parts of the process of creating a rapidly evolving set of tools that are not is service to themselves, they are a response to human need-some of it very pressing in nature.

Instead of throwing insults at me (I am too use to it to be an effective strategy), try tell those listening what you think the answer to those questions are.

Asking WHY always produces better answers to HOW.

Michalis Kamburelis wrote:

Michael: As for my post where I used the term “lusers”: I used the term “lusers” for “users that use IE (IE means Microsoft’s Internet Explorer)”.

My intention was just to say that IE is a bad www browser. Surely, I didn’t want to insult anyone (including people who use IE). “Visitors”, “users” are always respected. Even when they use software that I think is bad. Surely, users don’t have the time (and will) to try and compare various www browsers and judge which one is better. And users don’t have time to read some articles about why open source is better. That’s OK.

If user uses software that is bad, I criticise the software. It’s not the fault of the user that he uses the only www browser that was initially installed on his computer.

So my “insult” was only directed at the piece of software called “Internet Explorer”. Not at users. My apology if it sounded different.

Jeremy Dunck wrote:

Robby Slaughter,
So long as XAML is not an open standard format, it should not be considered a platform for web development.
See the gnashing of teeth regarding the Office XML vs. format.

Robby Slaughter wrote:

Jeremy: You’re right, I am sorry if I implied that XAML was an “open standard”, though I do think those words are kind of slippery. Anybody will be able to write XAML code and create an platform that runs XAML applications, so although Microsoft will control the details of the specification, I think it’s pretty “open” of them to let other people use it freely.

Michael A: It’s not a question of *owning* the web, just *designing* it in a way that is a little less stochastic and messy. We’re a decade into developing web applications that still pale in comparison to what we could do on the desktop in the mid 1980’s. Why? Because of the insane feature creep of the browser wars and the willingness of developers to wade into half-baked technologies without adequate forethought.

The rise of AJAX is a continued extension of this unfortunate trend. It’s like a cold war—these techniques are wildy technologically inadvisable and horrific hacks, but we have to pursue them because everyone else is doing them. Why can’t we take a deep breath and figure out what users really want the web to be (as XUL/XAML desingers have done) and start to do things the right way?

Jeremy Dunck wrote:

Sebastiaan wrote:

I am going to embrace AJAX simply because it does so much better. A couple of years ago I developed quite a complex webapp that would have been simpler to produce as a Windows app. But because we didn’t want all the hassels of a Windows app, we tried as best we could to create a nearly Windows app. Most importantly: all actions by users within a complex of tabs should not lead to a refresh of the page with the new data. For this we used WDDX, javascript and an iframe to post the useractions to. From the iframe we then wrote the new code that had been processed at the server and posted it back to the client via WDDX and javascript. Excellent, fast, useable and customers happy! And then came along AJAX!!!
If it only had been there a couple of years earlier, then we could have made the webapp truly cross-browser. Luckily the switch to AJAX isn’t that hard! Go AJAX!

nilettes wrote:

“Ajax” signifies a collection of prior existing, relatively mature, mutually supporting web technologies that many of us have been using for years in roughly the same way Ajax describes. So what is it then? Nothing but a snappy label–with an increasingly heavy dose of hype.

Like Cayce Pollarda’s allergy to brands, I have an allergy to hype. It starts in the pit of my stomach with a squishy queasy feeling, and then moves up to choke my throat, and finally lands in my sinus cavity with throbbing pressure on my sensibilities. Ajax is starting to give me some mild queasiness.

Some of you may have noticed that Adaptive Path coined the term “Ajax” and is doing a terrific job of branding it (this well-written article is a fine example). Of course in branding Ajax they also brand themselves as THE go-to company for all your Ajax needs (sort of what Cooper has done with personas). This strikes my cynical side as more of an Adaptive Path marketing initiative than a genuine technology.

This is of course a fairly common criticism, even appearing in wikipedia’s entry on Ajax.

On another note I’d like to take exception to the Oddpost vs Google example. Garrett asks “[w]hat’s the difference between Oddpost and Gmail?” And then goes on to imply that the difference is Ajax, and that Gmail beats Oddpost hands-down because of it.

While I agree whole heartedly with the philosophical reasoning that open systems are ultimately superior to closed systems, I think Garrett presents a false dichotomy. The real differences between Oddpost and Gmail start with the fact that Oddpost was created by two unemployed guys with laptops sitting in a San Francisco coffee shop. While Google is a multi-national behemoth that’s starting to make even Microsoft worry.

Despite the resource constraints, Oddpost developed one of the simplest, most elegant UIs I’ve ever used. Its light-years ahead of Gmail and other webapps. It light-years ahead of most desktop apps. And I was happy to pay a mere $30 a year to have it. Meanwhile, I dread having to even look at Gmail, let alone use it.

Gmail is succeeding where Oddpost failed because of branding, marketing muscle, 2gigs of storage, and a $0 price tag, not because it offers a superior experience (which it does not) and certainly not because Google developers followed a CSS/Javascript/XHTML technological implementation that allows a small handful of rabid Safari fan-boys to read their email.

Garrett concludes saying “the recent Ajax explosion signals a new chapter in the history of Web design.” I suspect that’s a bit melodramatic. The web has seen lots of hype come and go.

Ilkka Rinne wrote:

I think some of us are missing the point here: If the main reason to make a web application is zero maintenance and on istalling hazzle at the user end, then why should we maintanin the fundamental web page model, history and so on? Why not just open a new window for the application without any browser-like decorations and make the whole thing look like desktop application? Snap, you have entered the world of desktop application interaction (the surfing world is still there in the original window).

If the interaction will be like in desktop applications then the application should also look like one to help users create the right kind of mental model. Sure, back functionality is nice to have in many cases in desktop apps too, but the only proper way to make it work right if you are changing views without letting the server know, is to implement it in the application interaction logic. Make your own back button, mouse gesture or what ever to trigger returning to the previous state/view.

AJAX is interesting, but implementing more than the simplest GUIs with DHTML+JavaScript is still painful compared to Java Swing applications for example. The browser is designed for the point-and-click hypertext navigation. If your application does not work like that, why confuse the users by sticking to the browser navigation UI?

Paul Brown wrote:

Ilkka goes back to my original concern; the lack of a decent IDE for Javascript makes developing a decent app a nightmare of epic proportions. Also, having done a bit more homework in the last week, the fact that Ajax uses an ActiveX object as its core tech is a little concerning. Firefox and Safari may well have this as a native object now, but you still have to have different code to cope with different browsers and what you are using is essentially not an agreed standard, not to mention that the user must have JavaScript and ActiveX enabled on their browser for this to work.

The principle of splitting off the interaction by a level is an interesting one, but I’m sure that the same results, if not better, could be achieved with a combination of JavaScript, a hidden frame, PHP / CGI et al and MySQL. A genuine app in Java would be even better.

I’m sorry, but I’m just not at all convinced that this is a wonderful new dawning of interaction and not just a combination of buzzwords and marketing.

Francois Le Ralle wrote:

As far as I understand, AJAX is breaking the document logic of web applications and relacing them by an application logic which. This modifies the user browsing interactions. So there should be a separate protocol for AJAX so that browsers can identify them and provide adequate functionalities, or may be better, the same http port with a specific http header, so that the network layer protocol filters continue to work with no configuration change.

Sam Schillace wrote:

Great discussion.

We’ve been soaking in these issues over at We decided to try to use “Ajax” (whatever) to build a word processor that was “of the web”, not just a clone of a desktop app.

I think the original article nailed it - we’re seeing a phase change here because the Ajax stuff is widespread enough that you can develop mainstream apps for it now, and reach a wide audience. This was one of the first things we looked at before doing the app, and we reach, I think, something like 85% of the installed base right now.

The client-side JS environment is really interesting to develop for. The comments above on having to have a more mature conception of state are spot on - we had to sweat bullets to make this work for our live collaboration feature. But…it’s what users want, and expect, and you just have to do it.

And the bottom line is, if you’re doing these kinds of apps because you can deliver value, users don’t care why or how you’re doing it. This is what we’re finding with Writely - it’s just better for lots of light document editing than the desktop, and we think we’ll see the same kind of migration from the desktop that the email market saw.

Like it or not, for this moment in the market, AJAX is “good enough” and is likely to push the rest of this stuff off the stage for a while. It has all the characteristics of a “wrong is right” technology.

Give us a try if you have time - I think we’ve made good choices about how to do an app like this, I’d love the feedback.


Sam Schillace wrote:

Sorry…meant “worse is better”, not “wrong is right”…need coffee.

This is what I’m talking about, if you haven’t read it:

Rex Spearman wrote:

Paul, in response to your comment “the lack of a decent IDE for Javascript” I have come across this site which seems to suggest that they are to announce something at the web2.0 conference which sounds awfully like an IDE,seem to call it a javascript synthesis technology so not 100% sure. I guess Jesse is saying we are a tipping point in the concept of web as a platform. Time will tell.

Siamack Yousofi wrote:

Rex, great you found us and just to clarify, Morfik is indeed a specialised AJAX IDE. With Morfik, programmers implement the business logic of their application in a high-level object oriented language of their choice. Morfik compiles this code into a JavaScript AJAX engine. The process is a true compilation and avoids boilerplates or code snippet libraries. Since the output is neither an executable in machine-code nor a one to one translation of the source code nor a collection of predefined code snippets, Morfik process is referred to as JavaScript Synthesis Technology.

Paul asks - “Why JavaScript? The lack of decent IDE’s and slower running are not a problem for simple things, but surely a fully fledged application is easier to develop in Java?”

To give you an idea of the power of JavaScript Synthesis Technology, two of our programmers used the Morfik IDE to build a desktop version of Google’s Gmail in 2 months! This is a pixel by pixel match of Gmail and its functionality yet it works off-line. We will demonstrate Morfik IDE, Desktop Gmail and its design process at the Web 2.0 conference.


Mark Birbeck wrote:

Interesting points, to which I’d like to add a couple.

A scripted editor will not be as good as a desktop app, just as a scripted email client is not as good as a desktop one. That doesn’t mean that the scripted version is not useful, and it certainly doesn’t mean that the future is in the hands of good old-fashioned ‘desktop apps’.

Instead, what it means is that the features that are available to a desktop app prorgrammer should be made available to the web app programmer.

Some will disagree on even this first point, but with all respect to them that’s kind of irrelevant. People upgrade browsers all the time, and are even happy to try new ones, so there is no essential problem with adding better ‘application’ support to a browser.

In my view the key issue is not whether it will happen, but what form it will take. How should this new kind of programming be done?

Part of the problem with desktop apps is not just that they don’t take full advantage of the web, but also that they use ‘heavy’ lanuguages such as C++ and Java. Web pages on the other hand are a narrow class of applications that are easily programmed with simple mark-up. For example, how much programming used to be involved in creating an area on your application that could be clicked with a mouse, and then in turn cause a new page to open. Thanks to the HTML ‘a’ tag, this functionality is available to just about everyone.

What we need for the next generation of web apps then–the ones that are more like desktop apps–is a language like HTML, that provides the power of C++ or Java.

Of couse, Microsoft might tell you the same thing, but it is difficult to see XAML becoming as easy to use as the HTML ‘a’ tag. I’d therefore suggest a different solution.

I’ve been involved for three years now in XHTML 2 + XForms, two standards coming out of the W3C. XForms is a full standard already, and works in a number of browsers, successfully capturing common web programming patterns ranging from error-checking, mouseover hints, through to submitting data via HTTP or email. (XHTML 2 is still in draft form.)

An example of how XForms Submission is as easy to use as the HTML ‘a’ tag is in my blog article XForms: An Executable Pattern Language.

The article describes firstly how the XForms submission element is far easier than using XmlHTTPRequest, but then, more importantly, goes on to show how the very same tag can be used to achieve functionality such as reading and writing to databases, sending email, saving and loading local files, and so on.

Whilst AJAX obviously has a place in providing a sub-set of this functionality–a means of communicating via HTTP–it is extremely important to be clear about where it fits in the ongoing evolution of rich-client technologies. It is not the end of the road, but it is a very useful transition point on the journey.

Mark Birbeck

j oonk wrote:

I agree something like AJAX is where it’s all going, however I cannot see client-side technology like javascript as a functional part of that picture. So long as the technology we use to run javascript is not ‘under one roof’ and continues to behave in an unpredictable manner across browsers - it won’t establish a useable foothold as a technology that can be used for solutions. Or, more specifically the computer illiterate higher-ups in any organization who control budgets and initiate projects must be able to see and make AJAX work for themselves, and it must do so flawlessly. (Even on that their POS windows 98 laptop they have at home that you reluctantly support.)

I believe the functionality we are all looking for is described in something like flash, but needs to be bigger and more robust. The next generation rich client solutions like
Curl, or Laszlo Systems have the horsepower and the consistency more like that of an operating system to make what we need possible.

Wiki wrote:

From the Ajax WIKI
One major complaint voiced against the use of Ajax in web applications is that it might easily break the expected behavior of the browser’s back button (see Jakob Nielsen’s 1999 Top-10 New Mistakes of Web Design). Returning to the previous state may not be possible when a page is updated dynamically, since browsers typically record only static page visits in their history lists. The distinction between a static page, loaded in its entirety, and a page which has been modified dynamically might be a subtle one; users generally expect that clicking the back button in web applications will undo their last change and in Ajax applications this might not be the case. Developers have implemented various solutions to this problem, most of which revolve around creating or using invisible IFRAMEs to invoke changes that populate the history used by a browser’s back button. (Google Maps, for example, performs searches in an invisible IFRAME and then pulls results back into the Ajax element on the visible web page; the Dojo toolkit allows tracking of Ajax requests via callbacks which are called whenever the back button is pressed, restoring the application state that existed at the time.)

A related issue is that the use of dynamic web page updates makes it difficult for a user to bookmark a particular state of the application. Solutions to this problem have likewise begun to appear, many of which use the URL fragment identifier (commonly known as the anchor, or the portion of the URL after the “#”) to keep track of, and allow users to return to, the application in a given state. (Many browsers allow JavaScript scripts to update the anchor dynamically, which allows the Ajax application to update it in parallel with the contents of the display.) These solutions also address many of the issues related to lack of back button support.

Network latency — or the interval between user request and server response — needs to be considered carefully during Ajax development. Without clear feedback to the user, smart preloading of data, and proper handling of the XMLHttpRequest object users might experience delay in the interface of the web application, something which users might not expect or understand. The use of visual feedback to alert the user of background activity and/or preloading of content and data are often suggested solutions to latency issues with AJAX.

There have been some critics of the term Ajax, claiming that Adaptive Path (the consultancy firm that coined the term or other proponents are using it as a marketing vehicle for previously-used techniques

Dave wrote:

There have been some critics of the term Ajax, claiming that Adaptive Path (the consultancy firm that coined the term or other proponents are using it as a marketing vehicle for previously-used techniques

Hello!!!!! people! all technological complaints aside, AJAX and browser-based applications at all are on people’s lips b/c of what Jesse and AP gang have done. By eliminating the techno-babble and creating a real achronym for people to get their heads around w/ an explanation of its viability has been a HUGE triumph.

re: the complaint about state management
Why do I always have to manage state? Do I bookmark every state in Outlook? So why would I want to save every state just b/c it is in a browser. Yikes, people! let’s not hold onto old conventions for not good reason.

Jared Spool wrote:

Re: State Management

Imagine an AJAX-based interface that presents a list of links (say people who’ve linked to your blog).

To keep things manageable, the designers have restricted the display to list only 10 links at a time, though you might have 30 or 40 to display. Therefore a simple next/prev navigation scheme is set up.

Now, to keep page refreshes to a minimum and perceived performance to a maximum, the designers have decided to implement the next/prev architecture with AJAX too. So, as you go forward in the list, you’re just getting the partial page served, ala a standard AJAX interaction.

This all works well until you click on one of those links. When you click the back button to return, the state of the list is lost and you’re returned to the top.

One could argue (and I’m sure one will) that this wasn’t a good choice for AJAX. However, I think it’s premature to know what is a good choice and what isn’t. I think we need (a) to keep innovating and seeing where we can get past these obstacles and (b) become familiar with our tools and learn how we make good choices and what bad choices we should avoid.

Ajax Wiki wrote:

Using Ajax technologies in web applications provides many challenges for developers interested in also adhering to WAI accessibility guidelines. Developers need to provide fallback options for users on other platforms or browsers, as most methods of Ajax implementation rely on features only present in desktop graphical browsers.

Web developers use Ajax in some instances to provide content only to specific portions of a web page, allowing data manipulation without incurring the cost of re-rendering the entire page in the web browser. Non-Ajax users would optimally continue to load and manipulate the whole page as a fallback, allowing the developers to preserve the experience of users in non-Ajax environments (including all relevant accessibility concerns) while giving those with capable browsers a much more responsive experience.

Many popular applications using the concept have been created, including Google Mail and Google Maps, and Flickr. These high-profile examples of Ajax usage demonstrate the flexibility and utility of the web programming model. Google’s competitors have recently released similar Ajax-based websites

Anon de Reddit wrote:

Sorry, just a wisecrack, because I’m as clueless/hyperhyped as the next guy; might serve as a comedy relief or tasteless troll but here it goes:

Next up on the battlefield: Achilles! Being shot in the foot will become legendary ;)

Paul Brown wrote:

two of our programmers used the Morfik IDE to build a desktop version of Google’s Gmail in 2 months
yes, and I’ve built a fully functioning SQL database using Excel 97 and VBA (don’t ask, just pray to whatever you hold dear that you’ll never have to do it). The point is not if you can do it, but if you should. I still can’t see anything that Ajax can do that Java can’t do better. If anyone else can then please show me the error of my ways.

Matt Herres wrote:

I was doing AJAX and didn’t know it at a former client. The applications we created were the smoothest, sexiest looking applications.
At another client, we’re [I am forced to use it] using the prototypical J2EE/Struts/Tiles/Workflow layered approach.

Who needs a complicated workflow layer with AJAX? With AJAX the flow is kept in the page just like in Java SWING or MFC or VB applications. The user, intuitively, knows when to press the SAVE, ADD, DELETE keys because the AJAX programs I write only make these buttons enabled when all validated conditions are met. Complex checking to enable/disable buttons happens in the background. Imagine a field which requires 4 characters and which has 4 characters in it where the user hits the backspace. Now it only has 3. Instantly, some action button is disabled. The user immediately notices this (cause and effect) and knows, intuitively, that the field requires an exact or at least minimum number of valid characters. There is no better way to guide workflow than to have immediate and visual responses to a user’s input.

Calls to the backend are granular examples of service oriented architecture where each call requests something specific and gets it. This makes it very easy to debug and one call broken doesn’t necessarily impact other calls.

I developed POJOs (Plain Old Java Objects) to render [using FOP] PDFs from two “ingredients”: XML and XSL (stylesheets). From an AJAX application [running on client] I make a call to the backend to get an XML data result set based on user parameters. Then another call to get the specific XSL to that report. Then, from the AJAX client, open (open as new browers page or popup) a generic servlet page that only knows about the two ingredients and render the PDF on the new browser window.

Using AJAX allowed me to decouple the getting of the desired ingredients (in background calls) from the rendering based on those ingredients.

Now I do multibrowser AJAX. Though serious javascript seemingly complicated at first, once mastered, the entire system is simpler to construct and debug. Now that I’m reluctantly mired in the “traditional” J2EE/Struts/Tiles/Workflow solution I am trying to spread the good news about AJAX. Development just doesn’t have to be as grief filled!

BTW: I used to absolutely hate javascript! Now that I have done some pretty wild things with it in conjunction with AJAX I love it!

David Heller wrote:

Java is a great programming language. The plug-in VM from Sun is just troubling, and if you g-d forbid want to do swing, your footprint is just huge. In fact the entire deployment factor of Java apps in scenarios with “locked” desktops by 3rd party providers is well just impossible. It’s a non-starter.

Jason Scott wrote:

To me the problem is we are navigating this sea of data in a dingy with 21 holes and I only have ten fingers and ten toes.

Java, ASP.NET, CSS, Jscript and AJAX to mention a few all have their pro’s and con’s. They all have their place just like we all have our opinions.

The real problem here is standards. The fact that we are still hacking and working around browsers at this point in the game is boggling.
Racing for market share of something that is free, great.

I’ll end this by saying I have recently been using ASP.NET and have cut down on server trips greatly on things like user forms and data display. It does just that writes browser specific jscript to keep alot of processing on the client side to enrich/speed up the user expreience.

I bid you all a good day …now back to MONO.

Justin Hardman wrote:

I agree that stating that gmail is a revolution is a melodramatic.

I think it has been important in in the development community though because it has shaken up web developers to push the technology harder. I think design had gotten complacet before gmail. Basically gmail is a few simple tricks, i’m not sure it adds up to a fully functional application. Anyway; it does break brower conventions as well. I think this is a really important point. However, its not to say that you can’t have a very ajax powered site and still conform to browser conventions. It just depends on how you use it. one has to be smart about it. the problem is due to the relativly open way ajax works and the flexibality of DOM its very east to be Stupid with ajax applications. the reason the web works as well as it does is the limited tools we have for dynamic interaction inevitably lead to standards and conventions. Ajax looks to break all those conventions if misapplied.

Rex Spearman wrote:

I started looking for an AJAX IDE after I read Paul’s initial comment as I felt it made sense particularly with regards to a ‘fully fledged application’ as that is the business I am in – large scale application development, certainly not AJAX (actually have done very little in it). I was not sure when I came across Morfik whether their JavaScript synthesis was really an IDE but having now read Siamack’s comment and their whitepaper ( I realize it is more than an IDE. It takes VB, C# or Java and ‘compiles’ it into the intermediately language JavaScript and allows you still to manipulate the JavaScript should you be that way inclined. The result is an application which is a true browser program, not a plug-in. It really treats the browser as its OS. This all while it has a tightly inbuilt web-server and database. I find that astounding; to be truthful I have a nagging feeling it is hype (sorry Siamack). But I hope I am wrong as it would allow me to develop applications which are really OS platform independent and work online and offline. I also agree with Justin re ’shaken up the web developers to push the technology harder’. From what I can see it is pushing people like me also harder, beacuse we have to re-assess our responsiblity to deliver friction free interface/applications more and more.

Alan Gutierrez wrote:

joonk - There is no alterative to Ajax. It’s not an offering from a vendor. It’s something that is just there.

Siamack Yousofi wrote:

Rex, thank you for the feedback. I assure you that the Morfik IDE and JST are not hype and people will get a chance to see it in action next week during the Web2.0 conference.

You mentioned the phrase “It takes VB, C# or Java and ‘compiles’ it into the intermediately[sic] language JavaScript…”. I need to shed some light on this in the spirit of preventing any hype that may arise. To clarify, when a C++ program written in MFC is taken to a Borland compiler and VCL it will not compile without modification due to the dependencies of the code and differences of these libraries. MFC must be “ported” to VCL. The same applies to Morfik. We designed our compiler for “original code” rather than “legacy code”. A program written in C# a while ago may not compile without modification and has to be ported to Morfik.

To avoid the confusion we refer to our implementation of high level languages as Morfik C#, Morfik Java, Morfik Basic and Morfik Pascal (with more to come). All of these are fully object oriented and support all object-oriented constructs. When one writes in Morfik C#, one is thinking and expressing the logic of application in C#. The Morfik compiler (or more accurately “synthesizer”) takes care of the rest and produces the JavaScript semantic equivalent of the source. The appendix at the end of our white paper describes this in more detail. This is why, in the white paper, we say “developers must be able to leverage their existing language skills” and “programmers implement the business logic of their application in a high level object oriented language of their choice”.

As for the unplugged nature of Morfik applications, we do not claim any magic here either. Obviously if a web application is to continue running after being unplugged from the web, the browser requests must be handled locally. This requires an HTTP web server (or at least the relevant functionality of it), and such a local server is incorporated in Morfik applications. The same argument applies to database servers. Morfik applications incorporate an RDMS. In applications created with Morfik, all components are linked within a single executable and run under a unified computational space.

I hope this clarifies some of the mist. Stay tuned.

Siamack Yousofi
Chief Technology Officer

Seth Steben wrote:

I just wanted to respond to Mark Birbeck’s comments above, and I find it odd that I appear to be the first to do so here.

It seems to me that Mark is one of several to approach the topic here, but he is actually I think the only one to come out in clearly stated support of W3C standards which, although not yet widely supported, offer IMNSHO (In My Not So Humble Opinion) the clearest vision of what the web can offer in the near future without compromising standards. I am referring to the XForms and XHTML 2 which Mark mentioned.

The more that I have worked with xhtml/css and (more recently) xml on a broader scale, the more amazed I am when I see web sites and applications still relying on HTML 4 with limited or zero use of css, or on older, often proprietary markups and data formats. I realize that the reasons for this are varied, but I would suspect that they generally relate to one or more of the following:

*Real or perceived lack of support across all or most clients (software) used by the vast majority of existing or potential clients (human). This is increasingly invalid as an excuse, although we all know IE demands significant hand-holding when it comes to css.

*Real or perceived ‘cost’ of rewriting legacy code. This understandably slows or limits the updating of many long-established websites, especially those with large archives or enterprise structures based on legacy code/data formats. But I would argue the cost of not updating will increasingly offset the one-time expense involved in bringing these sites to the 21st century. I say ‘one-time expense’ because xml/xhtml/css are standards which are designed for future compatibility, and they make portability a breeze.

*The perception on the part of some developers that these standards are fads, and that it is best to stick with tried-and-true technologies. Well, 5 years ago, I could see this as a valid excuse. But today, you must have your head in the sand if you try to argue this. Also, WHAT tried-and-true methods? They were all abominations!

*Lack of support for these standards in existing IDE’s/editors. This is a very real problem, which is not adequately addressed by ANY of the major players, although I think we can say that Macromedia has gone the furthest in the right direction with Dreamweaver (not Flash).

*Belief that it doesn’t matter what coding standrds are used, so long as it ‘works’. This is perhaps most significant, and most insidious in a way. This mentality (or some form/extent of it) is represented in many comments here, and it is entirely understandable. Unfortunately, it is also one major factor in preserving/reviving ‘bad’ practices and proprietary solutions.

There is considerable agreement here that AJAX is nothing new, but that it is an umbrella term for existing technologies. Now I think that this explains much of the hype. Why NOT be excited when you discover that the latest and greatest is already in your bag? And I think that this is a positive trend in many ways, in that there is a focus on changing the way we approach our existing technologies, in that standards-compliance is emphasized, and expanding on what we already know allows for rapid implementation of useful applications.

BUT (and there is almost always one of these in my rants), I agree with comments here that AJAX is near-sighted. Perhaps the most obvious and compelling reason for that statement is the fact (yes, fact) brought up by someone earlier: AJAX is a HACK. We are well-acquainted with hacks in the web world, and one might almost say that it comes with the territory (and so long as you have browser development in the hands of the likes of Microsoft engineers, this is not only possible, but likely). And due to browser limitations, the argument for AJAX is as compelling as it is near-sighted. After all, developers need to implement services TODAY, not 3 years from now.

BUT (another one), 3 years from now, we will still need to develop new services (and 5, 10, 50 years . . .). So it becomes important to look towards the future even while rushing to implement what we can today. And, frankly, I don’t want to be using JavaScript today, much less in the future. I don’t see any indication that it is suitable in the long-term, although I was pleasantly surprised when I found how well the W3C managed to incorporate it into the DOM. It does allow for quick and easy implementation of services which are increasingly necessary in today’s environment, and therefore it has its place and fills a valuable role. But JavaScript really, truly, and completely, SUCKS (my unprofessional, childish opinion, here).

So where to look for the standards of the future? Mark had it right, I believe, when he mentioned XFORMS and XHTML 2. While these may not hold all of the answers, I can assure you that they will set many of tomorrow’s standards (well, they ARE tomorrow’s standards). Somebody else mentioned Open Lazlo- from what little I have seen so far, I tend to agree that it is very forward-looking. So do what you have to do to implement what you must today, but prepare for a future that leaves behind widespread dependence on ugly hacks- I believe it is in sight.

Aaron LEventhal wrote:

Firefox 1.5 due out before the end of 2005 will support accessibility for AJAX and DHTML applications.

Take a look at for more info.

DHTML accessibility, and accessibility in general, is something that IBM is contributing to the Mozilla open source effort. I’m the architect working on it.

Questions welcome:

Joe wrote:

I’m suprised at how close-minded a lot of the people appear to be on here that are posting replies. I don’t think AJAX is going to replace the traditional way of creating web pages. I think it’s a great method for an in-house webapp where the environment is controlled and you know for sure which browser your app-users will be using. I think the idea is to take a desktop app and replace it with a webapp, not necessarily to replace the company website.

hilary wrote:

Perhaps a naive question, but I was wondering why there doesn’t appear to be a push for a “browser” that is not a browser at all, but just supports viewing of web clients (I’m thinking Firefox without the menu bar, nav buttons, bookmarks, etc.–just a window with a title bar)? I realize that this will make the “browser” unsuitable for its original purposes, but why not have two tools for two completely different purposes–page browsing and web app interaction–or at least two completely different states for the browser?

In regard to all the comments about AJAX failing with state management, it seems to me that this is a result of displaying things built in an application paradigm in something which supports the page browsing paradigm. Joe writes: “the idea is to take a desktop app and replace it with a webapp, not necessarily to replace the company website”, but why are we trying to display both webapps and websites in the same environment? Once again, I’m assuming that this is a very naive question, but I’m curious if someone has and answer/feedback…

David Heller wrote:

Hi Hilary,
I don’t think the question is naive at all. I ask it all the time. There is though a simple answer. “B/c it’s there.”

Yup, that simple. What you are describing doesn’t exist, so the point is sorta moot in a way. BUT! there are examples that do come darn close:

1. Java Web Start. Click on a link in the browser and it opens up an application in its own instance state. Doesn’t need the browser once started.

2. XUL applications sorta do this, but again still start from a browser first (at least the first time you use it).

3. WinFX … check out … This is sorta a nicer-friendlier .NET application, but it has alot of the good points of a web/app as well.

I think AJAX is compelling first and foremost b/c for fairly simple rich behavior it requires nothing further to deploy other than the browser, which as we know is well, there already. XUL is there already too if you have a mozilla/netscape browser, but most people still don’t.

Flash is also already there for most people, but it has its own sets of problems.

What makes AJAX good is that you can scale with it. You can do something as simple as just designing a small widget with it, or you can do an entirely new page/state paradigm. And you can scale as slowly or quickly as you like.

Flash CAN do this too, but requires new skillsets that most web programmers don’t currently have by default.

Lots more … While you can look at one point and go Yay! or Nay! if you look at the total picture on all sides it is pretty darn complex.

Mark Peterson wrote:

I have to disagree with this statement:

“Proprietary solutions are never as compelling for Web designers as open standards are. Web designers are passionate about the Web as a medium, and that medium doesn’t belong to any technology provider.”

In my experience, Web designers have preferred proprietary technologies to open standards. I have not yet worked with a Web designer that hasn’t sighed “Oh, if only we could do the whole site in Flash” at least once (I admit, there have been times I’d wished I could do a particular homepage design as a huge image-mapped GIF). Many come from print or similar backgrounds, and they miss the amount of control they can have over pixel-perfect layout, fixed and predictable “page” dimensions,” and of course, their fonts of choice. They also like the degree to which Flash allows them to control the user experience and flow, like they would in a CDROM piece or TV commercial.

My $0.02.

Dave wrote:

Mark, I think you are totally right. I think the above quote you refernce, really means “web programmers/coders” and not designers. Designers really don’t give a hoot about technology. They care about aesthetics, behavior, usability, brand, legibility, findability, and well success. Whatever gets the job done. A good designer SHOULD be technology agnostic. Often we aren’t well b/c we are marketing sponges. ;)

hilary wrote:

Just an update to my previous post (and thanks Dave, for your feedback!): I found an interesting article by Jason Kottke musing about Google’s plans for web-desktop apps in the future:

Dan Shafer wrote:

Great discussion. Jesse, I envy your ability to trigger a passionate but not flaming discussion about an important new approach to a long-standing problem. I’m excited about Ajax for the same reasons many of you have stated here, but I suspect that in a year or two it won’t be Ajax per se that “wins out” in this effort. It will be something that merges Ajax with the likes of Laszlo Server.

This *style* of app — an app in the browser — must eventually win because it eliminates so many of the platform-specific issues inherent in today’s app development. Writing desktop apps in Java is a chore and the resulting products are often bloated. Plus, cross-platform UI stuff is still not quite there, at least according to my colleagues who do Java coding. I use a tool (Revolution) that really lets me build cross-platform applications quickly and smoothly but which is not suited to all kinds of apps (though it IS suited to 80% of all kinds of apps). That’s great but what I really want isn’t cross-platform software, I want platform-free software. And the browser offers the best possible current solution to that problem.

What we need, it seems to me, is a great IDE in which to build Rich Internet Applications (RIAs). We have such an IDE today — or at least most of it — in Dreamweaver, but DW is: (a) proprietary; (b) expensive; and (c) about to become the property of one of the worst software innovators on the planet (Adobe). So what’s needed is for someone to tackle the idea of an Open Source scaled-down DW clone that focuses all of its energy on enabling the creation of Web applications as RIAs.

I prefer the Ajax model to the Laszlo model only because I dislike relying on a plug-in, regardless of how ubiquitous that plug-in might be. Users who don’t have the plug-in won’t always download it and the company that made the plug-in is always somehow in the mix. As the Adobe acquisition of Macromedia demonstrates, you can’t rely even on the relatively large, stable companies to “do the right thing.” But until Ajax has a DW-like app for development in place, it won’t be able to get the kind of traction it will take to move the marker substantially away from desktop apps being so much better than Web browser-based apps that the latter become compelling.

On another note, Morfik does not seem to have been released yet. Did it actually debut at Web 2.0? If so, what is its status? The Web site still talks about the upcoming Web 2.0 trade show debut. Even if it is ready to go, however, unless the screen shots on the Morfik site are misleading, we’re not talking about a graphical IDE for the creation of rich apps with Morfik. It’s just a text editor/translator-compiler which may well have a lot to offer the community but which will fall short of a DW for Ajax or DW for RIAs.

Oh, yeah, and I tried Writely. I like it. A lot. I think it is a good demo of what *can* be done with Ajax (even though the developer here seems to be saying that doing it in Ajax was very difficult and challenging.

Dave wrote:

So I mused early on in this thread, and that musing turned into a big fat long article with screen shots and everything. So That doesn’t quite even fit in my own blog, but my blog can link to a PDF file.

Dave wrote:

Ok, why is it “Ajax” and not AJAX?
Is that jsut b/c it it happens to be pronounceable? Just curious? I know we do that for Laser and Radar, but those are acronyms that have been turned into regular words even in the dictionary. While I love AJAX as a term, I just don’t think its “arrived” quite yet. ;)

Dan Shafer wrote:

I’ve just spent about two hours with OpenLaszlo Server (, a free, Open Source RIA creator that I tried about 18 months or so ago and found interesting but not quite ready for my level user. They’ve made great strides, are up to a 3.1 release, and it is truly an intriguing, powerful package. Release 3.1 says it includes the AJAX API. This means the built-in XML-based OO language includes an XMLHTTPRequest class that implements that class as specified by the governing consortium (here’s the spec page:

The range of UI components and the elegance of products made with Laszlo is pretty astounding. I’m not deeply enough into it yet to know for sure but this could be a really interesting tool for folks interested in AJAX.

Dan Shafer wrote:

I should have mentioned that Laszlo outputs .swf files natively rather than XHTML, so it’s not, strictly speaking, the same kind of animal AJAX is, but it does solve a similar set of problems and, as a tool, is very mature.

Carlos wrote:

Ajax is a word. It’s the name of a product you can use to wash toillets. And now it’s an acronym you can use as a selling point to your customers. :)

Dave wrote:

Carlos, any new word can have derived meaning if you allow it to. Yes, it is marketing speak … but isn’t marketing speak about communicating an idea to people. If I said HttpXMLRequest (the real guts of AJAX) that really doesn’t have a lot of meaning. But now we have a word w/ hype that is quite useful. What’s so bad?
— dave

Siamack Yousofi wrote:

Dan, in response to your question, Morfik did actually debut at web 2.0 conference.

We are starting a Morfik pioneers program in the next few days. This will make a pre-release copy of the product available to selected developers ahead of the product release.

Morfik is a full featured visual design environment in the same class as Visual Basic and Delphi. Among other features, it includes a visual form designer, a visual report designer and a visual query builder. All graphical designers are specifically made for AJAX development.

Further, Morfik is designed for professional developers and includes comprehensive debugging and profiling facilities for developing high-performance AJAX applications.

Siamack Yousofi
Chief Technology Officer

Robby Slaughter wrote:

Here is the bottom line.

Interactive web technologies give us the power to do things in the browser that were absolutely possible (and totally done) ten years ago with ancient hardware and comparitively primitive software.

Ajax isn’t a standard, nor a revolution. It’s a semi-functional accident. For the entire history of computing we’ve been trying to get applications to work everywhere, and we finally have sufficiently massive amorophous layers of software to get some kind of traction. Not that any of it is really very good.

I think if anything, we should be apologizing.

Ashley wrote:

This has been a very informative thread.

I believe Web technologies is analogous to the saying… “too many cooks can spoil the broth”

Why? …you need a team of specialist PHP, MYSQL, XML, XSLT, JAVASCRIPT, APACHE etc to develop decent web Apps. This approach makes it difficult for a single designer to see the “big picture”.

For example, a telnet session is far more effective for deploying a database enterprise system over a network than a web app strung together with PHP, MYSQL, APACHE, XML & JAVASCRIPT.

So many features are far more superior for telnet type sessions, especially in relation to data entry performance and keyboard navigation. keyboard accessibilty is a big issue with browsers. Its almost like the keyboard became the forgotten interface when we jumped to HTML point and click technology.

If enterprise systems are to move to the web, things like keyboard accessibility needs to be properly considered in web apps - as its far more effective for navigation and data entry. I am currently trying to mimick an enterprise system our company uses into a web app… the problem is the current technologies don’t seem to the have the capabilities. You lose more good features than you gain!!!

Dave wrote:

Yes, let’s bow our heads in shame for 3 decades of bad desktop software, and even worse network integrated software during that time as well. Sure, let’s take the really negative and unproductive route, and hide our heads in the sand, while a new opportunity of growth is being spearheaded.

Yes, that’s what I’ll do.


And the other bottomline Robby is while people were doing that work for the last 2 decades no one cared or listened or saw value in how to apply it to a wider set of ubiquitous uses until well recently.

Revolutions in technology don’t necessarily happen when the technology is available, but when barriers to entry of its use are reduced. Some of your bottom lines are just NOT true, and don’t make sense when looking at the entire picture. Purely even on a technological level it isn’t true.
IE 3 coulnd’t do httpXMLRequest, and Netscape 1-6 couldn’t either. It always required the install of something else like a plug-in, which has a whole set of reasons that it isn’t doable for everyone.

EVEN AJAX is not doable for everyone yet and it is the most deployable technology out there today. The only thing more deployable is just straight (x)HTML w/o any CSS or JavaScript.

So the bottom line is that you can sit there and complain about a new word meaning something old, or you can sit down, join the hype and start helping people to sell what people want to buy!

Shoot! even HTML itself is old compared to SGML. So???? Let’s not use that word?

Robby Slaughter wrote:

I’m just proposing that we recognize AJAX for what it really is: a sign of failure more than success.

I think we can learn from the mistakes of the past, but it requires really understanding what went wrong. Mr. Garrett seems to characterize AJAX as a pinnacle of technical achievement. That’s just plain wrong. This was the original dream of Java; the underlying principle of POSIX, X-Windows, telnet and even Pascal p-code! All of those technologies were unable to gain enough traction to become *the* standard. Until we understand why they failed, I see no reason to believe why AJAX is not simply history repeating itself—or why the future, with XUL and XAML—will be any different.

TuringTest wrote:

There are two technological reasons why AJAX could succeed where Java, X, XUL and XAML woudn’t:

- because in its current form it’s an already tested and debugged programming environment
- and more important, because it’s already instaled in practically 100% of the desktop computers connected to internet! That’s an advantage that no other GUI framework ever had, not even MS ones.

John wrote:

Amy, Check some good stuff on Ajax at This might help.

Chris Erickson wrote:

Paul Brown raised some great points way back on Sept 16. He sites the lack of IDE’s and ease of development with Java, as concerns about AJAX.

ICEfaces from ICEsoft ( offers a framework compatible with any IDE, and a capabilty to develop AJAX applications in all Java. The ICEfaces framework handles the AJAX bridge for the developer and implements direct to DOM rendering. All the application code is pure Java.


Edusilva wrote:

Slightly off topic, but what I find intriguing is that Adaptive Path seems to be very eager to call out AJAX wherever they can, and thus posting articles all around. And yet, after this very interesting discussion that arose on this site, I see no reply from Jesse himself what so ever. Am I missing something? Is this just some exposre bling bling? (Me off course chicken for posting anonomously, but still an honest question). Cos for all it’s worth. AJAX isn’t really groundbreaking from a design-perspective.

Eric wrote:

I have a question — aren’t there some restrictions on xmlhttp that restrict the power of AJAX? For example, isn’t XMLHTTP restricted to only going to the domain that you are already in? And also I believe it cannot do any secure processing. Am I wrong about this?

If I am wrong, it is probably because I am having trouble finding a good XMLHTTP reference. MSDN just has bits and pieces. There must be something better somewhere.

kuchinskas wrote:

As an, um… user.. I have a couple comments and a question.

Comments: Some of the posts about getting rid of the page metaphor remind me of early talk — and deisgn — out of, when the designers had all sorts of revolutionary ideas. The site seemed pretty unusable to me, and I guess others, because it pretty quickly settled down and designer settled for a lot of color. Meanwhile, as a longtime user, I rely on the back button and history, and I’d be very frustrated trying to use a site that didn’t allow them. Such a site — or service — would have to have superb navigation and design.

Now, my question: I think Hilary’s suggestion of something like a browser that only supports desktop applications would be a good way to go. Do some of the current standalone desktop applets, such as Konfabulator Widgets or Weatherbug, offer a good model for what you all are talking about? Something that I know will change on its own, that I don’t expect to behave like a browser?

Ron wrote:

I’m not a developer, but a technologist and a usability consultant, so my perspective may differ on those points.
I find it interesting that while everyone is up in arms about Ajax for one reason or another, no one has suggested that the problem/challenge may lie in the browser itself.
We have a horse and buggy and we’re trying to make it into a race car. It won’t work.

I’m drafting a requirements document for a new application, a bastardized browser if you will, that will provide a presentation mechanism for pages (with approprite associated controls) or applications (again, with the appropriate controls for that type of content). I believe this will be a step in the right direction.

Interested in joining in? Drop me a line.

Ashley wrote:

I’m still attempting to grasp the way XmlHTTPRequest method works.

I followed this tutorial to build a zipcode database search - that fetches city and state based on the zipcode entered in a form. The tutorial resides here.

After successfully building the zipcode web app I decided to add a few more features. Firstly I added previous and next buttons to allow me to scroll thru the zipcode database one I had populated the form after the first query. Which was easier enough with a simple function in the javascript.

After that I decided it would be a nice feature to have a city lookup table. It was designed so if I pressed a button it would pop a new window populated with a list of city names based on my query from the parent window. That way I could scroll to the correct city and then select and jump back to the main page with the new city record.

However, I don’t know how to send the selected xmlHTMLrequest back to the parent page. The XML seems to stay focused on the new window. Does anyone know if the xmlHTMLrequest can populate the query results in a window other than it was initiated from?

G. I. wrote:

AJAX is gonna be a nightmare of epic proportions.

Robby Slaughter wrote:

Ron: Yes, the problem is the browser!!! It was never designed for this purpose and we’re trying to force it into it.

However, there’s no good reason to invent a new platform for application delivery. We’ve got lots of perfectly good platforms, ranging from Java to Flash to the Win32 APIs to Mac OS/Cocoa. The problem is not with the quality of the platform; it’s with rates adoption that are less than 100%.

If you really want to contribute to the problem, work on the Mono project or help out with MyXAML. We don’t need another browser.

Oded wrote:

I kind of like this Ajax thing.
Actually 5 years ago i started to use it and built
a generic engine for that.
you are welcome to go and check it out

Leo Robert Klein wrote:

Although late in the discussion, I just wanted to add my 2 cents.

A lot of the interactivity and functionality that many of us find so attractive in AJAX is reminiscent not simply of Java or Flash but also in some ways of frames as well. Using frames at least in some deployments was an attempt to maintain state on parts of the page.

The reason why I bring this up is that these technologies and approaches were the cause of considerable differences between groups of designers and developers earlier on.

So while I love the stuff, I still wonder if AJAX is simply going to be the next chapter in the WebDev culture wars. You know, AJAXsux and all that. Are the lines already forming?

Jeff Hegedus wrote:

Hasn’t everybody been doing this stuff ever since the xmlhttprequest object appeared on the scene and before that with hidden frames?

No. Probably not. But some of us have been. It’s good to see that it is finally getting visibility.

Thanks, Jesse.

Anonymous wrote:

You are all missing the point: This is the greatest marketing scheme in the world to force or coerce organizations to move to proprietary solutions and to require users to move towards a web services model where all content requires a server visit to display.

These ideas are NOT new and have been around for 15 years or so and are simply being repackaged as a way to move towards vendor or site-visit lock-in.

Grow up and realize that a lot of us dont fall for marketing “strategies” such as these and wont be easily fooled to part with out budgets on these types of consulting ploys to assist us with such lock-in.

Brian wrote:

While I don’t totally understand how Ajax works, I’ve been reading, researching, and playing around with it. So far it doesn’t put a breeze up my skirt, but I see it working at Google and other places, so it works well.

But, even in my own experience I’ve found Ajax apps to go against many conventions I’ve learned since the web go big. Namely things like the Back button, page wait, etc.

The novelty of these apps is great right now, but when I watch people using Ajax pages - from my 60-year-old parents, to 40-something home PC people, to nerds like myself - they get confused because the rules they have struggled to learn are gone.

The rules might have been dumb to being with, but they were there all the same. People expect a wait and people are trained to use the Back button.

I work with so many people that are already afraid of technology (web or desktop) that they cling to what they know and don’t let go. In this case, they cling to the Back button, page refreshing, etc…and now that goes away?

I guess it’s the same learning routine as before when people needed to learn the web just to buy shoes and pay their bills, but it’s one I’m not looking forward to support. Developing, I can’t wait, but guiding and explaining is far from productive when I work (and live) in a world where it’s a mixed bag of technology to start.

“You can use the Back button with this tool, but not with that one.” Exceptions are not good and shouldn’t be pushed onto people, at least not when they have enough trouble as it is.

I don’t think Ajax is a marketing scheme. It has serious value. It’s something I’ll be learning how to use and build with. But it is (and has been) possible to build quality applications within the browser without Ajax.

Robert Litchfield wrote:

Coming late to this discussion has its advantages. I’ve read through all of the posts and as a Web Application Designer and Information Architect it has been extremely interesting. Usability is something that I care very deeply about and each usability challenge/model is dependent on what is being done at the time. To paint all websites with a single paintbrush will only cause you a world of grief.

I’ve done a lot of user testing in my time, and I’ve found there is a very distinct difference in user behaviour depending on what type of site/application they are on. If the user is on a content driven site, they expect that the full range of browser buttons will work. Ajax is clearly the wrong way of approaching building this type of site (even if it is all driven from a database). However, when a site is transactional based, the back button is ignored. When this is the case, Ajax (and a broken back button) is not that bad.

We need to remember to approach all of this, not as an exercise in technology, but a effort to make our users life easier. Technology is a means to an end, and should be used appropriately.

Dave Chapman wrote:

Got to agree with you there Robert.

I think there is a distinct difference between a “Web Application” and an “Application hosted by the BRE (Browser Runtime Environment)”, I see a Web Application as something like and an Application hosted in the BRE is comparable to a Swing Application hosted by a JRE (Java Runtime Environment).

With the Web Application model comes a set of conventions e.g.
1. Where the company’s logo appears (what happens when you click on it)
2. How you search for something
3. The “Submit” button
4. The “Back” button

With the Application hosted in the BRE model, which is evolving from the desktop model, comes a completely different set of conventions - it’s up to designers to apply the appropriate model.

Dave wrote:

To Robert’s point,
My experience is akin to yours but w/ a slight variation. While users change their behavior based on the type of product they are using, this does not manifest itself 100%. For example my studies (quite a few; over 100) with enterprise applications (BRE hosted to take David’s phrase) showed 2 interesting phenomena consistently that contradict each other based on Robert’s explanation:
1. They use the back button. Love it! Why? B/c the back button is also in the OS now. So it is not something specific to “the web”.
2. They go to the file, view, edit menu of the browser to do things. (This part supports Robert’s POV). And if there are two sets of menus as in my app the user goes to the browser version first and then to the one I intended for them to use.

But that being said, I have done some analysis of the “sucessful” AJAX sites out there and I have to say that there are patterns that can be derived and executed on that are quite usable in both usable and useful using AJAX type “effects” that should not “break” conventions that people seem to be holding so dear, despite the fact that most users have only been using them for about 5-7 years … not a long time when compared so to a door-knob, tea-kettle, or faucet. I don’t think there are any 2-D affordences in these conventions; thus, we can still explore, train, and see what works best over time. Usability labs fail at the “over time” aspects of designing a system.

Robert Litchfield wrote:

Dave1, would you classify a Google Maps/Gmail type application as being hosted in the BRE? I’m trying to get my head around this concept without putting my own definition on it.
Dave2, It is interesting to see the differences in usage regarding the back button, which makes it all the more important to do user testing with your customer base. Unfortunately, I also find many users end up at the famous File Edit View menus of the browser.

Testing and analysing the existing applications are the only way to continue to improve our customer’s experience when it comes to this “new” type of web application and design. I just hope that companies realize this and spend the money up front, in order to save in the end.

Ashley wrote:

If you look back at history one can join the dots. With the birth of the web brought the novelty of linking computer networks by hyperlink. Allowing uses to arbitrarily navigate through endless networks of rich media (movie, sound and picture files). It was a stateless environment but fascinating to anyone who was experiencing computers for the first time and many might say its one of the greatest invention of our modern era. But after a couple decades developers have exhausted the current environment and its time to take the user experience to the next level. I see the next stage being computer networks fastened together by XML. To link information you need a form of standardization and XML or a derivative of XML currently offers the most widely accepted platform. I see the browser technology evolving around the XML model. A good example is the JCX engine JavaScript library (one of the earlier posts). Here the developer has extended the HTML tag definition & uses the Document Object model to add a lot more functionality at the client end. Things like calendar look-ups, program calls, field validation, graphs, scrolling and many other JavaScript features are all bundled in the one JavaScript library. Negating the need for all over the place conventions of the past. This allows developers to concentrate on database back ends, knowing they have a robust powerful client interface, which can deliver the content in a standardized way. The JCX engine also uses XML islands to link the information to the DOM in a perfect fit. While the XMLHttpRequest allows for programs calls in the background and the updating of information without the need for full page reloads.

All those wonderful JavaScript’s libraries are crying out to be standardised and nicely integrated into HTML tag attributes by the browser developers

In the end these web applications will work just like desktop programs across networks, and I’m sure future releases of the browser will support this approach.

I wouldn’t worry about the back button problem in relation to the AJAX approach, its totally irrelevant to some interface designs as JavaScript already has the ability to control all the client browser features. By customizing the window on popup you can remove the toolbars and right click functionality.

rajendra wrote:

Hi thanks for information.But i am not satisfied regarding ur doc’s.Please send one example to mail id as i given earlier.
problem:one webpage containing one or two text boxes and one submit button.If we press the submit button the data must goes to the servlet and displaying the data with out reloading the page.I need this example please.

If u people give this example then i can easily understand the real stuff.I hope that u will send.

Loek wrote:

I like the Ajax concept and the capabilities it offers (although there are many reasons why you should not use Ajax, which have already been mentioned by some posters), but the tragic thing is that the name Asynchronous Javascript And XML is incorrect, in fact it is bullshit. The pattern does not necessarily have to work with XML (it can work with plain text), or Javascript (it can work with Flash too!), and it is definately *not* asynchronous. I have a further explanation on my blog:


Jeremy wrote:

As with several people, I’m coming in on the converstaion late. In my reading about the Ajax approach, here is what I’ve noticed:

“People complain about the ‘back’ button being broke.” Well, then Ajax might not be what you need for that particular instance. I’ve used several services online where the back button is useless or not even needed.

“You can’t use Ajax for …” Sure. I’ve never expected the Ajax approach to solve every problem. I’m a heavy Perl programmer. I don’t expect to solve every problem with Perl.

“The acronym Ajax is incorrect.” Whatever. It’s just a coined term. There are numerous acronyms and names that aren’t exactly correct. When I talk to people that understand what Ajax is, they also understand that you don’t have to use XML, etc.

I’m a technology whore. When a new technology comes out, I like trying to play around with it. I’ll play around with Ajax and see if I like it. If I don’t, then I won’t use it. I don’t need someone telling me, “It breaks your back button.” I say, “Really? Not the way I program it.” I think some people are trying to use it to replace something that’s not broken. I’m not going to go and try to re-write all of my webapps to use the Ajax method. They already work like they’re supposed to. If I do re-write some, it’s just to play around and see if it works.

Ritesh wrote:

hello all,
i was wondering, is there any wawy in which AJAX can be modelled in sucha way that periodically the server sends responses, but the client doesnt request for it , like a page update or something. it more like TCP/IP based programming, if so how can it be achieved . plz help

mark wrote:

polsih user forum:,28,pl,0,0,forum_list.html

Ak sessible wrote:

I write in the public sector and everything we do must be accessible, where possible to all users. Fine Firefox1.5 can do accessible DHTML but IE still has a huge market share which isn’t really going to shift much. In fact in the UK we have the Disability Discrimination Act which means by law sites should be accessible as well by 10% of the population with some form of disability. Shut your eyes and try using your ‘cool’ Ajax site?. Try using the tab key to navigate through it.

If Ajax is used to develop applications rather than for enhancing content then the search engine issue isn’t really a problem.
I think Ajax would be good for validating Forms on the fly as that can be a pain in ASP/PHP.
Designers/developers should be aware of this need and not get carried away with using Ajax, just because its been hyped and its this years flavour. Perhaps next year we’ll have ‘website duck’ or ‘domestos’
Finally Frames!!Yuk!!!

Cibermox wrote:

Im already developing an application with ajax, its one of the coolest techs I ever try. Its simple, elegant and you dont have to learn nothing new.
I been fooling around with .Net and Java, but Ajax + PHP makes the work easier, cleaner, and costless (since they are free, and uses less hardware).
Just try sarissa.js library.
Your clients will prise your name when they see what ajax its cappable of. For me, its the best choice for intranet app. (and better if you already have some xml sources working).

Kai Zhou wrote:

Announce in advance i’m yet a new guy who want to learn something like web application development, but I agree to Seth Steben and Mark Birbeck.

Why don’t we pay attention to XFORM, which could be an important standard for RIC.

My suggestion is to use XFORM and build it on Javascript and AJAX currently. Then we can migrate our XFORM application to other platform at a low cost in the future when AJAX and Javascript are kicked out.

I found ‘formfaces’ and ‘osp 3.0′, which you can seach from google.

anon wrote:

A new type of reusable Ajax GUI Classes for JSP developers, which can be used as one uses GUI-API classes in Java/Swing:

Sam Jones wrote:

I have been using the technology in AJAX for 6 years. It was interesting to me to hear about AJAX, as if were something new, and when I find out, that’s what I’ve been doing in my apps since 2006. It has it’s place and is very useful. I think anyone who talks about the browser history problems, back button issues, content not indexable by Google… does really understand how to implement what is now called AJAX.

Some reasons for using the technology, that are better than a roundtrip post include,
returning search results and returning database queries. If the data is in a database and the page is generated dynamically anyway, through regular asp or database objects, it’s not physically on the web page anyway, and Google doesn’t index that. The idea behind AJAX is porting information into/out of the page with minimal user distraction.

I have the technology throughout my survey program, at Give it a try.

JohnReed wrote:

Alex Russell have recently written about COMET, the next stage of Ajax. Its the intresting to know the facts about COMET in coming future…

COMET - the next stage of AJAX

Wayne wrote:

What’s the benefit in using xml over something else which uses a lot less data to transfer such as a pipe delimetered string? I have always thought that for something like this xml is a lot of overhead in tags to transfer to the client.

rohit wrote:

I think Ajax would be good for validating Forms on the fly as that can be a pain in ASP/PHP.

Loneli Raider wrote:

Ajax… no way. The surviving strategies are always simple and cross-browser, with for example Safari, some sites with Ajax are just blank pages. This is no web designing, this is wannabe-technology based on some spesifications, which do not apply in some cases and thus are something to merely forgot than remember.

I did teach e.g Javascript for years, and said never base only on Javascript, because there is a possibility an user has not Javascript enabled. Good hype, but within years we’ve seen this kind of things before.

Ajax wrote:

Have a look at Ajax Projects, it includes all the ajax frameworks

Lori Haynes wrote:

I installed igoogle and I HATE it!! How do I get of the crap?

Leave a Reply

OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?