JavaScript On Demand
The only solution to this is to adopt a "lazy" approach to loading, otherwise known as "on-demand JavaScript," where code is retrieved from the server as the need arises. This can circumvent the redundancy problem, as only a fraction of an application need be downloaded initially, with additional functionality being acquired as necessary. This avoids the redundant consumption of bandwidth, expedites delivery, and reduces the stress on both server and client. There are two principal routes to implementing the technique:
- The first entails connecting to the server explicitly using an XMLHTTPRequest object, where the code that is returned is evaluated into the execution environment.
- The second approach to loading on demandthe "script-tag hack"turns upon the fact that script elements form part of the DOM-object hierarchy for a given page. This means that an application can create a script element, then set the value of its src attribute to the name of a JavaScript library, before inserting the element into the DOM hierarchy for the page. This causes the interpreter to download the library, thus introducing its functionality into the execution environment. Usefully, this principle also applies to CSSsetting the href of a <link> element dynamically causes the client to download and evaluate the corresponding stylesheet.
These techniques yield the same net result, but choosing one over the other presents certain tradeoffs. On the one hand, the script-tag technique is asynchronous, whereas XHR allows synchronous as well as asynchronous requests. In contrast, the script-tag technique allows retrieval of code from anywhere, whereas XHR allows requests only to the originating domain.
Noncohesion
Obviously, the mechanics of these techniques should be implemented within discrete functions, thus reducing the act of loading a resource to a simple call. However, the optimum designs for complex and powerful applications demand a degree of granularity to matchlarge programs are often split into many small modules, and in this case loading on demand can cause code to become littered with extraneous calls. Listing Two demonstrates this, where LoadLib_STH loads a library using the script-tag approach and LoadLib_XHR uses the XHR-based technique (LoadStylesheet is self-explanatory).
function DisplayMenu (...) { if (...) { LoadLib_XHR ("..."); } else { LoadLib_XHR ("..."); } LoadStylesheet ("..."); LoadLib_STH ("..."); // Code for displaying a menu } function LoadLib_XHR (LibName) { ... } function LoadLib_STH (LibName) { ... } function LoadStylesheet (LibName) { ... }
In this example, using on-demand techniques necessitates populating DisplayMenu with calls to load code that will be required subsequently; yet those calls are extrinsic to the business of displaying menus. The loading syntax is therefore disjunctive, and this degrades the functional cohesion (en .wikipedia.org/wiki/Cohesion_%28computer _science%29) of the code, thus harming readability and comprehension. In other words, the various concerns (or "aspects") of the system cut across each other and are therefore "entangled."
Moreover, functions like DisplayMenu bloat the application, thereby decreasing efficiency. Furthermore, the relevant resources need be retrieved only once, which means that repeated calls to DisplayMenu will cause redundant calls to the loading functionsthose calls serve their purpose just once before becoming deadweight that impinges on performance. All of these points run contrary to the very aim of loading on-demand, which is to pay only for what is used.