Notes on the MS "client-centric" web UI development.

Night changing in the morning and here I'm, caught in the tenets of a client-centric web UI development.
A bit of history and present:
We are using UpdatePanels approach heavily, narrowing down roundtrips with Conditional, keeping Viewstate on the server, and employing compression.
We are using a massive range of AjaxControlToolkit controls.

Breaking point:
Performance and complexity wise you can only go until the certain point with UpdatePanel. The price of the sending your whole page back to the server and retrieving "only" markup needed to refresh the update panel DOM can be really high.

One of the recent project requirements were to build tables in the UI, both plain and master-detail. No paging allowed, scrollable div to be used instead. Range of data - 100 - 1000 rows, plus detail rows when master-detail is to be used.

When we estimated the UpdatePanel solution we saw that Viewstate is actually 200KB for the set of 500 rows. OK, we can keep this one on the server (would require sticky session or session service or sql persisted session for load balanced scenarios as an extra downside), or we may not use Viewstate at all in this case.

BUT!!! What you can do with 800KB of markup data to be sent to the client to update the UpdatePanel with a GridView??!! Applying compression would bring it down to 100KB, but still...Add to this 3-4 seconds it takes to rebuild the DOM ...

It is probably the right moment to remember yourself 9-10 years ago when there was no ASP.NET and a comprehensive set of server-side controls so tempting to use.

And then you read some book on Javascript and ASP.NET Ajax to refresh and update your knowledge. And then you understand that it is a lot of work to do given the current state of MS "client-centric" web UI development.

Hearing about Json before you try to serialize the same data and see that data volume to transfer is actually only around ~100KB for the same 500 rows! This is qualitatively better!

Ok, so now it is time to create your "client-centric" UI structure, let it be table or a drop down. What are your choices here? Dojo :):)? I found this to be the most compelling for me:

AjaxDataControls in conjunction with ASP.NET Ajax Futures.

If I had to create my "client-centric" own library (which I thought I'd had to), I'd create it in a way how dotnetslackers created it. Combination of a client and server side programming model with crisp separation. Use of ASP.NET Ajax where possible (both RTM and current CTP of Futures, but only the script files, no installation of "Futures" required.)
I'm simply enjoying working with AjaxDataControls library, everything well prepared for changing and expanding, though I found myself few times rolling back my changes when actually seeing in the middle that I can achieve the same with just APIs guys have already implemented.

This is an interesting road, I'll continue with logging pitfalls and amusements I have experienced moving along so I can refer to it myself in case MS would not obsolete the need in the next 9 years :).