Blog

Every day new sites with AJAX appear and it looks like AJAX had come to stay. ASP.Net, as every other reputable web framework, must take it into account. It must provide the right tools to every scenario. What are the scenarios then?

HTML

Until AJAX gained momentum, this was the only possible scenario. If you take a look at most Webcontrols of that “time”, the native ones included, you’ll see that the entire framework was designed with this and only this in mind. Yet, it tool into account several factors like the browsers “divergencies”, or shall I say non-standard compliants? Well besides that there was little to worry about and only one things todo, output html that works in every browser and handle the litle differences.

AJAX

Now there is AJAX. What does this mean really? We already have controls that make use of AJAX, and controls that are fully AJAX enabled. What does fully AJAX enabled mean? Well, to me it means that you can create that control enterelly in the client-side, using JavaScript of course. So the main concept is that you shall be able to provide the data and the properties to the client and the control should be build on client-side.

The Problem

The problem is that you have to build the html-build-logic twice. You have to do it on the server-side for several reasons including either disabled javascript clients or the old-browsers support. On the other side, you should be able to build that control entirely on Javascript because the control can be an anwser to a client’s request.

Currently there are several AJAX toolkits that mostly “capture” the control’s output on the server-side and send the raw HTML to the client, but thats hightly inefficient, specially if we’re talking about a datagrid with lots of records. This can mean a lot of bandwidth waste, as well as server resources, based on the fact that the server could process only the data, send it and the client could build all the UI.

So, if you wanna to do things right you’ll be doubling the effort of the end-tier, the logic that builds the UI.

I really think that this bring us to another, more conceptual question, that is where does the UI building process really belongs to. If you look at any paper that describes the three-tier structure you’ll find that the UI process is always on the end tier and if it is, for example, Windows Forms it belongs to the clients computer. But if we’re talking about the web the clients computer is on a fourth tier, not really included in the theory.

I believe that more that bringing faster and advanced user interfaces is bringing things to the right place when it comes to the place where things really belong to. The only problem I still see it that for one reason or another, about 10% of the user, on some stats, have javascript disabled. This is the major problem and one reason to delay a process that could help us moving to the next Web version.

The data processing and a lot of the processing logic really does belong to the server side. But not the UI building process. On an ideal world the server will only generate data and send it already processed to the client that actually builds the UI. Additionally it will process the events and gather the data needed because of the user’s request/actions. This opens many doors to reduce WebServers bandwidth and CPU usage as well as opening new, easy, doors like the hability to have client-side site themes.

One clear example of this idea is the success of Atom and RSS feeds. What they really do is to provide you with the, and only the, data you want. You request a feed for a specific author, category, search, etc… and the server will provide you with the data you’re requesting. The actual UI where you see the data is subject to your preferences. You can see it in raw, on a desktop application or on a pretty and fully featured web interface. Doesn’t really matters to the server.

This entry was posted on Saturday, October 21st, 2006 at 18:36 pm and is filed under .Net, ASP.Net, Design, Mono, Monologue, Web. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.