Postbacks or Not?

I had an interesting conversation with a couple of TechEd attendees on the subject of whether or not to use postbacks in a Web application.

At the core, the issue was that postbacks degrade the end-user experience: the back button doesn't always make sense, the resulting flicker, the loss of scroll position and focus. All real problems. These folks I talked to had completely replaced postback usage with their own client-script framework they invented on ASP.NET v1.1 to send data down to a Web service hosted on the server, and update the UI based on the results.

Postbacks seem more natural for things like simple data entry forms, search engines - things that HTML and the current generation of browsers were designed for. But postbacks are infact truly the wrong thing for expanding a tree node in a dynamic tree, or navigating rows in a grid. I do see the appeal of the non-postback world. You navigate to an application, and from there on the UI comes and goes, or rather changes with smooth transitions. No more flicker, or unexpected enabling of the back button, simply because you clicked a Submit button.

<tangent> Thinking a bit about navigation, and the address bar. What if the address bar continued to indicate "foo.com" regardless of hyperlinking around to a different section of the current screen, or some other physical screen. Its all the same logical app, "foo.com," anyway. Essentially the server sends down an "app" whose UI morphs as you postback, or navigate. Curious to hear the opinions and thoughts on the feasibility of this model. Should Web applications head down this route? </tangent>

Postbacks happen to be a core aspect of the Web Forms framework. Both the lifecycle of a form and the associated event-based programming model revolve around postbacks. In general, things work better when you go along with the flow of the underlying of framework. To that end, we're doing various things in Whidbey in the Web Forms framework to improve the postback model.

• We can maintain scroll position.
• We can maintain which control had focus, and restore focus, or allow server code to focus a new control (coupled with our validators now being intelligent enough to automatically set focus on the control in error).
• Introducing a new feature called "Callbacks" that can be used by server control developers. Essentially this allows a control to asynchronously fetch data without causing postbacks, which allows controls to be smart about when they use postbacks. More on this in an upcoming post.