I see four levels of JavaScript problem-solving.  Your approach will depend on some of the factors we discussed in part 1.  If we agree that JavaScript is a hammer (a very useful tool in many but not all situations), we must also determine at which strength to employ our hammer.  Hammering too hard or too fast risks damage to our nails or wood.  Likewise, wielding JavaScript with a heavy hand can have unintended consequences for site performance or user interaction.

Minimal footprint*/minimal reuse – optimized script on the page or referenced** on the page.

• Benefits:
  • Easy to deploy and test with minimal disruption to page/site structure using a CEWP.
  • Exporting the CEWP allows code reuse (Web Part Gallery) on a case-by-case basis.
• Drawbacks:
  • Code often needs parameter changes or minor syntax changes to redeploy (and therefore some skill).
  • Works only in a “controlled” site collection; new site/library structures do not gain the benefits until a site editor adds the CEWP to the page.

Medium footprint/medium reuse – optimized script with common application added to default.master page or referenced by master.

• Benefits:
  • Smallest footprint available to new site/library structures.
• Drawbacks:
  • Parameters can no longer exist in the script call; variable use (from server variables, the query string, etc.) may limit usefulness.
  • Requires changes to the default.master (opens a can of worms for administration and possibly performance***).
  • Increased testing needed to avoid unintended changes to the user interface.

Large footprint/high reuse – library of script referenced on page.

• Benefits:
  • Highly flexible reducing development time.
  • Benefits gained from community development and patching.
  • Cross-browser compatibility problems often solved.
• Drawbacks:
  • Bloated footprint.
  • Learning curve and feature sets differ for each library.

Maximum footprint/maximum reuse – library of script referenced in default.master.

• Benefits:
  • Least amount of administration needed to maintain scripts or script references.
  • Can develop web parts with the library in mind.
• Drawbacks:
  • Largest footprint; mostly likely to negatively influence performance.
  • Large testing pattern needed to avoid interface problems after script changes, SharePoint patches, or new application development.

*Footprint refers to the additional code the browser must download as well as the complexity of the processing the client must complete.  While a campus intranet may have no problems deploying a large JavaScript library on top of SharePoint, a public-facing site used primarily by mobile users may become unusable.

**Avoid referencing a script with a full web address like “http://…” as this causes a DNS lookup and will reduce page performance.  If you place the script file in a document library, make sure you have the correct permissions on the library for all permission levels.

***Changes to the default.master done in SharePoint Designer (SPD) forces the new version into the database.  This causes additional load and an increased number of “trips” to the database per page request.  Avoid doing this on production sites.