Postback or Callback?

Question

I was wondering what to take into consideration when deciding between a full postback or a quick callback.

There are two extremes: You could do it the "old" way, where every user action causes a full postback. Or you could conceivably ajaxify your whole web application so as to never cause a full postback.

Both options don't seem to make a lot of sense to me and I usually do what feels right. For example, I use a callback for a quick user action like rating an article but use a full postback for an action like editing and saving an article. But doing what feels right isn't really a convincing argument in a team meeting.

My question is: How do you decide what to use? Do you have any guidelines or rules? What are advantages/disadvantages of using a callback over a full postback?

Answer 1

There is a consideration of UX versus RAD - is it more important to get your app up and running, or is it OK to spend a lot of extra time building complex client-server interaction capabilities?

When you need to maintain a lot of state on your web form - e.g., each call to the server will likely need information about the state of more than just the one control which invoked the callback - postbacks are much easier. If RAD is your first priority, use postbacks in this case. But full postbacks rarely, if ever, provide a really clean UX. If UX is your top priority, you can afford to spend the time necessary to build a system which can maintain state on both sides.

Maintaining complex state on both the client and server side across multiple AJAX callbacks can be very difficult unless you use something like partial postbacks on ASP.NET, which update the ViewState for you (unfortunately those have a lot of overhead and inefficiencies since they hide all this from you).

Answer 2

General guidelines would have you use AJAX style callbacks when manipulating data inside the same logical section. Example: User Preferences

However, when moving into a completely separate logical section of a page, it is probably best to do a full post back since the underlying programming model will be simpler.

That being said, there is no right way to do this, and several new patterns such as the single page pattern have emerged that would enforce the always AJAX philosophy.

Answer 3

From a practical perspective, if you do a callback, you can't reproduce the post-callback state with a URL. For example, let's say you have a search page. If the user enters "aardvarks" and clicks search, you can redirect to foo.com/search/aardvarks, allowing the user to save or share that link. If you load the search results with a callback, this is not possible.

Answer 4

I, too, usually just do what feels right, but the root of what feels right to me is whether I'm changing to a different state or simply modifying the state that I'm in. Saving from an edit takes me from an edit state to a view state, so I'll usually do a full post of the data. Populating cascading dropdowns based on the selection in a previous dropdown is modifying data in the state, not changing state so I typically do it via AJAX.

Another thing that I typically consider is how much of the page will change based on my action. If virtually all of the page changes, then it's more likely to be a candidate for a full request since there isn't much gain over doing it via AJAX. If only a small amount is changing, then it's more likely to be an AJAX request for just that data.

These aren't hard and fast rules. I'm more interested in the user's experience than I am in following rules, but they seem to be generally true - at least for me.