Category Archives: Community

Loading JavaScript Libraries – It Shouldn’t Be This Hard

I’ve been doing a lot of JavaScript programming for the past few years. SharePoint 2013 has only accelerated the pace. Currently, I split my time roughly evenly between SharePoint and non-SharePoint work at my primary client, but both projects make heavy use of JavaScript, between them making use of many of the popular JavaScript libraries – Angular, JQuery, JQueryUI, Moment, Require, Knockout, etc., etc., etc.

The disparity between the two worlds is still quite wide. Even something as simple as loading up required libraries is more difficult in the SharePoint world than in the rest of the world. Part of this, I realize, is due to the nature of SharePoint. It is a much larger application than many other non-SharePoint applications and lends itself to extensibility much more than those non-SharePoint applications. There are often far more people involved as potential customizers of SharePoint than with non-SharePoint applications

And that’s where the trouble begins.

Extensibility means a loss of control. Even in controlled environments that actually effectively do SharePoint governance, extensibility invites problems. JavaScript is still a little bit of the Wild West; every project is going mandate the use of different libraries, different versions and different configurations. If all I’m concerned about is my project, things are easy: I load the libraries I need using one of any number of script loaders or script-loading approaches. To hell with anyone else.

That, obviously, is not a very good approach, but it is one taken all too often. I was recently asked to look into a problem at a client that boiled down to them having a ridiculous number of JavaScript libraries loaded on too many pages:

  • 4 different versions of JQuery
    • One page actually loaded JQuery 6 times, as poorly trained site admins, or users with permissions, were adding Script Editor Web parts on pages and each loading JQuery, from different document libraries and CDNs
  • 2 different versions of JQueryUI
  • 2 versions of Knockout

This is in an environment that at least makes an effort at governance. Unfortunately, too much of it is left in the hands of developers, but this isn’t a post about governance directly. Instead, it is an attempt to try and figure out what we as developers and architects should do.

As a consultant and ISV, I cannot mandate too strictly how my client or user’s environment be configured. I can say something like – if you don’t have JQuery installed and loaded, we will install and load it. But that’s about it. That may be fine for the moment my customization (either custom built as a consultant or a product I sell as an ISV) is added to the environment, but I have no control over what happens later. If, three days after my customization is added, another product or customization is added which loads its own version of JQuery we may have a problem – especially with the somewhat recent split of compatibility between JQuery 1.x and 2.x. The one that prompted me being called in to that client was caused by a customization loading a new version of JQueryUI, one which contained a different custom collection of widgets. It broke a different customization.

What’s the solution? I don’t have a good answer, but I’m working on it and invite collaboration. If we can come up with something good, this would be a killer community-driven project. Here are the problems, as I see them:

  1. We need some way to track which libraries and versions are available in an environment. This can’t be “just” documentation or offline means – code should be able to check and respond appropriately. Somehow, this needs to be global across the environment and future-proof.
  2. MDS must be supported. As a consultant or ISV, I cannot dictate that MDS be turned off and have that remain inviolate for all time. I know many developers prefer to just turn it off, but it is a feature of SharePoint and therefore must be supported.
  3. There must be a standard for how libraries are loaded so you can anticipate when they will be available. One of the problems faced by the client I mentioned was that via the convoluted mess they had gotten themselves into, JQueryUI was loading before JQuery, which doesn’t work.
  4. There must be a simple way for non-developers to participate in maintaining things. Otherwise we run into the problem above where users had loaded many different versions of JQuery via the Script Editor Web Part
  5. It would be nice if this made things easier for developers – perhaps by supporting AMD modules and requirements management, either via Require.JS directly or a fork of it to make it SharePoint and MDS compatible.
  6. It should support both on-premises and SharePoint Online/Office 365, including Apps.

There are a few other things that should probably be included in there, but these, to me, are the big targets. I realize that there are answers to each of these individually, but what is missing is a comprehensive approach and a commitment from the community to drive a consistent approach. Honestly, there may not be one ring to rule them all. The best thing may be two or three approaches, but that would still be better, especially if there were some consistency and commonality amongst them.

If anything is to come of this, education and community support are critical to making it work, so what do you think? Leave a reply and we’ll see where this goes.