jQuery Ajax Beats ASP.NET Ajax

ASP.NET Ajax is a good technology in theory, but the implementation in practice is anything but smooth. There are many little ‘quirks’ that ASP.NET Ajax does to your page; these quirks almost entirely revolve around the handling of viewstate during ajax calls.

ASP.NET Ajax passes the viewstate to the server and back during things like UpdatePanel updates. This is done to insure that the viewstate is always up to date, even if the page information changes during the Ajax call. Many Ajax calls, however, don’t require any changes to viewstate. Unfortunately, when the viewstate comes back, I’ve found many unpredictable results – things like page titles changing and breaks in back-button functionality in some scenarios. More importantly, these bugs are hard to track down and understand, in my experience. On top of this, viewstate is usually pretty large, which slows down ASP.NET Ajax requests and transfers more data across the wire, increasing bandwidth costs.

What have I chosen to do instead? Through Encosia, I’ve found that it’s fairly trivial to make jQuery Ajax calls into the codebehind, or even to local web services via JSON. These calls are small (they don’t send viewstate), transparent (they don’t change page information on return unless you explicitly ask to), cross-browser compatible, and rock-solid (like everything in jQuery).

Surely there are quite a few circumstances where ASP.NET Ajax beats out jQuery Ajax (for things like datagrid population, for example). From now on, though, I’ve decided that my default stance will be to write my Ajax calls in jQuery unless I can create a compelling case to do so in another technology.

The Asp.Net Site Has a Problem

Have you been to http://www.asp.net lately? I have no idea why, but it’s slowing my browser to a crawl for a period of 5-10 seconds just after the DOM renders. I’ve tried across several machines, and it’s really annoying, especially since it happens on every page load instead of just once. I think it’s the Silverlight check that’s causing the issues. Regardless of the issue, if you’re going to make a site to evangelize a product you created (and that’s written on the platform that your site is promoting), it probably shouldn’t suck.

jQuery and Visual Studio

Did you get the chance to read that Visual Studio will be shipping with jQuery support included in the future? This news just made my day, more or less. If you aren’t in the know, jQuery is a really well developed JavaScript framework library. It includes support for things like making AJAX requests, easy DOM manipulation, and effects. There are a significant amount of controls written on top of jQuery that provide rich web experiences, and are as simple to use as integrating a plugin and adding markup to your HTML. The best part is that the use of a JavaScript framework has huge beneficial aspects on your cross-browser capabilities – all the framework methods are more or less guaranteed to work on everything from IE6 to Chrome!

Visual Studio ships with ASP.NET AJAX, which is kind of like the Microsoft bastardized attempt at a JavaScript framework. It’s been lagging behind jQuery and most other modern JavaScript frameworks since it’s introduction. Now, with full jQuery support, including intellisense, there’s little reason to have to use ASP.NET AJAX, in my opinion.

The one unfortunate aspect of official jQuery support in Visual Studio is that there are a lot of other competing frameworks, many of which are on par with jQuery, but whose market share will inevitably erode. Either way, a choice had to be made in this regard, and the right one was, in my opinion.

JavaScript can provide such a rich user experience nowadays that it rivals Flash/Air and Silverlight in many areas. It’s also getting faster (on a daily basis, seemingly), which bodes well for it’s future. If you haven’t checked out jQuery up to this point, it’s well worth a minute of your time.

New Starts, Safe Finishes

So, the blaq design weekend at Snowshoe was a wonderful time out. If you haven’t gotten a chance to get out there for a few days of mountain biking, it’s definitely worth the experience. Unfortunately, I was totally afraid of breaking my camera so I didn’t take it out on the trails, but I got a few beautiful snapshots of the resort, which you can check out here.

On to other things – I started a new job last week. I’m finally a full-time web developer, working on ASP.NET 3.0 to boot! I’m now working in downtown Cleveland, which is a big change in both a location and a drive, but it’s looking like this is a great opportunity to learn some cool stuff and to have a different experience in life. Of course, it’s a big change to my life – I had to join a new gym, and I had to get a new car (VW GTI, more on that later, hehe).

One last thing, to end on a funny note. Since we took our Snowshoe vacation on my week between jobs, I apparently didn’t have health insurance! Luckily no serious damage was done – just a few bruises and scratches. If I’d have ended up in the hospital, it would have cost a bit more than I had bargained for. Those downhill runs at Snowshoe are pretty insane in places, so coming home in one piece is certainly not a guaranteed thing.

Check out TinyMCE

If you’re a web developer who’s in charge of creating content management systems, there’s a great control you’ve got to check out – TinyMCE. TinyMCE is a free, open source WYSIWIG text editor. The beauty of it is that it’s feature-rich, it’s platform independent (being written entirely in JavaScript), and it’s extremely easy to configure and extend. It’s developed by Moxiecode, who also develops some very intriguing commercial controls. TinyMCE is actually the text editor that WordPress uses for their backend CMS (so, it’s what I’m writing this post on, by extension).

The great part is that TinyMCE is specifically designed as an XHTML markup editor, so the output of it can go straight into any web container without further down-the-line manipulation. Even better was a feature I was not at all expecting – you can style the text editor with a .css file and a css class definition too! This means that if you use your site’s stylesheet and it’s written well, you can get the TinyMCE editor window to effectively replicate what your site post will look like. Now, that’s a powerful feature!

Here’s an example of what I mean. This is a sample post from my other site, blaqdesign.com, in the content editor system that I’m writing for it. The great part was that these posts weren’t originally created in TinyMCE, but since they’re valid XHTML fragments, I was able to load them into TinyMCE with no hassles whatsoever. If you go to the site, you’ll see in this very post in the site news, and formatted exactly the same way. The background is the same, the text formatting and colors are perfect, and the XHTML markup is preserved. Now, I don’t have to worry that other people will make a mess of the site formatting when they’re creating content.

TinyMCE

If you’re interested, here’s my TinyMCE configuration I used:

<script>
tinyMCE.init({

mode : “textareas”,
theme : “advanced”,
theme_advanced_buttons1 :“bold,italic,underline,strikethrough,|,justifyleft,justifycenter,justifyright,” + “|,bulletlist,numlist,|,undo,redo,|,formatselect,|,cut,copy,paste,pastetext,pasteword,|,” + “outdent,indent,|,link,unlink,image,cleanup,code,charmap”,
theme_advanced_buttons2 : “”,
theme_advanced_buttons3 : “”,
theme_advanced_toolbar_location : “top”,
theme_advanced_toolbar_align : “left”,
theme_advanced_statusbar_location : “bottom”,
theme_advanced_resizing : true,
theme_advanced_resize_horizontal : false,
content_css : “/Styles/blaqStyleSheet.css”,
body_class : “contentBody”

})</script>

Disabling an Ajax Timer Control

I just got done fixing an issue that I was having with the ASP.NET AJAX Timer control, and I figured I’d write about it because there doesn’t seem to be like a ton of documentation out there right now as to exactly what is going on.

Here is the scenario: You have an Ajax enabled .aspx page which has an UpdatePanel set to update itself based upon a timed interval from a Timer control. You also have some type of submit button on the page that does a synchronous page submission. So, what happens when you click on the submit button, and before the page submit has run through it’s logic, the timer control trips and causes an asynchronous Ajax post? Well, what I was seeing was that the page would end up in an incongruous state – the submit works, but the page updates itself to show the results of the asynchronous update, not of the synchronous submit action.

This behavior is to be expected, to tell the truth. One of the actions has to win, and it may as well be the last one into the queue instead of the first. So, the real thing we want to do is disable the timer control based upon the submit button being clicked. No problem, I thought – I’ll just disable it in the event handler for the button click, like this:

private void SomeButton_Click(object sender, EventArgs e){

Timer1.Enabled = false();

// Do stuff here…

// Maybe reenable the timer here…

}

Hmmm… that doesn’t seem to work, and here’s why. Since the submit button click is handled server-side, the enabling-disabling action won’t be propagated back to the client until the postback is complete. The timer is a client-side javascript control, so it can (and will) keep working as the page is being posted.

So, what do you do? Well, you’re only really left with one option – disable the timer control on the client side. That means you’re going to be doing it via Javascript. Luckily, I found this post that details all about using Javascript to disable the timer control. Now, all you have to do is hook up a client side event to the timer control and programatically disable it. You can re-enable it in codebehind with the button click handler, too, so you don’t have to do that on the client side. Here’s what I ended up with:

<script language=”javascript” type=”text/javascript”>
<!–
function DisableTimerControl(){

// Disable the ajax timer control before elevating on the client side.
// It will be re-enabled on the server side.
var timerControl = $find(“AjaxUpdateTimer”);

if (timerControl != null){

timerControl._stopTimer();

}
return true;

}
–>
</script>

That wasn’t so bad, was it now? The long and the short of it is that you have to be careful about using Ajax controls, but it is still pretty easy to make them do what you want if you’re on top of things. Either way, Ajax is here to stay, so get used to it!