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 miniature applets built with JavaScript, ActiveX, Java, and Flash into web pages. 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 client-side 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. Figure 1-3 shows the difference between the server-side and the client-side model.
These are some other reasons for avoiding client-side programming:
- Isolation: Client-side code can’t access server-side resources. For example, a client-side application has no easy way to read a file or interact with a database on the server (at least not without running into problems with security and browser compatibility).
- Security: End users can view client-side code. And once malicious users understand how an application works, they can often tamper with it.
- Thin clients: As the Internet continues to evolve, web-enabled devices such as mobile phones, palmtop computers, and PDAs (personal digital assistants) are appearing. These devices can communicate with web servers, but they don’t support all the features of a traditional browser. Thin clients can use server-based web applications, but they won’t support client-side features such as JavaScript.
However, client-side programming isn’t truly dead. In many cases, ASP.NET allows you to combine the best of client-side programming with server-side programming. For example, the best ASP.NET controls can intelligently detect the features of the client browser. If the browser supports JavaScript, these controls will return a web page that incorporates JavaScript for a richer, more responsive user interface. And in Chapter 25, you’ll learn how you can supercharge ordinary ASP.NET pages with Ajax features, which use even more client-side JavaScript.
However, no matter what the capabilities of the browser, your code is always executed on the server. The client-side frills are just the icing on the cake.
