Programming Microsoft ASP.NET 4 - Dino Esposito [468]
Summary
ASP.NET offers two approaches to AJAX: partial rendering and scriptable services. Of the two, partial rendering is the one with some hidden costs. Partial rendering is easy to understand and doesn’t require that you learn new things. It makes an existing page work the Ajax way without changing anything. Although it can still achieve better performance than classic postbacks, partial rendering moves a lot of data around. In the worst cases, the savings in terms of markup are negligible compared to the quantity of bytes moved.
On the other hand, the best selling point of the Ajax paradigm is the idea of making stateless server-side calls from the client and updating the page via the DOM. Here’s where scriptable services fit in. No hidden costs are buried in this model. You send in only input data required by the method being invoked and receive only the return value. Traffic is minimal, and no view state or other hidden fields (for example, event validation) are roundtripped. On the down side, remote method calls require JavaScript skills. You control the execution of the method via JavaScript and use a JavaScript callback to incorporate the results in the page.
Using scriptable services leads you to making some architectural changes to the application. You need a server API designed to respond to script-led requests, and you need this API to live on top of your existing middle tier. How do you expose this API? There are various options for implementing this layer. You can use a Web service or, better yet, a WCF service hosted in the same domain. Once you have a back end based on services, you orchestrate calls to endpoints from the client browser using whatever programming language the browser provides. If plain JavaScript is not optimal, you can use a wrapper library such as jQuery (see next chapter) or switch to a rich Internet framework such a Silverlight.
Chapter 21. jQuery Programming
If knowledge can create problems, it is not through ignorance that we can solve them.
—Isaac Asimov
Aside from the social implications of it, the modern Web from a technology viewpoint is mostly about running (a lot) more JavaScript code on the client. JavaScript is a very special type of language; it’s probably not the language everybody would choose to use today to power up the client side of the Web. However, it’s the only common language we have, and we have to stick to it to reach the largest audience.
So what if you want (or more likely need) more power on the client?
Be ready to write more JavaScript code. More importantly, be ready to import more JavaScript code written by others. Either of these two ways of using JavaScript is OK, as they are not mutually exclusive options.
I firmly believe that, at least for the time being, you can’t just transform JavaScript into something else that is radically different from what the language is today. However, the Web has repeatedly proven to be a surprisingly dynamic and agile environment; so who really knows what could happen in five years?
Currently, the most effective approach to adding more power to the client is using ad hoc libraries full of Document Object Model (DOM) facilities and adding new features to the existing JavaScript language. Interestingly, a single all-encompassing library seems not to be realistic. The ideal JavaScript library is often obtained by stacking up and composing together bits and pieces of existing libraries in a custom recipe that suits each particular application.
Many attempts have been made over the years to create the perfect JavaScript library. As it often happens, many libraries participate, but only one wins. And in this regard the winner is jQuery. In this chapter, you’ll discover the capabilities of this library and its powerful extensibility model.
Power to the Client
JavaScript is a language tailor-made for the