Difference between a Postback and a Callback

Question

I keep on hearing this words \'callback\' and \'postback\' tossed around.
What is the difference between two ?

Is postback ver

Answer 1

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

The answer is YES. Postback is a "term" specific to Microsoft's ASP.NET But 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.