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 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 all 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 it 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 for this post) to find good uses for AJAX in a Web Shopping Cart solution. The goal of the contest or as Tim called it – a BlogConversation - 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 lots of discussion, there was actually very little in the way of useful suggestions. I was interested in this contest for a variety of reasons. One is that I too have a Shopping Cart tool, and well, riding Tim’s coat-tails 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’s inviting 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 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 your self, “Yeah, this is really useful and a good fit for 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’ve been following 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?
So as primary technology, 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).
Is AJAX really a better solution?
Take a look at the suggestions that are coming in for Tim’s query. I find 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 relative 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 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 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.
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.
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 to manage these 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 page content to the server on every request and basically update the entire page firing a good chunk of the 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 (say a PK for a record to display).
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 bullet points above are related AJAX’s newness and the fact that everybody’s currently trying to figure out how to find standardized patterns and approaches. The tools are experimental mostly trying to find the sweet spot and in the .NET space there are several AJAX libraries available, each of which takes a slightly different approach. I’ve played with Michael Schwarz’s AJAX.NET and Jason Diamonds My Ajax.NET and Script Callbacks in ASP.NET 2.0 as well as a custom wwHoverPanel 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 manage retrieving content from ‘external’ Urls. The combination of the libraries provides good functionality, but the approaches are currently 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 is addressing some of the tough issues like providing better client side script debugging and consolidation of AJAX access models.
More importantly though, we as developers need to think of ways that this technology really fits. And this is really what Tim’s contest is about. I’ve been checking over there every few days to see what’s being discussed because I am curious. I guess I don’t have enough imagination to come up with my own scenarios.
While I can think of a few scenarios that would be cool:
- Shipping calculations and update of carts
- Sorters for Admin pages: Items, Specials, Categories etc. 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 Shop 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.