Here's my take on your paradox and ASP.NET:
I tried User Controls and found their lack of design-time support to be disappointing.
I still use them for some things, mostly as a convenience, but not for most things.
I then moved to Server Controls and found them to be almost the perfect answer.
They aren't hard for experienced developers to write (probably hard for scripters),
and they almost always provide full design-time support for rest of team (designers).
However, they were not a good solution for encapsulating page headers and footers,
since things in the <HEAD> section, like stylesheet links, are ignored in the designer.
So, now I use User Controls for mostly content-only types of things for their simplicity.
This allows anyone to maintain them, they can be cached, and site is not restarted.
I use Server Controls for more complex situations, especially for any design support.
I.e., my site has a Button Server Control that is great for designer-types to work with.
I think that this is the preferable solution for teams with capable developers on them.
However, the overall site look and feel doesn't get design-time support in any solution,
so I gave up and moved it to base page classes instead of user or server controls.
At first I really wanted my overall stylesheet and common menus in every page,
but after a while you get used to these things not being present until rendering time.
It forces you to focus on the page-specific details, and encourages use of CSS styles.
Dependency on site layout during each page design can lead to poor assumptions,
especially on sites that allow personalization, or multiple stylesheet options like I do.
So, I don't know that I have really solved your paradox, but I came to terms with it.
As for the performance advantages of rendering:
Consider this most basic page event order: init, load, prerender, render, and unload.
Every user and server control must go through this entire sequence (and others too).
Also, note that every block of literal HTML in an .ASPX page is a literal user control.
What if you can skip the init, load, and prerender stages, and go straight to rendering?
My base page class does just this -- the header (and menu) and footer is only rendered.
I ran tests (using trace for tracking the execution time) to compare the performance of
pure html, old-style includes, user controls, server controls, and page inheritance too.
Page inheritance tests included cases for dynamically adding controls on init or load,
straight rendering, and even the complex page template case of Jonathan Goodyear.
The best performer was straight rendering using page inheritance, with pure html and
old-style includes being the next best case (these are essentially one literal control).
Of course, pure html provides no reuse, and old-style includes are out of favor now.
The worst performers were always those with the user controls, and especially the
complex page templating techniques that require multiple user controls to be used.
There was a slight advantage if delayed user controls until load, or prerender better.
Server controls were also slightly better than user controls, but not by much either.
All of these issues are actually quite minor, but each control (literal, user, or server)
does increase this performance hit slightly, so it pays to at least be aware of it some.
My point is that common site headers, menus, footers should be optimal performing,
while the page-specific details make more sense to use controls and their positives.
I hope this helps some. I am trying to get permission to write an article on this stuff,
but so far the magazines are content with the published page templating techniques.
Thanks, Paul Wilson
Thanks, Paul Wilson, ASPInsider, MC**
For the best .NET code, examples, and tools, visit:
WilsonDotNet.com, WilsonWebPortal.com, ORMapper.net