Part 2: Loading JavaScript Libraries (It Still Shouldn’t Be This Hard)

My post on Sunday seems to have struck a little bit of a nerve.  A number of folks added comments to the blog post and a few others commented directly to me via email or other channels.  In this post, I’m going to quickly summarize and respond to some of the comments and then move on to step two – trying to formulate thoughts for moving forward, if there is in fact a path to move forward any further.

OK, here we go, in no particular order…

(Oh, yeah, perhaps this goes without saying, but these are largely opinions based on my experience and stories I hear from other developers.  YMMV, and I’d *love* to be proven wrong about some of these, but let’s make sure to keep the discussion productive and moving towards a solution).

  • Marc’s concept of “Functions as a Service” (FAAS) is interesting and one I think should be investigated and fleshed out.  I haven’t read the book chapter Marc references, so maybe he’s already done that…Marc?
  • Hugh’s mention of JSFiddle as a case study is *exactly* what I had in mind for a part of this.  For small-scale customizations implemented by an end user, selecting a library or two needs to be as dirt simple as JSFiddle.  I think this ties in to FAAS as well.
  • As a few folks mentioned, this is not entirely a technical problem.  Regular old Governance comes into play in a big way.  Too, if anything comes of this, we must get a groundswell of community support behind it as a “standard”.
  • This is perhaps a semantic argument, but contrary to what a few folks posted, I think there *is* a one-size-fits-all solution, or at least one-size-fits-most – there’s always going to be edge cases that don’t work.  The semantics comes in because I’ll call it one solution with a couple of facets, but all falling under one umbrella.
  • SPO (Office 365) and MDS must be addressed
  • Supporting MDS is somewhat difficult, and more than just not polluting the global namespace
  • RequireJS is a great example of managing dependencies and loading modules. I use it frequently, as do many developers. Unfortunately, as it stands right now, it is not MDS-compliant (it creates script nodes using CreateElement)
  • Loading multiple versions of the same library is a performance and memory use problem, but also breaks some libraries (like JQueryUI, and probably a bunch of other JQuery plugins, though I haven’t tested them).  Namespacing doesn’t fix all of this.
  • The other problem with loading multiple libraries is also compounded by a lack of control over load order.  SharePoint has too many ways to load libraries and they all load at different times.
  • A comment was made that “most companies would not want to advertise the existence of a “standard library loader” to general users… since that would implicitly suggest that ad-hoc customization is ok…maybe even supported” which part of me agrees with, but a bigger part of me thinks those companies are just burying their heads in the sand.  Unless they somehow hide the Script Editor webpart (which some do, I know) they have people doing customizations and ignoring it doesn’t make it go away.  They’d be better off embracing and providing some guidance/support.  This also plays into my “one solution with many facets” approach – companies can choose which pieces they wish to implement to cover their scenarios.
  • Another comment was “As a developer you should be working to make YOUR js libraries isolated from anyone else.”  I think this is wrong.  This is not being a good corporate citizen.  This is the “too hell with everyone else” scenario in my original post.  I agree that you should isolate your code as much as possible, but unless everyone is there can still be problems.  Too, your code is not the only code running in the environment.  The only exception to this I can think of is if you are developing an application as an ISV or internal developer/consultant and your application is entirely self-contained – you control the horizontal and the vertical.  However, if you develop even one web part as part of your application, you don’t have that level of control – users could add that webpart outside of your application.  If you integrate with OOB SharePoint – even just using its Master Page – you don’t have that level of control.  If your application allows Custom Actions to load, you don’t have this level of control…etc., etc., etc.  Even if your stuff is perfectly insulated and always works, it may break something else or cause some other problem.
  • A few folks commented along the lines of user’s maintaining/understanding/impacting their code.  This falls under the previous bullet.  In most cases, your code is not the only custom code running in the environment
  • A big part of the problem is that we cannot say that this is only of concern to professional developers.  While I personally dislike the term “citizen developer” I agree with the fact that non-developer users are customizing SharePoint and using JavaScript they cobble together from the internet or simple trial and error, and they too often “ship it” as soon as it appears to do what they want with no additional testing or documentation.  This ship has sailed and there’s no way we’re bringing it back to port, much as we might want to.  (And yes, I realize that some of those “citizen developers” do very good work – better than some developers – but I’m mostly concerned with those who don’t)
  • I have not specifically noticed the “jarring effect” some folks mentioned, but maybe I’m just missing it.  I’ll dig out some code I wrote that should show it and try to pay more attention.

I think that sums up my responses and follow-on comments.  Now to move forward…

As I see things in my twisted little mind, here’s what we need, from a technology point of view (governance is next, don’t worry).  This is very much of a blue sky wish list and I realize that some of it may not be feasible/possible.

  • A replacement for the Script Editor web part that simplifies things for end users to allow them to pick the libraries they need and guides them towards some minimal “best practices” – a very lightweight linter of some sort that enforces a few basic rules would be a good start.  Optionally blocking inline script tags would also be nice (so MDS doesn’t break).  I think 99.9% of the time, simply telling them that JQuery is already available will be sufficient, so this doesn’t have to be fancy.
  • A way to track which libraries and versions are available globally (scoped to a given web, I think)
  • A way for developers to specify/discover which libraries are loaded and the order in which they load
  • A fast, reliable way to load and initiate a script loader which can then load other required scripts
  • An MDS-compliant way to specify dependencies between modules and load order

I’ve probably missed a few things, but that’s a start.

For governance, here’s my wish list:

  • Documentation of whatever the technology solutions are
  • Consensus amongst developers that whatever “this” is, it is the recommend way to proceed (although I acknowledge this is like herding cats and will never be close to 100%)
  • Training/education material for end users and developers

So where do we go from here?  Next is a viability assessment of the technology wish list.  What’s possible?  What’s feasible?  After that, if enough of the technology can be made to work then we kick off a community project.  Or we talk to Microsoft about carving off a little corner of the PnP world for this effort and get a little help from the mother ship (which would also go a long way in getting buy in from developers and companies).

This may all very well be a pipe dream, but I’m somewhat known for tilting at windmills (and metaphors, mixed or otherwise) but if we don’t at least try to come up with a solution to a problem, all we’re doing is complaining and that’s just wasted energy.

As always, comments welcome.

Dave