AJAX

Is AJAX really worth it?

Kyle — Thu, 01 Mar 2007 14:22:00 GMT

I was one of the ones who jumped on the AJAX bandwagon pretty quickly. I've built several private apps using AJAX, and really like it. I like the fact that the web becomes more "rich," and more closely resembles forms in functionality. The gains are enormous.

That having been said, I found myself asking the question: Is it worth it? I've found (so far) that doing things with AJAX takes at least three times longer, there's much more room for error, and cross-browser issues are brought to the forefront. I have played around with the AJAX.NET framework a little, and have had mixed results. What I got working was pretty cool, but do I really need rounded corners on divs? It seems to me that a lot of their controls are gimmick-ey, and don't really have all that much to do with AJAX.

I think my biggest disappointment with the MS AJAX.NET framework is it's complete failure when adding the framework to an existing project. I could not for the life of me get it to work. I spent three days fiddling with it, and nothing seemed to want to work. I really have little desire to re-write the projects that I do have for the benefit of AJAX.

So, is it all worth it? Are post-backs really that evil? I'm starting to think "No." AJAX is cool. I probably won't use it if I'm in a hurry. It has its place, but is it ready to take over the web? Should it?

Those are my questions...

Sweet AJAX Travel Site

Kyle — Tue, 07 Nov 2006 13:03:00 GMT

Just ran across this travel site that I'd not heard of before.

www.kayak.com

It's got some sweet AJAX action going on.

New to Ajax? Read this...

Kyle — Sat, 11 Mar 2006 07:25:00 GMT

Recently, I've run across several posts over at the AJAX.NET Google Group asking about how you can bind a DataGrid, or a Repeater using AJAX.

The answer is, you can't.

DataGrids and Repeaters are Server Side controls. Their life begins and ends on the server, when the page is rendered to the client. The client is rendered to HTML, and sent to the client. That's it. Finito. The End. That's all she wrote. From there on out, it's all the client.

Any AJAX transactions that take place must be rendered on the client using JavaScript. It's that simple. Server Controls are for the server. Asynchronous JAVASCRIPT and XML. No mention of server controls in the name. So, if you bring back a collection of Data from the server, you need to parse through that data with JavaScript, and create your HTML manually. No way around it. (Well, there is, but it can severely limit functionality).

The other issue is Page Context. You don't get one when you're doing an AJAX call on the server. It's an HTTP Request. No page context. With the AJAX.NET library, you get the session and cookies, etc, but the page doesn't exist. No way around that. Even if you could get the page context, it's only valid when the script is running on the server. You can't re-bind data to an existing datagrid.

So, Server Controls are for the Server. Any work done with AJAX is Client Side.

Ajax.NET and DataBound Server Controls

Kyle — Wed, 22 Feb 2006 14:28:00 GMT

Over on the AjaxPro Google Group, a user asked a question about databinding a repeater using Ajax. The response has always been "A repeater (or any other server control) is rendered on the server, and then passed back to the client as HTML." One of the purposes of Ajax is to reduce the amount of bytes being sent back and forth between server and client on non-initial load functions.

In this post, the usual answers were given. Loop through the dataset with JavaScript, then display the results. This makes sense to me.

Then I got thinking. For those who don't want the hassle of looping through datasets to build tables, but are more comfortable with server side databinding, there is a way...

***SERVER SIDE***

<AjaxPro.AjaxMethod()> _
    Public Function getDG() As String

        Dim ds As New DataSet
        'Fill the DS however you want...

        Dim DataGrid1 As New DataGrid
        DataGrid1.DataSource = ds
        DataGrid1.DataBind()

        Dim SB As New System.Text.StringBuilder
        Dim SW As New System.io.StringWriter(SB)
        Dim htmlTW As New HtmlTextWriter(SW)

        DataGrid1.RenderControl(htmlTW)

        Return SB.ToString

    End Function

***CLIENT SIDE***

<div id="DataGrid1"></div>
<a href="javascript:void(0);" onclick="test();">Here</a>
<script>
    function test()
        {
        ServerSideRenderControl.WebForm1.getDG(getDGCallback);
        }
    function getDGCallback(res)
        {
        document.getElementById("DataGrid1").innerHTML = res.value;
        }
</script>

This method (though large) allows you to databind a data-aware control on the server side, and then pass it out to the client through Ajax. I haven't dealt with server-side templates (for repeaters)... You're on your own for that. Enjoy!

First AJAX.Net Project Deployed

Kyle — Sun, 11 Dec 2005 04:31:00 GMT

Well, I deployed my first AJAX.NET project today. It's a private (local) project for a client.

I like the benefits of AJAX technology, but there are a few quirks that should be dealt with.

For instance, session time-outs. If you use any kind of session based authentication system, a time-out may occur if the page is not refreshed within the session time-out limit. Back-Button issues (as some have pointed out) are less of a big deal in this project.

Ajax String Building - Which is better?

Kyle — Fri, 09 Dec 2005 20:09:00 GMT

Which is better?

This:

<AjaxMethod()> _
Public Function GetString() as String
   return "The String"
End Function

<Script>
  function getTheStringCallback(res) {
    document.write("<table><tr><td>" + res.value + "</td></tr></table>");
    }
</Script>

Or This:

<AjaxMethod()> _
Public Function GetString() as String
Return "

The String

"
End Function

<SCRIPT>
  function getTheStringCallback(res) {
    document.write(res.value);
      }
</SCRIPT>

When writing AJAX code, do you build the output JavaScript side, or Server Side? I prefer Server Side. (I'm more familiar with VB than JS). Maybe I'm just lazy.

AJAX.NET Pro and Date Types...

Kyle — Mon, 28 Nov 2005 21:15:00 GMT

This...

<AjaxPro.AjaxMethod()> _
Public Function GetTheDate(ByVal TheDate as DateTime) as String
Return TheDate.ToShortDateString
End Function

Does not work.

But, this...

<AjaxPro.AjaxMethod()> _
Public Function GetTheDate(ByVal TheDate as String) as String
Return cDate(TheDate).toShortDateString
End Function

Does. Apparently, any type conversions involving dates need to be done inside the function, rather than passed through the function.

The Psychology of Ajax

Kyle Holder — Fri, 04 Nov 2005 13:49:00 GMT

The Psychology of AJAX

If you’ve been poking around the .NET blogs long enough, you’ve seen the word AJAX, perhaps even visited Michael Schwarz’s website, maybe even downloaded his AJAX.Net assembly and poked around in it. I know I have. I see the value in AJAX, and that’s not what this post is about.

I want to ask the audience some questions regarding the psychology of AJAX.

The thing that got me interested in AJAX was a post about the way Sam Goody was incorporating it into their shopping cart system. (Sorry, I can’t find the link now). Using AJAX, a user clicks an “Add to cart” link. Immediately after the click, the image is replaced with an “Updating” message, and after about ½ of a second, an “In Cart” image appears.

As we all know, our computers (particularly our servers) are very fast. It probably doesn’t take about .5 seconds to perform the appropriate action on the server. This “wait” period can be accomplished by putting a system.threading.thread.currentthread.sleep(500) in the AJAX method on the server side, or of course by pausing the execution of the JavaScript. Personally, I prefer just having the server sleep for 500 milliseconds.

So, this isn’t an issue technically. My questions come from a User Experience angle.

Question: We’re all used to waiting for pages (even on a high speed connection). Does the fact that AJAX allows seemingly immediate results affect the user experience negatively? For example, Sam Goody could have done a round trip on their site, and the user would have expected to wait for it. So, when things happen immediately, are they inclined to think something might be wrong? Does the appearance of the server doing “something” (even though it’s “sleeping”) enhance the user experience to the point where that ½ of a second is a significant gain?

Any thoughts?