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.

ASP.NET AJAX

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. That plugin is currently available on GitHub: http://github.com/jquery/jquery-tmpl
• 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: http://github.com/nje/jquery-datalink. 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:

• Scott Guthrie
• Stephen Walther
• Boris Moore
• Dave Reed
• James Senior
• Rey Bango

Finally, you can also watch my blog (http://encosia.com) 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.