You are reading an article. Lots more of these in the archives. Dave Ward Meet Dave Arrow


30Comment Retweet

Javascript Libraries and ASP.NET: A Guide to jQuery, AJAX and Microsoft

Oct 4, 2010 In Development By Dave Ward

When Microsoft announced they would begin providing official support for jQuery, few of us realized how profoundly that announcement would eventually impact client-side development on the ASP.NET platform. Since that announcement, using jQuery with ASP.NET has moved from the obscure, to a central role in ASP.NET MVC’s client-side story, and now to the point of potentially superseding ASP.NET AJAX itself.

The journey hasn’t been all smooth. With Microsoft’s move toward jQuery, the ASP.NET AJAX, Microsoft Ajax Library, ASP.NET Ajax Library and Ajax Control Toolkit roadmaps have been uncertain at times. This has made it difficult to keep track of which projects are still relevant, and especially which you should choose going forward.

In my last article for Mix Online, I discussed what ASP.NET needed to know about jQuery from development perspective.  In this article, I want to provide clarity on the events that led us to this point, talk about what portions of the current AJAX framework are and aren’t affected by recent changes and show you where we’re headed next. In addition,I’ll dive into the implications of the recent announcement about the adoption of Microsoft’s template library by the jQuery core.

How We Got Here

To fully grasp the current state of affairs,it helps to understand how we got here—especially in light of the recent ambiguity surrounding several of Microsoft’s similarly-named libraries. That story begins in 2005-2007, as Microsoft previewed and then released their first AJAX framework for the ASP.NET platform.


Originally developed under the codename Atlas, ASP.NET AJAX was Microsoft’s first bid to provide ASP.NET developers with officially-supported AJAX functionality. The ASP.NET AJAX extensions initially shipped as an out-of-band extension to ASP.NET 2.0, but its popularity led to its inclusion as a first-class component of ASP.NET 3.5 and subsequent releases.

ASP.NET AJAX’s popularity stemmed from its server-side controls such as the ScriptManager, UpdatePanel and Timer, which made it unnecessary to learn or use JavaScript. Unfortunately, the convenience those server-side controls offered came at the expense of performance and efficiency. Though a server-driven approach remains in use even in ASP.NET 4, its popularity has waned.

One of ASP.NET AJAX’s more enduring features was that it augmented ASMX services with the ability to communicate in raw JSON format. Many of the jQuery-centric techniques to avoid ASP.NET AJAX actually still leverage ASP.NET AJAX’s System.Web.Extensions features on the server-side, using features such as ASMX ScriptServices, Page Methods and the JavaScriptSerializer class.

ASP.NET AJAX is also notable because it gave us Microsoft’s first full client-side framework— MicrosoftAjax.js. MicrosoftAjax.js not only underpinned ASP.NET AJAX’s server-side abstractions, but also provided a cross-browser JavaScript API for tasks including event handling and basic DOM manipulation. Even when burdened by the code necessary to support the UpdatePanel, MicrosoftAjax.js weighed in at only 24kb when minified and zipped.

The Ajax Control Toolkit

Shortly after the first version of ASP.NET AJAX shipped, a companion product named the Ajax Control Toolkit was released on CodePlex as an open source project. The Ajax Control Toolkit (ACT) is a collection of special server controls built on top of ASP.NET AJAX’s client-side MicrosoftAjax.js framework.

At the toolkit’s inception, its popular controls included the CascadingDropdown, AutoComplete and ModalPopup extenders. These controls were primarily abstractions around embedded JavaScript to achieve rich DHTML functionality without client-side programming. In fact, some of the controls, such as TextBoxWatermark and MaskedEdit, were purely client-side effects, wrapped in a server control for ease of use.

Unfortunately, what this server-centric approach offered in ease of use was often negated by inefficiency. It was easy to end up with dozens of HTTP requests for embedded JavaScript, image and CSS resources. Worse, it wasn’t entirely obvious where the culprit was, since those embedded resources were silently injected on the control’s behalf, not explicitly added to the page by the developer.

Though the Ajax Control Toolkit still enjoys significant popularity (as I’m writing this, it remains one of the top three most downloaded CodePlex projects in the last week), its uptake in new projects is beginning to decline in favor of a more client-side approach that uses jQuery and its plugins.

The Microsoft Ajax Library

By early 2008, the ASP.NET team was already at work on a successor to ASP.NET AJAX’s client-side component: The Microsoft Ajax Library. It was an upgraded replacement for MicrosoftAjax.js that provided the previous framework’s baseline features, as well as a range of expanded functionality.

Over the course of six preview releases and a beta, The Microsoft Ajax Library rolled out advanced features including:

  • Script Management – Handling interdependencies between scripts, asynchronously loading them on demand and reliably raising events when they’ve been loaded is a tedious problem to solve. It’s worth the effort though. Non-blocking, asynchronous script loading can result in a marked improvement in how quickly pages load.
  • Templating – The DataView component provided a robust client-side templating solution, similar to what a Repeater or ListView could accomplish on the server-side. As development transitions to the client-side, the problem of transforming JSON data sources in to HTML markup becomes a common thorn in our sides. The DataView was a solid solution to that problem.
  • Data Integration – One of the library’s most powerful ASP.NET-specific features was the DataContext. Similar to its namesake on the server-side, the DataContext made it extremely easy to work with data and included support for Data endpoints and client-side change tracking and submission.
  • Componentized – The Microsoft Ajax Library was eventually refactored into about a dozen loosely coupled scripts, divided roughly to a component (e.g. DataView or DataContext) per script. The script dependency management abstracted this away so you could pick and choose features to use and rely on the framework to asynchronously load the smallest subset of scripts necessary to support those features.

One notable thing about those new features is that they didn’t overlap with what jQuery core provided at the time. Rather than reinventing a selector engine, DOM manipulation library or animation framework to compete with jQuery, this library’s focus was truly on complementing jQuery.

That shift in approach was an important one. ASP.NET developers using jQuery as the foundation for their client-side development could continue doing that, while selectively taking advantage of the Microsoft Ajax Library’s improvements. The library’s componentized approach and script dependency management made it easy and straightforward to load the minimal set of script to provide exactly the functionality you desired.

The CodePlex Foundation

Since JavaScript frameworks must be distributed as source code anyway, they’re natural candidates for open source projects. In that spirit, the ASP.NET team decided to embrace open source and contributed the Microsoft Ajax Library to the recently-formed CodePlex Foundation in early 2010.

To better fit the ethos of open source and avoid any misinterpretation of Microsoft’s role in the CodePlex Foundation, the decision was made to remove “Microsoft” from the library’s name. Instead, it was renamed more neutrally as the ASP.NET Ajax Library.

At that point, the library still had no dependency on jQuery. However, many of the library’s components were refactored so they could be instantiated as jQuery plugins instead of requiring the older create or Sys.create syntaxes. Additionally, the library’s Sys.get method supported passing advanced selector queries through to jQuery if it was present.

New Directions – Microsoft <3 jQuery



During the second day’s keynote at MIX10 this year, Microsoft put an abrupt shift in thinking on display. Instead of demonstrating the ASP.NET Ajax Library, Microsoft gave us the first public glimpse of an entirely new approach: a jQuery plugin called jQuery Templating.

Even for those of us who follow Microsoft’s client-side development story, this year’s events came as quite a surprise. Particularly, the lack of an officially sanctioned new AJAX technology to accompany ASP.NET 4’s release left most of us scratching our heads. For nearly two years, we generally expected that the ASP.NET Ajax Library would ship with ASP.NET 4, but nothing new shipped at all!

Even more surprising, the nascent ASP.NET Ajax Library not only remained unreleased, but was abandoned completely. If anyone had still wondered whether or not Microsoft was truly committed to jQuery, it was clear at that point that they were “all in.”

Microsoft gives back to jQuery

The jQuery Templating plugin showcased at MIX10 was only the beginning. Since then, Microsoft has committed development, testing, documentation and other resources toward helping improve jQuery. These efforts include both contributing patches to jQuery core and developing new plugins.

Additionally, Microsoft continues to offer its technical support services to developers using jQuery. While the expansive jQuery community provides all the support most of us will ever need via blogs, message boards, and tutorial sites, having SLA-backed phone support is an important factor in the decision process at some organizations.

Even though the collaboration between Microsoft and the jQuery project has taken several months to hit its stride, the new relationship has begun producing tangible results. Not only has Microsoft refined the jQuery Templates plugin to the point that it’s a great client-side templating solution in its own right, but their implementation of jQuery Templates is now slated for inclusion into jQuery 1.5.

Where we stand now and a look at the future

Microsoft’s changes in direction this year are potentially great ones, and we’ve only seen the first glimpse of what they have in store for client-side development on the ASP.NET platform. However, it hasn’t been easy to keep track of the shifting roadmap, exactly which technologies are impacted by the changes, and which approaches to bet on going forward.

The status of existing Microsoft projects

First, this is what you need to know about the status of Microsoft’s existing client-side development products:

  • ASP.NET AJAX – Both the server-side and client-side portions of ASP.NET AJAX ship with ASP.NET itself and are fully supported. Though the UpdatePanel’s server-side flavor of AJAX has largely fallen out of favor, it will continue to be a viable approach and be supported for the foreseeable future. There has been some confusion about the fate of ASP.NET AJAX, due to the similarity of its name and the ASP.NET Ajax Library’s, but their fates are in no way intertwined at this point.
  • The Ajax Control Toolkit – The venerable Ajax Control Toolkit is still available on CodePlex and continues to receive occasional bug fixes, but activity on the project has been sparse in recent month. As was quietly showcased toward the end of the ASP.NET Ajax Library’s lifespan, it’s possible that most of the Ajax Control Toolkit’s DHTML controls could be re-implemented as jQuery plugins instead of their current assembly-based packaging. With so much of its functionality already present in jQuery and jQuery UI, the only certainty is that its future is uncertain.
  • Microsoft Ajax Library / ASP.NET Ajax Library – Though this library was stealthily “released” within the latest versions of the AJAX Control Toolkit distributions, it is deprecated, obsolete, is not supported by Microsoft in any form. It will receive no further development or bug fixes, and should not be used going forward.

The most important takeaway here is to differentiate between ASP.NET AJAX and the ASP.NET Ajax Library. They are named so similarly that it’s easy to be confused about their unrelated roadmaps. If you’re using the ScriptManager or UpdatePanel, you’re in the clear in terms of future support. If you’re using a DataView or Sys.require, you’re using the now-obsolete ASP.NET Ajax Library and should consider a jQuery-based alternative.

jQuer­y development to watch

Though it’s clear that jQuery is the future of client-side development on the ASP.NET platform, there hasn’t been much guidance about where to start and what to learn. This story is still unfolding, but these are a few of Microsoft’s new jQuery efforts that you can watch to stay abreast of what’s to come:

  • Templating – Previously referred to as jQuery.tmpl or jQuery-tmpl, the jQuery Templating feature was Microsoft’s first foray into working with the jQuery team and community. Though its inclusion in jQuery isn’t planned until jQuery 1.5 is released, you can begin using it in plugin form immediately. Though the plugin is technically still in beta, the jQuery team has designated jQuery Templates an “official” plugin and it is being used as part of the foundation for new jQueryUI widgets. That plugin is currently available on GitHub:
  • Data Linking – The next feature that may be a precursor to more official things to come is the jQuery-datalink plugin, which is also available on GitHub: With this plugin, you can “link” JavaScript objects together so that they remain synchronized when changes are made to one or both of them. The canonical example of this is linking a JavaScript object’s properties to corresponding fields in a form, to eventually automate tasks such as change tracking and submission.
  • Globalization – The third jQuery plugin that Microsoft is working on is one called jQuery-glob. Though it will almost certainly not find its way into jQuery core, I believe it will become one of many “official” ASP.NET jQuery plugins in the future.

While these three plugins are the only ones that Microsoft is developing in public right now, they are just the tip of the iceberg. It’s likely that we’ll soon see Microsoft develop jQuery plugins to re-implement the Ajax Library’s DataContext, provide easier access to ASP.NET-specific data endpoints, and replicate the functionality of the Ajax Control Tookit.

To keep up with Microsoft’s work on these official jQuery plugins and any new ones that may emerge, I suggest keeping an eye on .NET jQuery Extensions at GitHub. In addition, several members of the Microsoft team have blogs with great tutorials and announcements regarding the team’s ongoing work with jQuery:

Finally, you can also watch my blog ( or follow my Twitter updates (@Encosia) for more information like this article and hands-on examples of using these new jQuery features with ASP.NET.

Follow the Conversation

30 comments so far. You should leave one, too.

Ryan Ryan said on Oct 4, 2010

Awesome post Dave! Finally some insight as to what Microsoft has planned for the future of AJAX implementation. As a developer this really goes a long ways in making my life easier. Now if only we could get Microsoft to pick up the slack in IE.

Thogek said on Oct 5, 2010

Sounds like the historically bumpy roadmap of JavaScript/AJAX in ASP.NET is settling into much sharper (and more practical) focus. Thanks for the illumination. :-)

David Clarke David Clarke said on Oct 5, 2010

It''s really a shame that MS didn''t join the jQuery party years ago or at least stop trying to pretend browsers didn''t exist. For anyone working with ASP.Net, everything MS did was an attempt to abstract the browser out of the equation. The misery and toil of trying to get .aspx pages to work with AJAX controls (particularly when maintaining other devs work) is unlikely to go away any time soon for those of us who still have a foot in the ASP.Net camp. Good to see the blinkers are off.

KastoJay said on Oct 5, 2010

Awesome post. Thanks for this very well explained overview !

Pierre Boucher Pierre Boucher said on Oct 5, 2010

Great post!

Using jQuery myself in my web client side development, I am very happy to MS decision to join thousands of developers that already use it.

I am just wandering if this new interest has anything to do with the fact that to my knowledge, Google does not use jQuery on its clients application (or do they?).

Anyway, no matter the reason, it''s good new.

Micah Burnett Micah Burnett said on Oct 5, 2010

I''m glad to hear MS is embracing jQuery almost as much as that UpdatePanels are falling out of favor. Those things are a severe pain to work with.

Sean Gerety Sean Gerety said on Oct 5, 2010

Nice post! I always disliked the server side injection of script and found it hostile to debug and develop on the client side of the browser. jQuery has been such a pleasure to the use with existing ASP.NET web forms & ASP.NET MVC. I''m really looking forward to the new plugin''s that Microsoft is contributing.


Sumit Pranav Sumit Pranav said on Oct 5, 2010

Excellent post.

Thanks for giving an insight of MS road-map.

Wish to read next article on the same topic...

W. David Porter W. David Porter said on Oct 5, 2010

Thanks for the article. I haven''t been able to find out anything about the future of the client side ASP.NET Ajax Library until now.

I am very sad at the demise of the ASP.NET Ajax Library. If you download the source for the ajax control toolkit, there is a project that includes javascript for purely client side controls such as watermarks, calendars, tabs etc. Especially the calendar, which works much better than the jquery ui date picker. It works great, looks great, and it''s just really sad it''s no longer supported. I hope it won''t be lost.

Sanat Gersappa Sanat Gersappa said on Oct 6, 2010

Nice post. jQuery looks better by the day. Thanks for clearing up the confusion on the roadmap.

Chris said on Oct 7, 2010

If ASP.NET Ajax Library is obsolete, do you have any recommendations as to an alternative to the script loader (I was about to start using this and now I think I best not).

Dave Ward Dave Ward said on Oct 8, 2010

@Chris: I like LABjs.

RequireJS is the other major contender in that area right now.

Scott Koon also just released a new alternative called Bootstrap. I haven''t had a chance to try it yet, but it should be another solid choice.

Rod Rod said on Oct 9, 2010

Great post Dave! It took MS awhile, but it''s nice to see the jQuery <3 and I''m looking forward to the upcoming developments, especially the Data Linking plugin.

Alex Lysenka Alex Lysenka said on Oct 11, 2010

Great post Dave. Thank you so much for clearing things up.

rtpHarry rtpHarry said on Oct 13, 2010

Thanks for writing this article it did clear things up for me as the whole area has been murky in my mind for a while. I kept going to download ACT and wasn''t sure if I should be getting ACT directly or the Microsoft Ajax Library as it now included it.

It seems that the key take away is that there isn''t really any solid solution for us to rely on which is disappointing seeing as ajax has been popular now for over 5 years.

One of the things I liked about webforms was that all the functionality was included and standardised. I appreciate that in the long run jQuery = awesome and having everything integrated will be cool but at the moment its a case of - is it responsible for me to use any of this on a clients project?

Every plug-in has its own little way of approaching things, varying standards of documentation, questionable future support, limited samples or experts to turn to for advice, "keep your fingers crossed" quality control... I know people hate on Microsoft but having it all handed on a plate certainly has its benefits.

lol said on Oct 13, 2010

Sounds like Microsoft is taking lessons.

Nick said on Oct 13, 2010

Dave your the man, any help in this area on the direction microsoft is taking helps me focus my efforts.

niloo25 said on Oct 14, 2010

Thanks Dave, for your efforts, really useful to know Microsoft roadmap for Ajax and open source in future version.

Thank God, I am out of AJAX now. Open source is really opening my eyes these days!

rob greene rob greene said on Oct 14, 2010

Nice, and informative in a general direction. But I have to write a program tomorrow. Knowing the future does not prepare me for right now, what tools should I use?

Dave Ward Dave Ward said on Oct 14, 2010

@Rob: I recommend using jQuery and its plugins for anything you''re starting today. If you need templating, use the jQuery Templating plugin until jQuery 1.5 is released.

Sergey said on Oct 16, 2010

Thanks for the great post!

Now at least I understand why "ASP.NET AJAX in Action, Second Edition" is not going to be published.

Isaiah Okorie Isaiah Okorie said on Oct 16, 2010

Thanks Dave for another useful insight. Day after day it sounds like its more about what means to the web and NOT the other way (as was in the past!). Your articles make my jQuery day! Many thanks and stay blessed!

Dave Ward Dave Ward said on Oct 17, 2010

@Sergey: That''s exactly right. When we saw these changes coming, we decided it would be wrong to either a) release a new book (at full price) with very minor updates or b) release a book that would be basically obsolete by the time it was in print. It was a difficult decision, because we were nearly finished (I had written 15,000 words about the DataView alone), but we all agreed it was the right thing to do.

Sorry for any confusion or disappointment around that whole situation. We''re working to come up with an even better replacement soon, in the spirit of what''s covered in this article.

Christophe Christophe said on Oct 19, 2010

All these project names are confusing - thanks for shedding some light on their respective roles and what to expect in the near future.

Mike Mike said on Oct 27, 2010

I use ScriptManager and UpdatePanel. What are the jQuery equivalents of those?

andres felipe andres felipe said on Nov 3, 2010

thanks for the info
Right now i need to take a desicion to use a ajax library inside my projects

tdurant tdurant said on Dec 17, 2010

I''m glad because I already do all of my SharePoint interactions with Jquery.

Yurets said on Dec 28, 2010

So, where does it leave custom server control development with client side functionality? It used to be based on what was called "Microsoft Ajax Library" which is now, I guess, rolled into AjaxControlToolkit. But, is it still a preferred method?

Dave Ward Dave Ward said on Jan 2, 2011

@Yurets: You can still develop server controls that depend on a ScriptManager and expect MicrosoftAjax.js to be present. The new client-side library, the ASP.NET Ajax Library, with features like a script loader, templating, and two-way databinding is what was discontinued.

That said, there''s no reason why a server control must depend on either of those libraries. You can just as easily write a server control that injects a copy of jQuery and uses that to implement its client-side features.

Jayp Jayp said on Feb 4, 2011

Does Microsoft go out of their way to intentionally complicate things, or is this just the product of poor planning...? Lack of forethought...? ...or...?

I mean, seriously: MS Ajax vs. MS Ajax Library vs. MS Ajax Toolkit, etc. The ridiculous naming makes this all just very difficult to follow.

Then, on the flip-side... .asmx vs. .svc vs. PageMethods, etc... It''s just too much for one guy to keep up with.

I''m all for staying progressive, modern, and up to the latest standards, but it just seems like MS is constantly changing things that aren''t broken.

Sometimes, it makes me want to leave 20+ years of dev. experience behind and find a simpler way of life...