Jack @ ASP.NET

It’s important to understand the difference between server-centric “AJAX” and client “pure” AJAX.

In server-centric AJAX applications, even though the application leverages asynchronous calls between client and server, the server is the one that is actually responsible for generating the necessary HTML content before providing it to the client. This leads to heavy bandwidth usage, and lack of responsiveness. In addition, the client application becomes far too reliant on the functionality of the server, and its ability to provide good markup, as opposed to simply requiring data and simple interaction.

In client AJAX applications, the communication with the server is purely for passing data back and forth. All of the rendering and state is maintained within the client environment, and the server is only brought into the picture as needed.

So, “The server should only be concerned with data, not presentation”.

In order to enable our ability to easily create dynamic UI and place the rendering process on the client, we need a way to define templates of markup that represent the UI we wish to create, and allow the runtime to instantiate them for us. This alleviates the need to write a bunch of DOM code or depend on server-rendering.

If you’ve used WebForms before, you’re already familiar with the approach many of its server controls take. You have access to a set of properties that allow you to define arbitrary templates of content, complete with HTML, server controls, and data binding expressions. This model makes it very easy to create dynamic UI that is rendered server-side [Advance Animation].

ASP.NET AJAX 4.0 introduces the ability to define templates as well, but purely client-side. Now you can create the HTML markup you want to use for representing your template, complete with HTML and data binding expressions. In this example, we’ve created an unordered list template whose content is a list item whose content is the value of the Name property of the JSON object that is bound to it. The data binding expression resembles that of WPF.

“ASP.NET AJAX is alright, but it is way too server-centric for serious client-side development…”, One of the more common misconceptions with ASP.NET AJAX is that it has always been a server-centric framework and offered little to no value for purely client-side JavaScript development. One of the primary objectives of this presentation is to show how ASP.NET AJAX as a JavaScript library has always been useable without server constraints, as well as how ASP.NET AJAX 4.0 makes that even more of a reality by adding additional support.

When some developers think of ASP.NET AJAX they implicitly associate it with WebForms, and feel like it’s very coupled to the ScriptManager and UpdatePanel server controls. While this style of development (partial rendering) in WebForms is an available option, it’s important to keep in mind that that is simply an integration point between ASP.NET AJAX and ASP.NET WebForms. If you’re already using WebForms, partial rendering provides a very easy starting point for introducing AJAX-like functionality to a web application.

That said, ASP.NET AJAX can be used outside of the context of WebForms, because it is ultimately just a collection of JavaScript files that can be referenced within a web page. It’s true that Visual Studio provides rich support for using ASP.NET AJAX, but there is no reason to treat ASP.NET AJAX any differently than any other JavaScript library (i.e. jQuery, Prototype, etc.)

Taking a pragmatic look at the existing ASP.NET AJAX release, we recognize that there are some things missing from it that are really necessary to begin doing any serious client-side web development with it.

There needs to be a stronger offering in terms of client-side controls, which ideally would also provide the same level of templating and data binding that the server controls in WebForms provide. In addition, because JavaScript is a client technology, communication between the server needs to be extremely easy, such that developing with JavaScript, and taking on the tax of an additional tier, becomes simple enough to warrant the benefits it provides without overloading the time it takes to create.

Finally, ASP.NET AJAX really needs to become modular in the sense that developers can pick and choose what pieces of the framework they want to use, or need for that matter.