Bertrand Le Roy recently published a 13 page document on CodePlex, describing the ASP.NET Team’s goals for the future of ASP.NET AJAX. It’s been available for two weeks now, but there has been little reaction to it online and less than 8,000 people have downloaded it. I’m surprised, considering its importance.

If you haven’t yet read it, I encourage you to download and read it right now.

Now that you’ve read the official document, continue reading here for my take on what I think are the most significant items in the document. What follows is broken down into sections matching the road map document:


Persistent client-side event sinks

The following example shows setting up an event sink that will result in the title attribute of all spans getting dumped to the debug trace. This starts working at the moment the call is made and will continue working even for new spans that get created after that.

$listen(“hover”, “span[title]”, function(e) { 
  Sys.Debug.trace(this.title); 
});

The average web page’s DOM is becoming increasingly volatile. Elements may be destroyed, appended, and replaced many times between each page refresh. Maintaining event handlers on those relatively ephemeral elements is often a significant headache.

Hence I think $listen has great potential, with one caveat: Performance.

If I have a dozen $listen sinks set up, what happens when I dump a thousand new elements into a table or select list? Will a $query be executed for each $listen, on every DOM modification?

If $listen introduces client-side hangs during those sorts of operations, the convenience would not justify the trade-off. Please be sure to include that sort of scenario in your testing.

Client Data and UI Templates: The Good

For performance critical functionality, using something like the UpdatePanel will never be a panacea. It was a noble effort, but trades far too much performance for its simplicity. When speed counts, the only thing on the wire should be data.

For that reason, I’m very happy to see client-centric markup generation being officially supported. Check out this example code, from the road map document:

<div id="repeater1"></div> 
 
<div id="template1" class="sys-template"> 
  <h2><a href="{{ 'products/' + id }}">{{name}}</a></h2> 
  <p>{{description}}</p> 
</div> 
 
<script type="text/javascript"> 
  Sys.Application.add_initialize(function() { 
  $create(Sys.UI.DataView, { 
    template: $get("template1"), 
    data: myData 
  }, {}, {}, $get("repeater1")); 
} 
</script>

This implementation is fundamentally similar to my recent post on creating a client-side repeater with jQuery and ASP.NET AJAX. I think it will be a solid step in the right direction, and it will be great to see the technique become more mainstream in v.Next.

Client Data and UI Templates: The Ugly

The road map goes on to describe more complex templating, attaching client-side behaviors through xmlns attributes, and even a client-side analogue for DataSource server controls. Here’s an example:

<body xmlns:sys="javascript:Sys" 
      xmlns:dv="javascript:Sys.UI.DataView"> 
 
 
<div id="tripList" sys:attach="dv" dv:data="{{myData}}"  
    dv:template="{{$get("template2")}}"></div> 
 
<div id="template2" class="sys-template" 
  xmlns:ac="javascript:Sys.UI.AutoComplete" 
  xmlns:wm="javascript:Sys.UI.Watermark" 
  xmlns:dp="javascript:Sys.UI.DatePicker"> 
 
  <input type="text" sys:id="{{ "airport" + $index }}" 
    sys:attach="ac,wm" 
    ac:serviceUrl="airportList.asmx" 
    ac:minimumPrefixLength="{{1}}" 
    wm:text="Type the name of an airport" 
    value="{Binding airport, mode=twoWay}" /> 
  <input type="text" sys:id="{{ "flight" + $index }}" 
    value="{Binding flight, mode=twoWay}" /> 
  <input type="text" sys:id="{{ "date" + $index }}" 
    sys:attach="dp" 
    dp:lowerBound="{{ new Date(1970, 4, 21) }}" 
    dp:upperBound="{{ new Date(2050, 1, 1) }}" 
    value="{Binding date, mode=twoWay}" /> 
</div>

In my experience, this code is not maintainable. Unless spectacular Intellisense and designer support accompanies its release, I wouldn’t expect it to see much use in production.

Further, the behavior and content should be separated; especially given that one of the road map’s stated goals is accessibility. Unobtrusive JavaScript is the way to go here, not overloaded declarative markup.

Can we get this functionality in a way that is conducive to separation of concerns?

Improved animation support

I bet there are more people who have used the toolkit’s AnimationExtender once than there are who have used it twice. It’s a very powerful animation framework, but unwieldy and difficult to learn.

For that reason, it’s a relief to see the XML syntax being abandoned for fluent JavaScript objects. The example from the road map:

$query(".sprite").animate([ 
    new Sys.Animation.FadeIn(300), 
    { 
      "style.backgroundColor": "#ff0000", 
      "style.fontSize": "2em"), 
      duration: 500 
    }, 
    new Sys.Animation.FadeOut(300) 
  ]) 
);

That’s a massive improvement over the AnimationExtender, but still a bit verbose. It would be great if that could be further distilled down to something like this:

$query(".sprite").FadeIn(300)
                 .FadeCSS({
                   "backgroundColor":"#f00", 
                   "fontSize":"2em",
                   duration: 500 })
                 .FadeOut(300);

New AJAX Control Toolkit components

The next section in the road map describes several new AJAX Control Toolkit controls in the works, and solicits community input:

Which controls get implemented first will highly depend on community feedback. We welcome suggestions and encourage you to communicate your preferences about which controls would be the most useful to you as well as what features you would expect on each of them. We identified the following controls as possible candidates:

High priority (v.Next):

  • Grid. Make this work with ASMX and WCF JSON serialized services, and it will be the most popular control in the toolkit. Be sure that it renders <thead> and <tbody> elements, unlike the GridView.
  • Upload. We need a solid solution to the async upload problem. It’s not something that would be used as often as the Grid, but would be nearly irreplaceable.
  • Asynchronous validator. I began writing an asynchronous username availability validator last year, but became disillusioned before overcoming all of the hurdles involved. I think an asynchronous validator base control that allows custom, server-side validation rules would be a great addition.

Would be nice later:

  • Progress bar. How would this work? If it were easy to use, it could be very popular. It shouldn’t be rushed though. Save this till later and take the time to perfect it.
  • TreeView. This isn’t something I would use very much personally, but I think it would be welcomed by many developers.

Low priority:

  • Layout. How many real websites use these ubiquitous splitter controls? They are typically indicative of a poor web UI, attempting to copy the layout of a thick client. We can do without this.
  • Chart. It makes no sense to reinvent this wheel. A Silverlight based control isn’t going to be very widely adopted right now. More importantly, it doesn’t make sense to alienate the companies who have been supplying excellent visualization controls for years.
  • Color picker and rich text editor. As with charting, this functionality has been available for many years. There are mature solutions already available. Your efforts would be needlessly squandered here.

JavaScript build tools

Aggregation and minification (is that a word?) is a constant thorn in my side. More details on implementation specifics would be nice, but I think the feature can only be an improvement.

While you’re supporting minify, you might as well add packer support as well. Depending on the speed of the client machine and execution order of scripts, packed scripts may load faster than minified ones, and can also be used to provide minimal obfuscation.

Ideally, this would enable us to work with an uncompressed, commented JavaScript include in debug mode. Then, in release builds, the include would be optimized and combined with other scripts. Please keep in mind that we may be using scripts hosted externally, which also have separate debug and release versions. A mechanism to allow for that would be excellent.

I think that the ability to add script references at the web.config level could be very useful as well. For example, I may want to reference jQuery throughout my entire website. Save me the trouble of adding that script include on every page, and I’ll buy you a beer the next time you’re in Atlanta.

Stay focused on your core users

Finally, I was surprised to see this ambitious goal early in the document:

Make ASP.NET Ajax the first-class choice for all Web 2.0 developers

I don’t mean to sound negative, but that is simply attempting to bite off more than even Microsoft can chew. At least in the near-term, developers using other application stacks or JavaScript frameworks aren’t going to replace what they’re using with v.Next of the client side ASP.NET AJAX library.

We need the ASP.NET Team to focus on the needs of those of us using ASP.NET AJAX today. Empower existing ASP.NET developers to create robust, dynamic websites, and you’ll find that our work has the potential to reach broad audiences on your behalf.

A few additional thoughts

Stop trying to hide JavaScript from us. Similar to the UpdatePanel, things like Script# and Volta are neat, but they are leaky abstractions. I hope they don’t significantly influence the ASP.NET Team’s vision of the future of AJAX.

It’s like Joe said: JavaScript is inevitable. Why learn to use Volta or Script#, when you could just learn JavaScript and be done with it?

I don’t want to become a client-side architecture astronaut.

Refreshing UpdatePanels via JavaScript. A year later, my post about using __doPostBack to refresh an UpdatePanel is still the most trafficked page on this site. v.Next ought to have a better way of doing this, as it’s obviously a common need.

I believe $query(”UpdatePanel1″).Update() would be very well received.

Host the client library for us. Steven Smith mentioned this back in April. Yahoo hosts all of the YUI scripts on their CDN. Google now hosts jQuery, prototype, script.aculo.us, MooTools, and dojo. There’s no excuse for Microsoft not to follow suit here.

For those of us writing public facing ASP.NET applications, this can be a non-trivial factor in deciding which JavaScript framework to use. In addition to a Google or Yahoo CDN being more performant than most any hosting setup, your users may even show up with the library already cached.

Conclusion

It’s no secret that myself and several others have been drifting toward jQuery this year. I sincerely hope that ASP.NET AJAX v.Next might begin to reverse that trend.

The ASP.NET Team appears to have some exciting features in store for us. I hope that we start seeing “futures” releases soon. Maybe some idea of a tentative release timeline?

What do you think? Did I miss anything important?