ASP.NET pages are made of code, markup tags, literal text, and server controls. Based on the request, the server controls generate the right markup language. The ASP.NET runtime combines the output of all controls and serves the client a page to display in a browser. The programming richness of ASP.NET springs from the wide library of server controls that covers the basic tasks of HTML interaction -- for example, collecting text through input tags-as well as more advanced functionalities such as calendaring, menus, tree views, and grid-based data display.
When the ASP.NET platform was introduced, server controls looked like the panacea of all evil. They were just perfect for the job making a reasonable tradeoff between performance and productivity. It goes without saying that server controls make it so easy to generate complex markup for pages. All that it requires is a simple step-by-step procedure. You drag one from the toolbox and drop it on the Web Form drawing surface. You select some of its properties and set them declaratively through Visual Studio. You point the browser to the page and see the result.
Books and tons of articles have been written in the past few years to illustrate how to create custom ASP.NET server controls and how to effectively use existing controls. Then, all of a sudden, server controls seem to have lost all of their sex appeal. Why is it so?
In first place, server controls are black-boxes of markup. Using them is similar to talking using only predefined sentences from a vocabulary. You can choose how to combine sentences together; you can pick up one of many similar sentences, but you do not have total freedom of expression. Styling server controls is critical too. No matter Microsoft introduced features such as themes and skins, to gain total control of the user interface appearance you need to resort to CSS over raw HTML. Finally, server controls are necessarily bound to viewstate and the classic page lifecycle triggered by the ASP.NET HTTP runtime.
Amazingly, before the advent of ASP.NET in the late 1990s, server controls were considered a not-so-good idea because they were a server-side framework in a world that was blinking at Dynamic HTML and rich client-side, script-based technologies. Immersed in the context of ASP.NET, server controls became the emblem of productivity. And now, after having been celebrated as one of the greatest invention of the Web, they're pushed again to the corner because of their internal complexity and black-box nature.
Where's the Truth?
For sure, server controls are not high-performance tools when compared to client-side technologies. They do have, instead, a tremendous potential as far as productivity is concerned. Nothing that has happened in the industry in the past 18 months has changed these facts. So why server controls seem not to be so attractive anymore?
It has to do with expectations of developers; and not all developers are the same. Developers really needing to gain total of their HTML can do without server controls. However, doing without server controls requires you to change significantly your programming model -- no more postbacks, no more viewstate, and an overall simpler and lower-level programming style.