A year-and-a-half ago, I was ready to bet the farm on XML. I was sure there was just one way to improve Active Server Pages (ASP)—namely, a richer, customizable, application-oriented HTML. This new approach had to be good XML that Extensible Style Language (XSL) processors could transform into plain HTML 3.2 code.

I envisioned a server-side world with highly descriptive pages based on proper XML schemas and translators. Each page of a Web application would represent a state in the application's design, and a decent language would let developers describe that state's UI. A good descriptive language is what an XML schema gives you. Reducing a Web application to an XML schema was certainly a correct way to pose the question of enhancing ASP. It also opened people's eyes to the privilege of fanning the XML fire. As a result, I became involved as a supervisor for a few large and remunerative projects.

While meditating on some architectural issues for one of those projects, I thought of another way to improve ASP. With ASP, you have to build everything you need—it doesn’t impose limitations on what you can and can't do with code, provided that you get everything you need through code. I felt the need to devise a new family of more powerful components. The ASP object model is a mere COM-based wrapper on top of basic browser-Web server interaction (session, request, and response). Thus, I called on some programmers to build a server-side component that can generate highly customizable datagrids. Most ASP have a simple layout for accessing data and producing detailed reports. So why not use a project-wide, configurable, homemade datagrid? One week later, the two programmers in charge gathered in my office with a ready-to-use and pretty cool component that we used in the project.

Our datagrid was a COM automation object capable of accessing the ASP's Response object to update the output stream. While they work perfectly together, ASP and COM remain two distinct worlds. COM binary code is fast but, because COM is involved, you always end up paying in initialization overhead. When you have to comply with a stressed Web server, every bit of performance you can save helps.

While working with our datagrid, a thought flashed across my mind. The future of ASP is components, no matter the model—COM, COM+, or something else—nothing but components. What I thought of as "something else" now has the face of the .NET Framework, and ASP based on this framework in the form of ASP.NET pages.

In ASP.NET, you have three families of components, and every element you can manage is an object. These objects aren't COM or COM+ based, but rather instances of one class of the .NET Base Class Library. Of course, some of these classes call COM objects under the hood, but that doesn't affect the generality of the statement: You simply don’t work with COM objects in ASP.NET.

The first family of components, which provides for backward compatibility, is called HTML controls. When the ASP runtime finds an HTML tag, it creates an instance of the corresponding object. This interaction happens behind the curtain, and it ensures that all legacy code will continue to work.

To experience the true power of ASP.NET, you have to work with server controls, the second family of components. Server controls are characterized by the <asp:> namespace and are simply .NET components exploited through a declarative syntax. Declarative syntax means that you don’t need to write the code to instantiate an object; you just declare the object to be up and running and with certain properties at a certain time. In ASP, any object or tag is lifeless as long as it remains on the server. You can't assign the property of a tag in an ASP page, but you can within an ASP.NET page. To enable this feature, you must use the runat attribute. Set the runat attribute to "server," and ASP.NET will automatically create an instance of the object that you can code against from within the page. The flexibility you get is enormous, and readability and maintenance increase significantly. However, this model wouldn’t have been so powerful without built-in controls, especially data-bound and list-bound controls. ASP.NET gives you the advanced and rich components that you otherwise would have had to write yourself. In particular, I was pleasantly surprised to see that the <asp:datagrid> control of ASP.NET is a close relation to the datagrid COM component I had written a year ago.

ASP.NET's third family of components validation controls, rely heavily on another cool feature of ASP.NET: postback events. Validation controls give you the greatest flexibility when it comes to validating the values you enter through input controls. More important, these controls let you define both client-side and server-side validation code. In other words, you can easily check the format on the client and perform more advanced data-driven checks on the server. All this happens through the same programming model. You set an OnClick handler for the client and an OnServerClick handler for all the controls you want to make on the server.

Postback events is the key technology for directing all this traffic. At the top of the ASP programmers' wishlist was the ability to use advanced and comfortable programming techniques, regardless of the browser. When an ASP.NET page includes controls that support postback events, the runtime spookily adds some extra code to the page. This code performs a submit to the server using the same page as the target. Basically, when a postback event fires, the page refreshes itself on the server while its current state (e.g., text have entered, boxes you have checked) remains unaltered.

Extensive use of components, a rich object model such as the .NET Base Class Library (BCL), and some cool techniques integrated into the runtime make ASP.NET the ultimate environment to date for Web. However, ASP.NET is more than this—it's an application that exploits several server-side services, including caching, state maintenance, threading, and queuing. Writing ASP.NET pages teaches you skills that you can then leverage to write desktop .NET applications (e.g., WinForms)—skills that will help you understand and write Web services.