Yet Another Ajax Blog
For anyone who wants to understand Ajax or how I am approaching it, start here.
I’ve never liked sending an entire page of web form data to a server. It seems clunky compared to most other user interfaces we use that do field-level processing. Anyone who has worked with an IBM 3270 terminal knows that this is more of a blast from the past than modern technology at work. So back around the year 2000 I "invented" a method of getting web pages to provide immediate feedback without screen refreshes. It used JavaScript to cause a hidden frame to execute an HTTP request. When the request came back the OnLoad event would execute a callback in the visible frame, and controls would be updated without a flicker. The thing that was neat about this is that it didn’t use Java (still considered web form taboo to most people) and didn’t use ActiveX controls which were specific to Microsoft Internet Explorer. The technique was completely cross-browser compatible using code that anyone could work with. I did presentations for audiences of people who had never seen such a thing, and they loved it. At the time many other web developers were looking for such a golden function. It turns out that many people "invented" similar techniques independently of one-another. It was a solution whose time had come, but for many it was a solution in search of a problem, so it didn’t really catch on.
Surprisingly the demand for such a "solution" didn’t really come about until 2005 when Ajax came on the scene. The real kicker seemed to be when Google started using it. Prior to this most end-users were quite comfortable with page-at-a-time forms submission and full page refreshes. If you ask most people, that’s just the way the net works. But when Ajax came around, all of a sudden people realized they had a problem that needed to be solved. This newfound problem and solution quickly became so much a part of the end-user consciousness (or at least business people charged with creating applications for end-users) that now most of my clients say they want it for new development. This is really funny because I’ve been asking people if they want something like this for years and never got a single request. Now I’m faced with the problem that most clients don’t want me to even start development on their projects unless Ajax-style functionality is present right from design. For those clients on the fence, I’m faced with the issue of starting a project without Ajax only to have them read up on it later and ask me why it’s not in there – then I’m faced with a re-write, but at whose expense?
AJAX if used as an acronym stands for "Asynchronous JavaScript And XML". The original implementations used an XmlHttpRequest component that has been around for a few years. Many websites use it, but AJAX wasn’t a buzzword until the term was coined in 2005. The phenomenon is sort of like Design Patterns. People didn’t know they were using some common pattern until the Gang Of Four wrote a book on it. Now there are developers who want to apply patterns to every facet of their coding, whether they need it or not. Because XmlHttpRequest is Microsoft technology and only available for Internet Explorer, most end-users don’t want it in their applications (at least this is what I hear in my community) – there’s that "what if my users want to use browser X"? question. But now with the AJAX revolution as a more conceptual model (independent of any specific components for implementation), most browsers now support the functionality.
As you’ll see as we go, AJAX is used often as an acronym, but the more savvy will refer to it simply as Ajax, calling it neither a technology nor an acroynym, but just a way of doing things.