Check this out: Google Suggest[^]  <-- My new home page

I was reading this article[^] by Jesse James Garrett (actually, I read the first 3 paragraphs and made a mad dash to my soapbox, aka: my blog) where he mentioned the Google Suggest link as an example of how the web is becoming more user friendly, and as rich as many Win32 applications. First things first, Google Suggest is freakin awesome. It's not a super revolutionary piece of code getting used there, but it strikes a cord deep within me.Not only will a brand like Google help make this technology common place in rich web applications, I created a control[^] that utilized this same technology over a year ago.

Sit back for a moment and think about how standard web pages work. For example, a simple contact information form.

• Client requests a page.
• Server builds the page
• Server sends HTML to the client
• Client renders the page
• Client fills out all values in the form and clicks submit
• Client then sends data to the server
• Server processes the data
• Server builds a new page
• Server sends HTML to the client
• Client renders the page

Ok, get off the gas pedal Levi. Go back and read the rest of the article

I'm not going to steal any of James' thunder, or his graphics, here. Go read his article[^] to get an uncannily close description of what I was starting to say, then come back.

.....

.....

I really like the name that the guys at Adaptive Path have created fits very well in my opinion, and I think I'll be adopt it as well. It sounds a lot better than “We have an application that use XMLHttp and the Document Object Model to make direct calls to the server, passing XML, executing server side code, and returning some XML back the client, parsing it with some XSLT, all without the user having any clue any of this was happening“

Ok, so where was I? Oh yeah, simplicity of what's going on here. It certainly sounds complex due to the number of different technologies being used to explain what is actually being done, but honestly, it's very simple. Client side code gathers some data and puts it into an XML document. We take that data, and pass it to the server just like we do in a postback. The server then reads it, runs your logic, and sends the client back the data you need. Then, if needed, the client then uses JavaScript to display the data on the page. If not, it does nothing.

 Back to the example I started above. Why does the web need to operate in this synchronous fashion? I think that James made some great points explaining that one reason the web works this way is due to the reason it was built in the first place, communication. What if you could do the following:

• Client requests a page.
• Server builds the page
• Server sends HTML to the client
• Client renders the page

From here, as the user was filling out each control in the form, with the addition of Ajax, we have many new options we didn't before. For example, user fills out the first name control. As soon as the user moves on to the next control, the client could, behind the scenes, send that data to the server to process. This could be done for every control in the form if that was desired. When the user gets to the last field and clicks Done, sure, posts will be made to the server to get them to the next page, however, the server would not have the load of processing the form first. That got done while the user was working.

Get it? User and Server are working at the same time, asynchronously.

If I'm a dialup user, this is outstanding! I get a very rich interface, just like my broadband friends, over dialup. This is because the actual data being passed back and forth is relatively small. Afterall, all that is being sent is small pieces of data, not the entire HTML page.

A better example could be, say, a tax form. What if, as you were filling out the form, tax table values were filled out for you as you provided more information? Or better yet, help information. Sure, help information could be sent to the client on page load, and then made visible as you progressed through the form. The major downside of that is you've just increased the size of your page tremendously. Using Ajax, your form could appear to be 'smart' and collect the help information as you move through the form.

This type of functionality is common place in Win apps, but not in web applications due to the use of synchronous calls. If you wanted functionality like that in your run of the mill web page, you would have a user base that would be able to tell you the pixel count of an hour glass cursor in their sleep.

One argument against an Ajax type setup is that is does add complexity to a web application. At least it did for the applications I built 2 years ago based on the Ajax methodology. With that said, I have most certainly grown as a developer over the past 2 years, and I think it would be fairly straight forward to clean up the whole process into a very streamlined system.

When Jeff Brand[^] was in town a few weeks back, he made mention of some potential user controls in Visual Studio 2005 that may use this methodology. I have not done any research at all to back up what Jeff said, but would love to see some more information on what exactly these controls are going to do.