Difference between a Postback and a Callback

A Postback occurs when the data (the whole page) on the page is posted from the client to the server..ie the data is posted-back to the server, and thus the page is refreshed (redrawn)...think of it as 'sending the server the whole page (asp.net) full of data'.

On the other hand, a callback is also a special kind of postback, but it is just a quick round-trip to the server to get a small set of data (normally), and thus the page is not refreshed, unlike with the postback...think of it as 'calling the server, and receiving some data back'.

With Asp.Net, the ViewState is not refreshed when a callback is invoked, unlike with a postback.

The reason that the whole page is posted with ASP.Net is because ASP.Net encloses the whole page in a <form> with a post method, and so when a submit button is clicked in the page, the form is sent to the server with all of the fields that are in the form... basically the whole page itself.

If you are using FireBug (for Firefox), you can actually see callbacks being invoked to the server in the Console. That way, you will see what specific data is being sent to the server (Request) and also the data the server sent you back (Response).

The below image illustrates the Page Life Cycles of both a postback and a callback in a ASP.NET based Website:

_{(source: esri.com)}

A postback occurs when a request is sent from the client to the server for the same page as the one the user is currently viewing. When a postback occurs, the entire page is refreshed and you can see the typical progression on the progress bar at the bottom of the browser.

A callback, generally used with AJAX, occurs when a request is sent from the client to the server for which the page is not refreshed, only a part of it is updated without any flickering occuring on the browser

A lot of this discussion is ASP.NET gobbledygook language....

The answer is YES. Postback is a "term" specific to Microsoft's ASP.NETBut remember, vendors like Microsoft wrap their OWN versions of these processes around their own implementations of them, confusing us all as to what REALLY HAPPENS in the Http/Html world.

Their version of POSTBACK is basically a traditional HTTP POST request sent back to the originating server. But in ASP.NET they do it by sticking a gigantic FORM HTML element tag (with POST method attribute) around the whole web page rather than traditional form controls in one tiny part of a web page. They do do this because they are using the HTTP specification to maintain "state" of their page and its controls, and to make sure the whole page, even the traditional non-form field markup, comes back intact.

Unfortunately, this sends a HUGE amount of unnessary data over the wire such that their VIEWSTATE and its sister POSTBACK in the page has come to be viewed by many as a waste of bandwidth and a sloppy way of implementing web page state. I can show you that most modern browsers and website, if designed using cacheable CSS and consistent HTML markup, will return page state quite naturally using the browsers native HTML cache. ie Full POSTBACK is often unnecessary.

CALLBACK is just JavaScript. Its just ECMASCRIPT circus tricks ASP.NET stores in what they call their AJAX API in gigantic JavaScript libraries your browser downloads from the server, and which ASP.NET developers unknowingly pack into their web pages to trigger changes in a web page without full POSTBACK. The ASP.NET API for AJAX just creates all this massive Javascript that's on the client-side and which gets triggered in the browser when the user changes something, rolls over something, or clicks something in the browser triggering traditional JavaScript browser DOM events, which then ships a giant load of JSON or other data back to the server to process. That then gets returned and accepted by the Javascipted libraries and objects in memory in the browser, and changes parts of the users web page and markup.

Its said some 5-10% of users and browsers have Javascript disabled so all this JSON and AJAX would crash and burn for those people. ie CALLBACK would not work.

That's what goes on behind the scenes. Much of it is overkill, if you ask me. And thats why Web Control models in ASP.NET have been criticized in the past.

If you abandoned ASP.NET for a second, you could write a simple FORM field yourself in an HTML web page with a single textbox and button and press it and watch it post to the server, exactly like an ASP.NET page would do but faster and simpler. That's what real POSTBACK is. The browser naturally sends the server the necessary POST HTTP Header to do so, but caches the HTML in the rest of the page, so it renders lightning fast on its own.

For CALLBACK you could just add a simple Javascript/ECMAScript code to that same HTML page where, when the user rolls over some text or button, clicks, or changes a form field, the web page doesn't POST, but behind the scenes you have Javascript send something up to the server. How you handle that via your own JavaScript, JSON, or libraries is another deal. But its not magic. For people with no Javascipt or Javascript disabled you should design pages with no CALLBACK and just cache any changes that return when form field controls or hyperlinks are clicked. Its one reason to reconsider callback routines though most modern user-agents now are setup for ECMAScripted website routines.

That's what confuses people......these vendor implementations of very basic HTTP requests and Javascripted tricks get layered into language thats not clear. It then causes people to build monstrous web applications that do all this unnecessary stuff that very simple coding would solve.

I still use and recommend ASP.NET. It's come a long way and a great system. But it would help if more people understood the basics of what they do before using them as these frameworks can be customized and simplified quite a bit to improve them if you see whats really going on under the hood.