Summary

We've covered a lot of ground over the last two chapters. You should now be able to judge when adding some client-side code or objects could improve your pages, both by adding responsiveness and reducing the workload placed on the server. And of course, the examples demonstrate ways that you can achieve tasks that just aren't possible using only server-side code.

The one big problem with client-side coding is the uncertainty about the environment of the browser. However, the two market leaders are tending to standardize on the features they support, while squeezing other browsers out altogether. As long as you ultimately design for these, you can be sure that the majority of viewers will benefit from your pages.

The main points in this chapter have been:

There are often tasks we can't accomplish using just server-side code, and ASP. For this reason, client-side scripting, and objects like Java applets and ActiveX controls, can come in very useful.
Client-side programming can also reduce network load and server processing requirements, especially with verification of information before submission.
Spreading the processing load between server and client means that careful design is required, otherwise the application becomes almost impossible to maintain.
Remember that client-side users can't be sure, with the examples we've see so far, that information submitted from form is not being intercepted or used improperly. At the same time, the server can never be really sure that the information they are receiving in genuine.

This last point is very important, and is the one thing likely to prevent the increasing spread of electronic commerce. In the next chapter, we change tack to look at this subject in a lot more detail.