AJAX is the hot topic in Web development at the moment, and there’s a lot of discussion going around about how to best implement this technology in real-world applications. AJAX stands for Asynchronous JavaScript And XML and it’s basically another term for remote scripting or the ability for browser client code to call server-side code directly without reposting the entire page back to the server. Rather, client-side code can pull down little chunks of data and update the content in the HTML document using the HTML DOM. In concept, the model is similar to the way you work in desktop applications where you have a stateful client interface that asks for data and then moves the data into the UI. You can contrast this with standard Web applications where typically all business logic and UI creation is managed on the server and the client browser serves merely as a terminal to render the content. AJAX changes this model to include the client as an active part of the application.

The technology used in AJAX - little more than a standardized HTTP client model - is really nothing new. Internet Explorer has supported AJAX-like functionality since IE 5 back in 1998 and I remember at the time being very excited about the technology only to have it all fizzle because it was IE-specific. Now, 6+ years later, other browsers have picked up on IE’s XmlHttp model and many browsers including Mozilla/FireFox, Opera, Safari, and Netscape all include support for XmlHttp in a standardized way, which finally pushes this technology into the Web development mainstream. Incidentally despite the X in the AJAX name, XML is actually not used by most AJAX implementations. XML use is optional.

AJAX is hot and people are falling all over themselves to be associated with it. As happens so often in this business, some new technological feature (in this case not even new) gets hyped way out of proportion and the press goes wild. Oh, and the trendy developers and IT guys go right along with all of it… But as is often the case with hyped up technology, the technology is desperately trying to find its place to live up to the hype. The potential is there, but looking around at samples and discussions of the technology you quickly find out that the samples often are contrived and trivial and don’t really provide functionality that goes beyond what’s possible with standard Web applications. Yet we’ve all seen the magic of Google Maps, GMail, Google Suggest etc., or Microsoft’s Outlook Web Access, all of which have been part of the reason why AJAX technology is seeing this newfound attention recently. While Google is making the most of the technology, finding innovative uses for AJAX turns out to be more complex than you might think.

Along these lines, Tim Haines recently ran a contest (which incidentally I ended up winning - http://ims.co.nz/blog/archive/2005/08/02/897.aspx) to find good uses for AJAX in a Web shopping cart solution. The goal of the contest, or as Tim called it - a blog conversation or “Blogversation” - wasn’t necessarily to find the best solutions but generate interest and ideas on how to integrate AJAX into existing applications. What’s interesting is that at the end of the contest, while there was a lot of discussion, there was actually very little in the way of useful implementation suggestions. I was interested in this contest for a variety of reasons. One is that I have a shopping cart tool that I sell, and well, riding Tim’s coattails and getting ideas would be a great way to get some new ideas. But alas, there weren’t a whole lot of them coming.

All that said, I feel that AJAX is a technology that definitely has the potential to change the way we’re building applications. But as Tim Haines is finding out himself - and why’s he invited this discussion - it’s not quite so trivial to apply the technology effectively. Sure it’s easy to create some flashy thing like popup windows (http://www.west-wind.com/wwstore/ItemList.aspx) and some simple updates of page content. But to truly take advantage of this technology really requires rethinking about how you build applications.

Aside from the obvious examples of the various Google implementations and Outlook Web Access, etc., have you really seen the technology applied in ways where you might think to yourself, “Yeah, this is really useful and a good fit for a typical business application.” I’ve looked at a lot of demos and most of this stuff is just trivial and has the look of, “Hey, look what I can do!” I’ll admit that I’ve created some of these same simple samples as I’ve tried to understand the concepts and provide the technological context.

This is one of the reasons I followed Tim’s contest with interest. But at the same time, I think there are a number of questions that need to be asked.

Is this a Primary Technology?

There are many issues and levels involved in AJAX. First and foremost, I think for the moment it’s not quite ready for use as a primary technology. There are too many old browsers out there for one thing. XmlHttp is relatively new for Mozilla-style browsers and Opera is just now getting XmlHttp. Older browsers are going to be left out. In addition, AJAX relies on JavaScript and if the user has that turned off they are also locked out. In Internet Explorer, the XmlHttp object is an ActiveX object which is probably more serious because many IT departments lock out ActiveX usage on browsers completely.

So do you really want to bet that your customers have support for this technology? I don’t think so. If you work on a Web development shop, you DON’T want to force anything on your customers. Your goal as a business is not to dazzle your customers with your Web development expertise, but to provide a service (in this case sell them your stuff).

Incidentally the whole “no-JavaScript” issue is interesting to consider - have you ever tried to run an ASP.NET application with scripting completely turned off? If not, try it out some time. To try this, turn off Active Scripting in IE and see what happens to your ASP.NET application. It’s not a pretty picture. You’ll get security warnings on every page that does an ASP.NET event postback.

Mind you I understand the issue, but it’s still scary to think that a simple configuration setting can basically jinx your entire fancy application.

Is AJAX Really a Better Solution?

As I looked at the suggestions that came in for Tim’s query, I found that a lot of the so-called improvements are pretty minor usability enhancements. Most of them center on avoiding ‘bothersome’ postbacks and flashing. I don’t know about your applications, but most applications that I write tend to be pretty quick over even a relatively low bandwidth wireless connection. To me, postback speed is not a huge issue. I also try to use old school efficiency in my applications so I don’t do everything the ASP.NET brute force way (which often results in humongous pages with ViewState out of control). Yup, believe it or not, using traditional Web application development constructs like plain links and non-ViewStated grids actually results in better responding applications than all the crap ASP.NET often piles on by default.

AJAX provides the ability to provide in-context updates and, more importantly, AJAX allows for in-context information lookups. I could envision AJAX-style popups to help with lookup lists that pop up under a textbox, for example, or provide in-context help at the mouse cursor. Popping up information on top of the current page and allowing a quick selection of information is one of the simple things you can do with AJAX that provides instant gratification as well as potentially improving the usability of your applications.

My point here is that you should look very, very closely at what your application is doing and see if you can’t create a plain Web application that actually does what you need to before jumping on the AJAX bandwagon. There’s a lot of Just because I can going right now. I’m guilty of that as well. If you look at my store (http://www.west-wind.com/wwstore/ItemList.aspx) you see a few of those self-gratifying HTML popups (which I think are useful, but I can see how some people would consider it annoying). AJAX offers more stuff in the Admin interface, which is where AJAX really starts making more sense. The point is that you need to have a good reason to use the technology!

Beware of Bad AJAX Design

Grafting AJAX onto existing applications adds another layer of complexity to your application. And in a lot of situations it will duplicate functionality that already exists. AJAX inherently does things differently than a postback application. And with the various .NET AJAX frameworks you’ll end up either working that logic into the existing page (script callbacks, My Ajax.NET) or in external handlers (Ajax.NET) or something like my own wwHoverPanel class.

If you embed your logic into the current page using either script callbacks or Jason Diamond’s My Ajax.NET (http://jason.diamond.name/weblog/2005/07/06/my-ajax-dot-net-library) you are really creating two separate UI contexts in a single page, which is not a good thing at all. You’re feeding the main page HTML as well as the HTTP responses for the AJAX requests from this page, and in many cases the output your sending to the client may be HTML. So you’re actually generating two separate HTML responses in the context of a single page. From a design perspective this can lead to some very ugly ASPX code behind code and monstrous pages if you end up handling a number of AJAX callbacks on a page.

I can see that we might be heading that way. Can you imagine trying to build SDI simulating pages in ASPX pages and JavaScript code? Ugh! Think of a Windows desktop application you might have built in the past where one big main page manages the entire application. Now imagine that you’ll use AJAX to do the same thing. Ouch, that’s going to hurt! But people will try…

Also keep in mind that the client code gets large very quickly. A few days ago I built an AJAX Specials Sorter (http://www.west-wind.com/webstoresandbox/admin/SpecialsManager.aspx) for my Web store as an exercise of AJAX technology. It’s used to organize the specials that display on the home page. It’s non-generic code, and while it worked nicely, it ended up being quite a project to get everything to work properly in this interface. If you look at the page, you’ll see a ton of client-script code. Some of it is auto-generated by the AJAX library I used (Jason Diamond’s My Ajax.NET), but most of it is hand coded JavaScript. A lot of it! By comparison, the server-side code is a mere three methods. So essentially by using AJAX I’ve shifted most of the user interface logic to the client where it’s much harder to debug the code and where I have to deal with browser compatibility issues. Yes, the functionality is ‘slicker’ than a pure Web Interface would have been, with more live feel and considerably less data passed, but is it worth the extra pain of development using JavaScript code?

Lack of a True Rich Client UI

No matter how hard we might try to pretend we’re dealing with a rich client in HTML, we’re not. Yes it’s possible to build really rich client applications with HTML, but it takes serious skill and experience to be able to build truly exceptional UIs in HTML. Heck, even mediocre HTML interfaces are hard to build if they are to be cross-browser compatible.

The native HTML controls suck. I mean, look at the inconsistency of the DOM model and the limited functionality that the native controls provide. The workaround is to build fancy HTML hacks that simulate rich Windows interface controls.

It might be a different story if the HTML model was rich enough to support rich user interface controls natively. We’d all love to see rich user controls for ListViews, TreeViews, menus, status bars, etc., along with consistent browser support, but this is a dream we’ll probably never see happen. The Web has been around for a long while now and there are really no efforts being made to provide a unified rich user interface model. I’m not holding my breath.

Many people want to simulate a rich GUI. If that’s the case, why not just build a Windows GUI application with WinForms and Web deploy that UI? Yeah, it requires .NET, but if you build an app that is compelling enough people will want it anyway. For example, if Microsoft had built Outlook Web Access as a WinForm instead of an IE-based browser interface, do you think people would have put up with downloading the .NET Framework? I bet they would. OWA is a fancy piece of AJAX work before AJAX was fashionable, as is Gmail and all the other Google stuff. But how many of you (or me) are really able to pull off that kind of UI wizardry in HTML? I’d say there are maybe a few thousand people total out there that have the skill to build UIs like that. Are they going to be working on your team? Probably not… and even if you can get a hold of one of them can you afford the time it takes to do this? As it is, even simple JavaScript code takes 4-5 times longer to develop than it does to write server-side code when you consider the lack of debugging tools and the issue of browser incompatibilities.

If you really are after a rich interface - especially a Windows-like interface - a Windows application is a possible alternative. And it doesn’t have to be .NET either. It can be a JAVA desktop application, or a Visual FoxPro desktop application, or a VB6 application. If you build it mainly as a UI application with your data coming from the Web, your dependencies are minimal and updating applications is trivial (C’mon now - auto-update functionality is easy to create!)

For internal applications, think about it: Wouldn’t a thin yet rich client application make more sense? It would be a lot easier to build a compelling user interface that way rather than hacking crappy HTML controls and browser incompatibilities. You can use Web services with a formal contract, or something simpler that serves XML or raw data directly from ASPX pages or HTTP handlers. Think of the flexibility you can have with a rich WinForm environment.

I know what you’re going to say - “Yeah, but it’s Windows or Mac or Linux, and it’s just not cool to build for a specific desktop.” But is that really an issue for your organization? Cross platform is a lot less of an issue than some people want to make you believe. Also, consider that if you add an AJAX interface to your Web application you’re also building multiple interfaces - instead of different platforms you build two interfaces for AJAX-capable and non-AJAX-capable browsers.

It’s something to consider, especially with some of the improvements that are coming in .NET 2.0 for deploying applications from the Web using ClickOnce. This starts making a lot of sense when you think about a desktop application as a UI container only that can communicate with data coming from the Web.

Even given the potential benefits, I know that this is a tough sell though. I would have thought that HTML by now would be a whole lot less prevalent with more applications moving back to the desktop with Web services or other remote connectivity that can harness all the power of Web applications without the limiting HTML interface. But it hasn’t happened and is still considered an outlandish concept.

AJAX and the Web Business Model

Another thing you need to consider is that like Web services, the AJAX technology challenges the Web business model, especially for big sites. Web sites big and small are making money selling advertising space. (Actually I think nobody makes money with that except Google - people just keep spreading their ad revenue around until they finally pay it back to one of the big guys like Google.) Big advertisers want frequent postbacks to provide the needed page churn to display new advertising frequently.

Hmmm… I guess ads have to become AJAX ad rotators <g>. Now there’s an AJAX application waiting to be written if somebody hasn’t already done it.

AJAX is similar in this respect to Web services. We’ve not seen huge acceptance of Web services as public implementation because it’s very hard to brand content that is consumed directly rather than being dumped into an HTML page. AJAX is a little different in that usually the content is internally used rather than external facing like a Web service. But still there’s the whole of issue of a more static user interface.

Ajax and the Network

You should also consider what impact AJAX has on your application’s scalability. AJAX tends to increase the number of requests on a back end application considerably. This may be a good or bad thing. You might consider this good because it might help you break complex logic into smaller atomic chunks. So rather than filling all the data in one slow long running request you might fill each of those data items individually with separate AJAX callbacks. Atomic usually means better scalability as it allows more requests to run simultaneously.

But it can also be bad if you have lots and lots of requests that get generated. Even the relatively simple samples I posted can take four requests against a backend to load the page. And two more requests per additional selections in many cases. Using AJAX, your application will be a lot more chatty with many more trips back to the server rather than having a static page on the client that gets posted back all at once. If your requests are inefficient this can quickly kill your application’s performance and scalability. You have to be aware of what’s going on. And some tools that manage AJAX requests are more efficient than others. For example, Script Callbacks in ASP.NET 2.0 are pretty heavy in that they post back all the POST content of the page to the server on every request and update the entire page, firing a good chunk of the full ASP.NET page pipeline. While this may be very useful for easily maintaining page state, it’s also a lot of overhead to deal with if all you’re doing is generating a generic chunk of HTML that needs a single context parameter like a PK on the server.

Ajax has Potential, but It’s Still Growing Up

Although I’ve made devil’s advocate points here, I do believe that this technology has enormous potential to change the way we build Web Applications. We can hope that the influx of this script-heavy technology will encourage browser standards to take a step towards providing richer user interfaces that would make this technology much more useful.

A lot of the points I’ve stressed above are related to AJAX’s newness and the fact that everybody’s currently trying to figure out how to find standardized patterns and approaches. In the .NET space there are several AJAX libraries available. I’ve played with Michael Schwarz’s AJAX.NET (http://ajax.schwarz-interactive.de/csharpsample/default.aspx) and Jason Diamonds My Ajax.NET and script callbacks in ASP.NET 2.0 as well as a customer implementation. Out of these I prefer Jason’s library because of its simplicity and integration into the page pipeline. But it doesn’t serve all purposes: The most glaring problem (also with script callbacks) is that you have to make your AJAX calls back to the originating page. In that respect it’s impossible to access service-based data. For example, if you want to retrieve data from SqlXml or you have another page that could be feeding your client page HTML content it can’t be done. For this reason, I also use a custom control that manages retrieving content from external URLs. The combination of the libraries provides good functionality, but the approaches are not consistent.

Microsoft has had a disappointing start into the AJAX space with client script callbacks in ASP.NET 2.0, but they have announced plans for a much more comprehensive framework codenamed ATLAS, details of which will be unveiled at this year’s PDC in September. But ATLAS is likely some way off in the future and we can only hope that Microsoft will address some of the tough issues like providing better client-side script debugging and consolidation of AJAX access models.

More importantly though, as developers we need to think of ways to use this technology that really makes sense. And this is really what Tim’s contest is about. I checked his site every few days to see what was being discussed because I am curious. I guess I don’t have enough imagination to come up with my own scenarios.

I did think of a few scenarios that would be cool:

  • Shipping calculations and update of carts.
  • Sorters for Admin pages: Items, Specials, Categories etc., that all need a visual way to sort which is unintuitive to do with server-side-only code.
  • Data validation based on server-side settings. (Look up zip and state codes, for example, or perhaps verify a vendor ID or order code number that is in the database.)

My guess is you don’t think this list is very imaginative.

But maybe it’s just that a Web Store is not the most imaginative target for AJAX technology. I think the real kick for AJAX might be for scenarios like online gaming and other truly interactive tasks that we haven’t really thought of yet.

Rick Strahl