AJAX: Making Developers Lives Harder Since 1998

If two web apps did the same thing, but only one of those apps had neat AJAX features, which would you choose?  I’d choose the one with the neat AJAX features.  AJAX has now become one of those small features that will make people choose one thing over another. 

Since I think this, I’ve decided to get some AJAX into #Portal.  Before yesterday, I’ve generally understood how AJAX worked, but have never tried implementing something which used it.  Oh  and one more thing, the “J” in AJAX stands for JavaScript, and JavaScript is something I usually try to avoid (for lack of experience).

The next version of #Portal will be written with .NET 2.0, and I’m working on it in Visual Studio 2005 (Beta 2).  Since one of the new features in ASP.NET 2.0 is “client callbacks” – basically AJAX – I started to use it.  To use the Client Callbacks, your page must impliment the System.Web.UI.ICallbackEventHandler interface, which has contains one method: public string RaiseCallbackEvent(string eventArgument).  Wait a second, one parameter?  just eventArgument?!  While this might be fine for one or two different callbacks, this starts getting tricky when I have many different ones.  Can a user control use a client callback? Will this work with the CommunityServer Forums type of skinning?  Implementing Client Callbacks doesn’t end with C# code.  You need to write JavaScript to actually connect the callbacks to the page, and the page to the callbacks.  AJAX just got a lot harder. My exploration with callbacks left me with more answers then questions about AJAX.  I decided that maybe there was a better way to do this, and went to check out the popular AJAX.NET library.

My first impression of AJAX.NET, was that it was more keen to what I was looking for then ASP.NET 2.0 Client Callbacks. To use AJAX.NET (besides referencing the assembly), you need to add one HttpHandler to the web.config file, put one line of code in Page_Load, and give the [Ajax.AjaxMethod()] attribute to whichever methods you wanted to use AJAX with.  Right off the bat, this works a lot better.  Instead of funneling an entire page worth of AJAX calls into one method, I can write many methods.   But, I still need to write JavaScript to glue my page to the callbacks. 

Again, I do not have a strong background in JavaScript.  Since JavaScript uses similar C#/Java syntax, I can get by – but not without lots of docs .  When I was learning C# (way back: pre-.NET 1.0), I often used Visual Studio’s great debugging experience to pause execution and check out what was going on with variables, and to step through my code to understand how it all worked.  After a quick google search, I was happy to find that Visual Studio supported JavaScript debugging!  After putting a breakpoint onto my page, I was horribly disappointed to see the VS2005 JavaScript debugging “experience” (well, it was more like a lack-of-experience”).  My breakpoint didn’t even fire!  After putting a “break;’ statement in the function, VS2005 detected a break, but didn’t even show me which line "break"ed.  I couldn’t get any values from any current variables, and I couldn’t trace my code.  This, for lack of a better term, sucks.

My JavaScript issues aside, there is one thing that totally irks me about ASP.NET with AJAX.  One of ASP.NET’s most unique and useful features is it’s use of Controls.  Instead of writing a anchor tag to link something, I could use a HyperLink control, which would render the HTML for me.  More importantly, it created a very useful structure to a page, and abstracted the html allowing people to write .NET code which rendered HTML automatically.

AJAX is almost totally done with JavaScript.  It uses the standard page DOM, which might have similar concepts to the ASP.NET page, but ends up being totally foreign. My AJAX methods can’t return controls back to the page (to insert or remove), but they can only return primitive types (plus a few others, like DataSet).  In other words, if I want to insert a textbox somewhere on the page with an AJAX call, I need to return the HTML of the control (using the <input> tag).  This is totally disconnected from any ASP.NET concept, and makes things an order of magnitude more complex.

So, what needs to happen? 

• We need to figure out a more ASP.NET style to handle AJAX requests and responses.  I’m talking about on the client side, and not in my .NET code.
• JavaScript debugging needs to get a whole lot darn better in Visual Studio.
• Everyone needs to go buy a decent JavaScript Book

I’m confident that one day I’ll be able to return an ASP.NET control through an AJAX method, and it will be automatically (and properly) taken care of so I can just push it into the page without any thinking (something I hope the AJAX.NET project is working on).  I’m also confident that the JavaScript debugging support will get better in Visual Studio.  Oh, and I’m also confident that Amazon.com will sell at least one JavaScript book today .