Towards more processing at the client-side
Currently at my day-job, we’re architecting a framework to make ASP.NET a better ASP.NET. Basically, this fx is being used by developers to port just too many intranet/internet web applications to the .NET universe, for a just too big worldwide company. One of our key goals while architecting it was to move as much processing to the client as possible; we did a lot of work in this regard, which involved providing a client-side framework and lots of enhancements at the server-side to actually take advantage of it.
Current versions of ASP.NET don’t really make the browser do much JavaScript stuff at all which translates to writing all your code at the server-side and having to cause a postback for almost anything you want to process. But life would be much better if -whenever possible- no postback occurred, or at least just a “soft” one (more on this later).
Do you think you really know JavaScript? Take a look at the inner workings of a project like Tibet, and think again. It would be really useful to count with some base library at the client-side to make interaction between the different controls and the page simpler (abstracting you from browser-specific related issues) and cut as much as possible the dependency on posting back to the server. Of course this would require developers to have some understanding of JavaScript beyond the alert function… but it would definitively pay in the long run.
Moreover, the Microsoft XMLHTTP component (or Netscape’s verbatim XMLHttpRequest) can really help in avoiding entire postbacks and ugly UI refreshes at the browser to happen (yes this is what I previously referred as a “soft” postback). Keep in mind that today every control that fires a postback, causes the entire form collection to be posted and lots of processing to happen at the server-side; two particular expensive things that are really not necessary all the time.