My first experience of AJAX-enabled web pages was back in the days of .NET 2.0 (VS2005 with the ASP.NET 2.0 AJAX extensions) and involved making calls to ASMX web services and handling the asynchronous results in the client script, usually injecting HTML directly into a div or other element on the page. Although we were in completely unknown territory, the benefits were lightening speed and efficiency because you only returned the markup or JSON you needed and nothing more.
So for AJAX to work, the minimum requirement is that a page must have one and only one ScriptManager control. Then it needs an UpdatePanel which contains the controls to be updated asynchronously. When one of the child controls generates a postback event, the UpdatePanel catches the event and re-submits it as a partial postback. However the same behaviour can be applied to a server event occuring outside the UpdatePanel, by associating it with a trigger.
Unfortunately nothing in life is free, and this simplicity comes at the cost of efficiency. For server-side page event handlers to be able to access data during partial-postbacks, some or all of the web form’s view state still has to be posted back to the server. So bear this in mind and try to limit how many partial-postbacks you do (especially when a timer is involved). The important point is that although there is not a huge saving in how much data is sent to the server compared with a normal postback, it still provides a better user experience with no page flicker or waiting for the browser to refresh.
The following code displays the current time in a browser which gets updated at 1 second intervals via partial-postbacks. This is purely an example and you would never generate this many postbacks in production code (ASP.NET AJAX page methods are a much better choice for this kind of scenario).
Web form markup (client):
Code behind (server):
And here is a slightly more advanced example showing how to use a trigger to respond to events from a control which is not contained within the UpdatePanel. The appearance in the browser is identical to the markup above, but the purpose of triggers is to solve situations where you might have a lot of markup in your page which you can’t or don’t want to reorganise inside an UpdatePanel.