Remote Scriptease

Postbacks and view state are two fundamental notions of ASP.NET which ease web development a great deal. Thanks to the postback processing model you don't have to parse the query string anymore. Thanks to view state you don't worry about repopulating controls with data on each roundtrip. Processing forms on the web has never been easier. However, excessive postbacks deteriorate usability, while large view state degrades performance.

In the ASP.NET school of thought postbacks are encouraged. They are easy. ASP.NET does all the dirty work of extracting data from the from or query string and putting in the right page controls.

A while ago Microsoft made available a bunch of free ASP.NET server controls, among which were a tab strip and menu controls. The menu control would post back on every single click. I was simply horrified. We can do better than that.

Dino Esposito wrote an article titled Script Callbacks in ASP.NET which talks about improvements to the postback model in ASP.NET 2.0 and how we can simulate it in ASP.NET 1.1. The idea boils down to this:

First and foremost, you need to set up a parallel HTTP channel for sending the request and getting the response. The new request should be invisible to the user to avoid any interference with the displayed page. Finally, the response you get from this invisible request must be merged with the current page through dynamic changes to the document object model (DOM) of the page.

As I read the article I couldn't help thinking how convoluted postback processing in 2.0 was (it's not Dino's fault, don't get me wrong). Relying on the good old Microsoft.XMLHTTP is a good call, but we're back to using new ActiveXObject() and such. I hope we won't get stuck with this lame nomenclature of "downlevel" and "uplevel" browsers any longer.

Alternatives

Dino also mentions alternatives at the beginning of the article. One of them is Microsoft's Using Remote Scripting. I don't know why he's surprised it never caught up, but calling a Java servlet from a client-side script has several implications. Not having Java installed is one of them.

Another alternative is WebService Behavior, but again, behavior files (.htc) are supported only by Internet Explorer.

I started digging deeper and came across Javascript Remote Scripting (JSRS) by Brent Ashley, a client-side javascript library. It's light and it works across a wide range of browsers.

I also found an article at CodeProject by a guy who wrote an assembly to process remote calls placed by this library. The assembly works great and it's easy enough to set up JavaScript calls. Of all the approaches I've seen this far, this one seems to be the most acceptable one.

Seeing is believing, so make sure you check out his demo.

Recommendations

I've tried this code and would like to point out some gotchas. It's better not to mix JavaScript remote calls and pages that postback a lot. Sometimes, the view state does not reflect your changes made via DOM. A post back will roll them back to what is in view state.

For example, if you modify a dropdown via DOM (add or delete items, sort them differently) and then a postback occurs, your changes will be lost. You may as well disable the view state on it and save yourself some bandwidth.

I encourage you to give this library, JSRS, a try. It's a great step toward improving usability and reducing reliance on postbacks. If time allows, I'll cook up some useful sample.

You bring up some excellent points in this article. I have been using my own remote javascripting routines in an app I help maintain for quite a while now, and it really does cut down on bandwidth usage while improving the user experience greatly.

The demo you have linked to is a good example. I hope to see a demo out there that shows a much larger list returned using JSRS, as this is where the real power lies. When you have a page where you may want to have a list of thousands of options in a drop down, but
the client may not actually need that specific list at the time he or she is viewing the page, it is pointless to download the list, "Just in Case." Remote javascripting lets you bring that data in only if it is needed, and the initial page rendering is always much faster since it doesn't need to load that huge list in every time a user visits the page.

With the advent of DHTML, this is a fairly simple process. There are some pitfalls in communication, but once the security model is understood, this works very nicely. I'm sure it would be possible to create a server side control in .Net that would simplify this process, and even allow a sort of post back routine to run in each remote JS frame. (By the way, for those who are running SSL on their servers, remember to set the src of the iframe to either a blank page on the server, or to "javascript:false;" so that there isn't that "insecure content" warning.)

This is interesting. I would like to have my client side javascript call a local web service method. Is this possible? How can this be done? (I can't use IE, the system is OSX.)

Call a web service from JavaScript? Hmm, this can be tough. I know Microsoft wrote a behavior file (.htc) that does this, but it's IE specific, of course.

I'm afraid you're on your own to define an interface to a web service from client side script.