Client-Side Programming

At the same time that server-side web development was moving through an alphabet

soup of technologies, a new type of programming was gaining popularity. Developers

began to experiment with the different ways they could enhance web pages by embedding

multimedia and miniature applets built with JavaScript, DHTML (Dynamic HTML),

and Java code. These client-side technologies don’t involve any server processing.

Instead, the complete application is downloaded to the client browser, which executes it

locally.

The greatest problem with client-side technologies is that they aren’t supported

equally by all browsers and operating systems. One of the reasons that web development

is so popular in the first place is because web applications don’t require setup CDs, downloads,

and other tedious (and error-prone) deployment steps. Instead, a web application

can be used on any computer that has Internet access. But when developers use clientside

technologies, they encounter a few familiar headaches. Suddenly, cross-browser

compatibility becomes a problem. Developers are forced to test their websites with different

operating systems and browsers, and they might even need to distribute browser

updates to their clients. In other words, the client-side model sacrifices some of the most

important benefits of web development.

For that reason, ASP.NET is designed as a server-side technology. All ASP.NET code

executes on the server. When the code is finished executing, the user receives an ordinary

HTML page, which can be viewed in any browser.

Server-Side Programming

To understand why ASP.NET was created, it helps to understand the problems of other
web development technologies. With the original CGI standard, for example, the web
server must launch a completely separate instance of the application for each web
request. If the website is popular, the web server must struggle under the weight of hundreds
of separate copies of the application, eventually becoming a victim of its own
success.

To counter this problem, Microsoft developed ISAPI (Internet Server Application
Programming Interface), a higher-level programming model. ISAPI solved the performance
problem but at the cost of significant complexity. Even after ISAPI developers
master the tricky C++ programming language, they still lie awake at night worrying about
confounding issues such as multithreading. ISAPI programming is definitely not for the
fainthearted.

ISAPI never really went away. Instead, Microsoft used it to build higher-level development
platforms, such as ASP and ASP.NET. Both of these technologies allow developers
to program dynamic web pages without worrying about the low-level implementation
details. For that reason, both platforms have become incredibly successful. The original
ASP platform garnered a huge audience of nearly one million developers. When ASP.NET
was first released, it generated even more interest as the centerpiece of the .NET Framework.
In fact, ASP.NET 1.0 was enthusiastically put to work in dozens of large-scale
commercial websites even when it was only in late beta.


Despite having similar underpinnings, ASP and ASP.NET are radically different. ASP is
a script-based programming language that requires a thorough understanding of HTML
and a good deal of painful coding. ASP.NET, on the other hand, is an object-oriented programming
model that lets you put together a web page as easily as you would build a
Windows application. In many respects, it’s easier to learn ASP.NET than to master ASP,
even though ASP.NET is far more powerful.