Client-centric vs. server-centric programming in ASP.NET "Atlas"
ASP.NET “Atlas” offers developers, primarily, two ways to develop AJAX applications. For the sake of this post I’ll call them the “server-centric” and “client-centric” approach. So which one should you chose? The answer, as with all things software, is of course “It depends.” The goal of this blog is to introduce you to both. This post will be followed by a series of blogs/screencasts highlighting the “server-centric” approach. I’ve already demonstrated the “client-centric” approach through my Mashup 101: Virtual Earth and ASP.NET Atlas (Part II) blog/screencast. However, once I am done with the “server-centric” series, I will drill into the “client-centric” approach (which will include another series of blogs/screencasts).
Before I explain each, it is important to understand that the “complete” ASP.NET “Atlas” framework consists of both new server side as well as new client side bits. Here’s a high level view of the architecture of the framework:
I put the word complete in quotes because it is possible to use the “Atlas” Client Script Library without ASP.NET on the server. Shanku Niyogi shows an example of how to accomplish this with PHP here. However, as you will see, there are many compelling reasons to leverage the server bits (even if you decide to use the “client-centric” approach).
In the “server-centric” approach, you spend your time writing code on the server in your favorite .NET language. During initial page rendering, the server emits markup and JavaScript which is sent to the browser. The JavaScript sent to the browser targets the “Atlas” Client Script Library. The “Atlas” Client Script Library is used to post data back to the server. A traditional postback would cause the page to flicker and be completely repainted. Instead, the “Atlas” Client Script Library uses XMLHTTP to postback. During the postback, your .aspx page runs through its server side events. The markup and JavaScript that is new (or has changed) is sent back to the browser. The “Atlas” Client Script Library then injects these deltas (the new markup and script) into the existing page in the browser. This process is repeated as users interact with the page. The key benefit to this approach is that the learning curve to e AJAX applications using ASP.NET is practically non-existent. All the hard work has been done for you through new ASP.NET server controls. What’s even better is that the “Atlas” team followed a principle that says you should be able to AJAX enable the existing ASP.NET server controls. I will walk you through these controls in my next screencasts. I’ll start posting them this week.
Much like the “server-centric” approach, during initial rendering of the page the server emits markup and JavaScript. However, instead of sending data and receiving markup/script to inject into the existing page, the “Atlas” Client Script Libraries then send data and receive data. The “Atlas” Client Script Libraries allow you to make asynchronous calls to web services with a few lines of code (there is an example of doing this in Mashup 101: Virtual Earth and ASP.NET Atlas (Part II)). All aspects of the UI behavior are handled on the client, inside the browser, using JavaScript. The “Atlas” Client Script Libraries introduce a number of new concepts to JavaScript that enable a much richer programming model within the browser such as a rich type system, base class library, networking services, declarative scripting using “Atlas” XML script, template data, and two way databinding to name a few. The “Atlas” Client Script Libraries also introduce the concept of client side components and controls. Client side controls abstract HTML much like ASP.NET server controls do. This allows for the concept of a TextBox client side that has a similar object model as the ASP.NET TextBox server side (ex: each has a Text property). This also offers a consistent way to extend HTML by defining new controls that just don’t exist in HTML (ex: the Virtual Earth map control used in the aforementioned screencast). Overall, the “Atlas” Client Script Libraries make the experience of having to go back and forth between a scripting language client side and a managed language server side much more bearable since you have parity in terms of concepts, controls, etc. The best part is that this is all built on top of a browser compatibility layer that works in IE6+, Firefox, and Safari. There’s a lot to dig into here. Stay tuned!
In summary, If you are an ASP.NET developer who wants to do AJAX programming (or AJAX enable an existing application) while using the server control programming model you are already familiar with (without writing JavaScript), then you will probably like the “server-centric” approach. If you are a .NET developer comfortable with JavaScript programming, you want more control over what’s happening on the client, with a simpler way to write client side UI logic, then the “client-centric” approach is for you. Of course, you’re not limited to choosing one over the other. Mix and match as you see fit!
I suspect most developers will start AJAX enabling their ASP.NET applications using the “server-centric” approach first. Many may never use the “client-centric” approach. It just depends on how adventurous you get with your ability to create compelling new user experiences previously reserved for those in the “AJAX Know.”
-Marc