When the ASP.NET Ajax Control Toolkit first came out with the CalendarExtender, I just loved it. That smooth transition when navigating from month to month or year to year really won me over. I’ve also loved how I could use it as a simple ASP.NET Control by integrating it in my pages and using from my code-behind.

I took a look at the jQuery UI DatePicker widget (from an ASP.NET Developers point of view), which again completely won me over. What was it this time? Well … the speed, the options, the themes, the frequent updates, the ease of integration, etc.

Well this post started probably out of disappointment and I wanted to call it: Why I abandoned using the CalendarExtender and choose to go with the jQuery UI DatePicker instead. The disappointment started from a CSS issue, namely I’ve been using some default values for tables like:

border-collapse: separate;
border-spacing: 2px;

Of course the lovely CalendarExtender doesn't override these, and of course due to the fact that it specifies a default width (which works well in normal / default conditions) the last column of days can’t be seen.

You can as well go ahead and add new classes to your CSS files, but I do not accept this idea, as the Ajax Control Toolkit is a drag and drop solution. Add a reference and it adds everything that is necessary, even some good quality CSS and you are ready to go. On the other hand I don’t want to do the same hack for each and every site I use Ajax Control Toolkit on, so this issue should be solved once and for all.

This means that I need to download the Ajax Control Toolkit source, edit the CSS, compile, add the new reference, clear cache and we are ready to go. Except there is another problem. On day, there will be a new version of the Ajax Control Toolkit, which will also need to be “hacked” (of course if I don’t forget it) before I’m using it in a website.

Then there is another thing I don’t agree with on the Ajax Control Toolkit Calendar Extender. I do not like the fact that I can’t set the Culture and UiCulture for a specific control. It inherits the specific setting from the @Page declaration or from your general settings in the web.config file. It is logic, and it does work but it doesn’t seem elegant enough, or should I say elastic or dynamic enough.

Of course most of my comments here are only viable if I compare the CalendarExtender to the jQuery UI DatePicker, which is simply a beautiful piece of work.

After working with the jQuery UI DatePicker I noticed how much markup I needed to write to display a Calendar, it isn’t that bad when you need to create one, but if you have several dates that need to be recorded on one page, maintaining >4 CalendarExtenders tied to some TextBoxes isn’t that much fun.

Instead you can use a CSS class for each TextBox (given that you need to use the same options for all) and then make use of the powerful jQuery selector like:

$(".datePicker").datepicker();

For instance to create a set of 4 Calendar controls and 4 DatePickers you would need to write something similar to:

1) ASP.NET Ajax Control Toolkit – CalendarExtender

    <asp:TextBox ID="txtC1" runat="server"></asp:TextBox>
    <ajax:CalendarExtender ID="calC1" runat="server" TargetControlID="txtC1">
    </ajax:CalendarExtender>
    <asp:TextBox ID="txtC2" runat="server"></asp:TextBox>
    <ajax:CalendarExtender ID="calC2" runat="server" TargetControlID="txtC2">
    </ajax:CalendarExtender>
    <asp:TextBox ID="txtC3" runat="server"></asp:TextBox>
    <ajax:CalendarExtender ID="calC3" runat="server" TargetControlID="txtC3">
    </ajax:CalendarExtender>
    <asp:TextBox ID="txtC4" runat="server"></asp:TextBox>
    <ajax:CalendarExtender ID="calC4" runat="server" TargetControlID="txtC4">
    </ajax:CalendarExtender>

2) jQuery UI DatePicker

    <asp:TextBox ID="txt1" runat="server" CssClass="datePicker"></asp:TextBox>
    <asp:TextBox ID="txt2" runat="server" CssClass="datePicker"></asp:TextBox>
    <asp:TextBox ID="txt3" runat="server" CssClass="datePicker"></asp:TextBox>
    <asp:TextBox ID="txt4" runat="server" CssClass="datePicker"></asp:TextBox>

    <script type="text/javascript">
        $(document).ready(function() {
            $(".datePicker").datepicker();
        });
    </script>

The jQuery UI solution is much more pleasing to my eye, what do you think?

You can check out the multitude of options the jQuery UI comes with on the jQuery UI DatePicker Demo Page. Most of these didn’t seem that important for me at the first sight but then it’s really a big help disabling the option to choose a future date (IE. restricting certain dates). For example with the jQuery UI DatePicker you can set the maxDate and minDate of the widget which will only allow the Date selection within that range.

    $(document).ready(function() {
        $("#<%=txtTimeSheetDate.ClientID %>").datepicker({
            dateFormat: 'dd.mm.yy',
            minDate: -5,
            maxDate: 0,
            showOtherMonths: true,
            showStatus: true
        });
    });

The above piece of code generated the following DatePicker:

This isn’t easily and quickly doable with the CalendarExtender, in fact you can handle some events like: OnClientDateSelectionChanged or OnClientHiding but this is simply not straightforward, and because maybe one day, someone else will need to maintain this page you’ll better go with the KISS (Keep is Simple, Stupid) principle and use the DatePicker instead.

Then there is another factor that speaks for jQuery from my point of view. There are several themes to choose from, so there will definitely be one that will fit the stylesheet theme of your website. If not, you can still manually edit the CSS files supplied with the downloaded package, or you can create new classes which override the default settings, exactly the way it is possible with the Ajax Control Toolkit.

One disadvantage that comes with the usage of the jQuery UI library is the size of it. At the current version (1.7) the full jQuery UI library together with all the CSS and images bundled will way around 450kb uncompressed, which is allot, but the upside is that in the jQuery UI Download section you can customize your download. If for instance you don’t need certain effects or interactions or even widgets the size of the library will decrease considerably.

Although this will decrease the first load of the webpage, the JavaScript will be cached, and won’t be downloaded again until it expires.

What I also like about the jQuery UI library is that it gets updated relatively often, it ships with very few bugs, it’s super cross browser compatible and it integrates well in my solutions with ASP.NET and jQuery. The other day I’ve created a little piece of software for a photo gallery where I combined the ModalPopupExtender, jQuery and jQuery UI, sortable and draggable interactions to reorder images with jQuery Ajax Callbacks with the gallery, and modally edit names and descriptions of images.

The documentation is also a slight PRO for the jQuery UI, so there is no more question about it. Simplicity, ease of use, excellent quality, use the Ajax Control Toolkit, but replace it with jQuery UI where and whenever possible.