Partial Rendering Misses AJAX Architectural Points
Partial rendering is one of the two approaches that ASP.NET AJAX propounds. It works by applying the Interceptor pattern and hooking up the submit event of the form. The event handler then kicks in and operates the intercepted request via XMLHttpRequest instead of going through the browser. From the perspective of the ASP.NET runtime, business is as usual. So the request goes through the usual lifecycle and fires Init and Load events, and handles the postback and updates the viewstate. Undoubtedly, it keeps flickering out of pages and contributes to an overall greatly improved user experience. Undoubtedly, it is relatively cheap both in terms of required skills and impact on existing code. Properly optimized, it can lead to significant bandwidth improvement.
Should we call this AJAX?
AJAX is about a change of paradigm for the Web where we place requests-for-data instead of submitting forms-for-pages. Nothing of this happens with partial rendering. So should still we call this AJAX? And, frankly, does it really matter? Architecturally speaking, partial rendering is not AJAX for the simple reason that the underlying application model remains the same. There's no new architectural point in partial rendering. But partial rendering remains an excellent way to enhance existing applications.
Can we simply conclude with a sounding "Who cares if it's not pure AJAX?"
Partial rendering still misses some of the key features of AJAX--one in particular. So a model that doesn't support concurrent async operations, should be labeled as pure AJAX? I don't know whether we should or not. Partial rendering has many strengths, including that of simplifying the development of an AJAX-based user interface. However, it doesn't allow concurrent async calls. If you place two consecutive clicks for postback and the second fires before the former has terminated, then the ongoing call is aborted to make room for the second. Why is it so? To avoid breaking the viewstate and the overall consistency of the state. On the other hand, the pre-AJAX web works by making one call at a time. Why should partial rendering then be different?
What does it mean to you?
Use partial rendering whenever you feel, but be aware of its inherent limitations. In practice it mostly means that you have to disable all controls that can fire a postback during a refresh. If you need multiple calls at the same time, use then script services and trigger them entirely on the client via JavaScript. And as a free additional tip, avoid doing polling via partial rendering. In other words, avoid the use UpdatePanel with Timer controls, unless strictly necessary or if it's the minor evil. The issues are viewstate and bandwidth. Potentially too much data moving over the wire too frequently. A script service commanded by a client-side timer (the old faithful window.setTimeout) would do the job more efficiently.