A case for partial rendering

I've been seeing more and more authors lately dismissing partial rendering (a.k.a. UpdatePanel) as a poor man's version of Ajax, something you should only choose if you're too lazy to implement "true" Ajax.

I think that view not only has a slightly pedantic ring (isn't laziness one of the most powerful driving forces in computer science? isn't it perfectly ok to choose the most productive approach in some contexts?) but also misses the point that there are cases where server-side rendering absolutely makes sense.

For example, search engines don't execute JavaScript today, which means that if you're doing all the rendering on the client, your contents won't be indexed. If you want search engines to index your site properly, the contents must be included in the GET response, preferably in nice HTML. That simply means that contents must be rendered on the server during the GET request in order to be picked up by search engines. If you also need to update that same contents later, doing it on the client from pure data means that you need to have the rendering logic reproduced in client code. The easiest way today to only write your rendering logic once and make it work both on the GET request and on subsequent out-of-band requests is partial rendering.


  • Something called "degradable" AJAX?

  • @Andrei: yes. There are many ways you can achieve that, but UpdatePanel is an easy one.

  • are you actually talking about the AJAX updatepanel or the asp.net 1.1/2.0 feature that lets you output cache a page then define control which update (can't remember the proper name for this feature)???

  • @JA: UpdatePanel (as should be clear from the first sentence in the post ;)

  • I don't know that the SEO case is a good one to make. Other than some fancy improvement to the LinkButton, most of the controls that trigger postbacks (or partial postbacks) are going to be disregarded by search engine spiders anyway.

    That said, I do use them for progressive enhancement sometimes myself. Usually only in scenarios where I can disable ViewState. It's nice to know that users with JavaScript disabled or XHR not available can still submit the form and get a traditional postback with the same results.

  • I do believe that UpdatePanel is the poor man's AJAX which is easy to implement. The reason it is not a great solution is the fact that it still pushes around the ViewState and a consequence of that is only one request can be processed at a time. You basically have to manually queue up the requests on the client-side if you know the ASP.NET AJAX client-side API well enough to do so. (Queuing is handled automatically by Telerik control, for example. MS AJAX should have made this a simple option.) Alternatively, you can use the ScriptResource attribute on web services to convert web services into JavaScript proxies that can be emitted through the ScriptManager. You can make multiple calls on these proxies which does not require ViewState and it also does not instantiate the control hierarchy on the server-side. You can even use the LoadControl method to instantiate a UserControl in a web service method and return the markup for the control. The downside is that you cannot get that markup to work in the PostBack model. You have to make a decision to live with PostBack or break out of that model. I will use both depending on the conditions, but I do lean toward the AJAX-ified web services because they are truly asynchronous and the data transfered is significantly smaller. In one case I was polling the server and the response was as small as 1 byte, versus what is typically 10k to 60k with an UpdatePanel.

  • Please show us ASP.NET web sites that fully support degradable AJAX with UpdatePanel. Not only first-time rendering and calculate efforts involved in it.

    UpdatePanel doesn't introduce degradable AJAX, it only allows you to render first-page.
    If you say it will be indexed properly by search-engines, you are probably wrong.

    Think about AJAX-paged grid with list of products.
    First page will probably be indexed, but not all others.
    So what's a point?

    Only humans can do all properly.

    With MVC (ASP.NET MVC, or MonoRail) it is much easier to implement fully AJX degradable site (using ViewComponent (MonoRail) or UserControl).

    I don't say UpdatePanel is evil (thou I often think about it). It is very productive way even if it is just against the AJAX-theory. But later or earlier you'll find you need to improve performance, make page REST-full etc.

    UpdatePanel is just a good idea to *workaround* AJAX non-availability in WebForms.

  • I know that the term laziness is used a lot in software development, but I like the term "avoiding waste" or productive better. It is not only perfectly ok, it is far better to use the more productive approach, combined with continuous improvement.

    In this case, implementing "true" Ajax (i.e. lower level Ajax) often drives up complexity and delivery time while adding little value to the process and maybe the Ajax-enabled feature is not even useful to begin with. While UpdatePanel, on the other hand, often provides all of the value that your customer requires (i.e. faster/more responsive interactivity, but maybe not the fastest or leanest possible), but with little effort. If it is a business critical pipeline then the MS Ajax framework allows you to go lower level / “lean” Ajax at that point. In short, when using UpdatePanel the “pros” far outweigh the “cons” for a wide range of applications in WebForms in my opinion.

  • @Dave: sure, you shouldn't hide contents that you want indexed behind postbacks, but that doesn't make my case any weaker.

    @Brennan: I think you're missing the point. I'm not arguing that UpdatePanel is the best solution in all cases and you should always use it. What I'm arguing is that there are *cases* where it makes more sense (and having ViewState can be a good thing too). As a side note, you might want to take headers and request into consideration when you make network traffic measurements: there is no such thing as a single byte request.

    @Dmitriy: sure, it's not enough and using UpdatePanel is not the only thing you need to do if you want to optimize for search engines. But it does help. You cite MVC, but you can also just handle pagination with plain links. One thing that works well is to have links with an href such as "page.aspx?p=2" and an onclick such as "goToPage(2)", which enables Ajax pagination and search engine crawling at the same time.

    @Danijel: there are plenty, but just to cite one, you can look at Michael Schwartz's or Dino Esposito's blogs.

  • I think you have to use an update panel if you want to use asp.net validation controls. I researched for days trying to find a way to use the validation controls with the web service pagemethods approach and it couldn't happen as far as I can tell. If someone knows how to use the validation controls with asp.net ajax web services then please post up how, otherwise I continue to use update panels..

  • I will tell you a story about partial rendering with UpdatePanel. I was asked by our client to make a report that can have some column or row categories collapsible. Basically it was a big table with lots of data in it. I made the control, I tested it with postback, it worked, then I added an UpdatePanel and watch it display without flicker, but about two or more times slower!

    I was flabbergasted. I tested it again, more thoroughly, and I noticed that the same thing did not happen so bad in FireFox. As I knew about a similar problem from before, I used a similar solution: I changed the style.display property of the div containing the updatepanel to 'none' and I changed it back to null with RegisterStartupScript. And voila! An increase of 50% in speed with some flicker :)

    In other words, don't attack the UpdatePanel, when in fact it may be a browser issue. I would like an IE option to disable visual refresh for some or all elements, then reenable it...

  • hum...well, I still believe that an asp.net ajax application shoud have...several pages :) this would solve the indexing problems, right?

    regarding the page refreshing, I concede that the UpdatePanel might be the best solution if you're worried with security (ex.: you're getting data from a secure web service and calling it is really really much easy on the server side). should you use the updatepanel: well, it depends. I'd say that there's nothing wrong with it if you know what you're doing.

    should you always *use* the update panel:no.

    should you prefer JS code+webservices over updatepanels: the correct answer would be yes, but we all know that there are other factors that might make using the UpdatePanel a better option (ex.: if you're working with 2 more people and none of them understands why if(i = 1) is true, the panel is the way to go)...

    PS: i do really admire the UpdatePanel. It's really great and it really makes partial postbacks available to everyone. I guess that I stoped liking it when MS tried selling it as the best AJAX approach and stopped developing the client side of the framework to polish the server side (ie, the UpdatePanel and friends )

  • @Luis: I think you're almost completely wrong :)
    Having several pages solves part of the problem, yes, but only part: each page must still have the contents included in the GET request, which a "pure Ajax" page wouldn't. On having several pages I agree with you as I'm no big fan of single page interfaces if the site is a content site. If it's a non-contents application, you probably don't care about indexing anyway.
    I don't get your argument about security: information that can be accessed through an UpdatePanel is not any more secure than information that can be accessed through a web service is it? Am I missing something?
    Again, I don't think you should always prefer JS and web services over UpdatePanel, for the reason I expose above, for the productivity reason, because it can actually be faster to render on the server in some cases, I could go on.
    Finally, I'd like to know who in the team ever said that UpdatePanel was the best Ajax approach... And what makes you think that we stopped developing the client-side of the framework??? I'm developing it right now, at this very moment, so I'm more than a little surprised by this assertion...

  • I agree the search engine part, but I am just a firm believer that client-side script is the only way to go if you want your web sites to be truly ajax'ed.

  • Anyone have a link to an example of a site using ASP.NET AJAX that gracefully degrades when javascript is turned off (progressive enhancement)? I'd appreciate it. Thanks.

  • @James: I don't have a specific address to give you, but try to put a couple of controls and buttons inside an updatepanel and navigate to the page without JavaScript. Should work just fine.

  • One mistake you made: the update panel requires a postback in most common scenarios right? So it actually will only allow spiders to fetch the first content, not the rest (after updates of the panel).

  • @Mike: I never said otherwise. I think you missed the point, which is that on the GET request, if you do "pure Ajax" you don't get anything indexed. And if you look at Stefan's comment just above yours, he describes how you can have postback links that degrade to regular links in the absence of JavaScript, which enables search engines to follow and index them.

Comments have been disabled for this content.