Client and Server Communication

Client-Side Script Caching

Any time you are developing a web site, you want to keep the amount of data being passed from the server to the client machine minimal. That keeps the load time low for the web page so the end result improves the end-user experience. To use a large amount of client-side functionality, however, you need a large collection of JavaScript functions on the client machine. The dilemma is determining exactly how to divide up the JavaScript functions so you are only sending what you need when you need it.

There are some other factors to consider when dividing this up. When the JavaScript files are sent to the client browser, they are locally cached by the browser based on the current URL. Each time a page is sent from the server side to the client side, the browser has to send a request to the server for each separate JavaScript file to see if the client-side file's date is the same or older than that of the corresponding file on the server side. If the file on the server side is newer, or the client-side file does not exist yet, the server-side sends the JavaScript file to the client web browser.

Another factor that should be taken into consideration is the payload of the initial page. The more functions in a single JavaScript file, the bigger the file will be. If all client-side code were sent in a single file, that file would be rather large. The larger the file, the longer it takes to send to the client side. You never want the first page hit to your site to take so long that users have no desire to see the rest of your site. Despite the ever-increasing speed, availability, and usage of broadband connections, this is still a factor that merits your attention.

How this is handled in the DotNetNuke Client API, like many other decisions, is a compromise. The JavaScript files are grouped by functional area. These functional area groupings are similar, as is the naming of the entire Client API, to working with namespaces in ASP.NET. The JavaScript files are also structured so that all common functions are broken out into separate files. Those files make use of the functions by referring to the other JavaScript files containing that logical grouping, which is similar to working with ASP.NET namespaces.

To avoid too many requests needed on every page hit to determine if a new JavaScript file should be downloaded, the number of JavaScript files has been limited, and few will be added over time. A subsequent page hit is going to happen much more often than the initial page hit because the end user is more likely to view that page hundreds or even thousands of times again. Weighing all of this, the Core Team determined that it would be more beneficial for the end-user experience to not require a high number of requests for each page hit rather than focusing too much on the initial page hit payload.

Thus far you have touched only on how to get files and data from the server side to the client side and how to deliver them. The next section looks at how to start communicating between the client-side code (now that you know how to check what the client-side browser supports) and the server-side code.