When you combine decent Javascript with calls to the Microsoft MSXML component (or the equivalent one in Mozilla) to make web service calls to the server you end up with completely static client side DHTML pages that fetch their data in to form of XML from the server. This means you end up only downloading the UI layout once and then fetching the data to go in it. Much better than dragging the data and the UI layout down to the client every time the page reloads.

It also provides a nice clean break between your UI code and the web service data access code. A side benefit is that other apps can then call the web service code as well.

Another thing it does is allows you to cache large data sets on the client side. For example one of our apps has a hierachical tree of users, which on some customer sites is 10s of thousands of nodes in size. Because we use the client side Javascript approach we can pull across the part of the tree we need and cache it in the client side pages so we don't need to get it again (we have timed caches that expire after a certain time).

With just a handful of server side pages to call to access data it also makes i easy if you find you have to use HTTPS to encrypt your data, because then you only need to encypt the pages that serve out the data and leave the rest in the clear.

In our apps the web service calls all tend to use the same common code, allowing us to piggy back debug and performance metric data when we need to monitor how things are performing.

N.B. the web services don't have to be fancy, most of the time there is no need to go as far as using something like SOAP.

The end result (as long as everyone has half decent client machines) is a faster responding app that puts far less load on the server than a tradition "post, post and post again" app.

At one point I planned to design a framework of ASP.NET controls that generated code like this by just placing the controls on the form, but I never got round to do it.