Programming the Internet

Static pages were good for a while, but then the Internet became humdrum. Finally someone had a bright idea: "We have a program running on our web server that is responding to clients, and feeding them requested pages. What if we could enhance that program so that, for certain pages, it would call a program or script that would generate the HTML content on-the-fly, and have that content returned to the client?" So they changed the server process. Now, when the client asked for a web page ending with the extension .cgi, the web server process ran a separate script that generated the content. The system also provided a means for some client-supplied content to make its way to the script, making possible customization and personalization features.

From there it was a short step to a generic solution. On the Microsoft platform, Internet Information Server supported add-ins that could be called based on the file extension of the requested file. This led to Active Server Pages (ASP), a solution that allowed developers to embed server-side script (often using "VBScript," a variation of Visual Basic) right in the HTML content, and have it adjust the content before it was sent to the client.

Someone else said, "If we can write scripts on the server side, couldn't we also include a 'client-side script' right in the HTML content that a smart web browser could process?" Before long, client-side and server-side developers were battling it out in the streets, but the battle didn't get very far because all the programmers were exhausted. The cause? Programming in script! Whether it's embedding script in HTML (the client side) or generating HTML from script (the server side), script programming is cumbersome, slow, high in "bad" cholesterol, and almost impossible to debug interactively.

Some web script programmers hadn't used a language compiler for years, and were on the verge of lapsing into fatal script-induced comas. You could compile some server-side logic into a DLL and use it to process web pages, but it was far from easy, and these DLLs were still often linked into the HTML content via short scripts.

Then came .NET, and its support for compiled server-side application development. Script programmers breathed a collective sigh of relief from their hospital beds; they could now use the full power of Visual Studio and .NET languages to build HTML content. And this new system, "ASP.NET," was designed so that you could craft entire web applications without even looking at a single HTML tag. The design goal: to make web development nearly identical to desktop application development. And Microsoft largely succeeded. It didn't solve the client scripting problem (maybe soon!), but some of the new server-side features included in ASP.NET greatly reduced the need for custom client-side scripts.

The pages you build in ASP.NET are called "Web Forms," and because they are so closely tied together, I sometimes use ASP.NET and Web Forms interchangeably. But they aren't exactly the same thing: ASP.NET includes Web Forms.