SPWidgets – purtuga.github.io/SPWidgets – is a project I started back in 2012 when I started to take advantage of the SharePoint platform to build custom web solutions for the teams I worked with. It initially served as a place to gather reusable User Interface (UI) components that could be quickly applied to multiple projects – similar to jQuery UI (it’s design was inspired by jQuery UI). It has since grown to also include reusable utilities as well as SharePoint API methods – each self contained and again reusable across solutions.

I have now taken the self-contained reusable concept a step further and converted all files in the project to Asynchronous Module Definitions (AMD). If you have not yet learned how to use AMD and break up your projects code into modules, I suggest you take the time as it will forever change the way you design software – in a positive way. I think that anyone would agree that working with small pieces of code is much better than to try and navigate through a 5000+ line script file.


I’m a big proponent of modules and now use requireJS for just about all web development. SPWidgets was already broken up into individual files – each providing self contained functionality, so the move to AMD was not a difficult one for me. The move benefits the development of this library as well as anyone else wanting to use these modules without having to include the entire library into their projects. This was another big motivation for the move. When building SharePoint web apps, I want to keep them as small as possible, and AMD modules allow me to do that so that only the modules I referenced as dependencies will be compiled into the final file.

Build Process Updated as Well

I also took this opportunity to convert the build process to use Grunt, which was something that was way past due – this project was still using the cumbersome Ant system. Because SPWidgets is a jQuery library used by others (yes, there are a few out there – I think), the build process “compiles” the final single file just as it did before (look in the “dist” folder). The move to AMD should be transparent to existing users of this library – all widgets and utilities should continue to be exposed as they were before and with the same input signatures.

Support for Bower Package Manager

In the process of converting all code to AMD and re-factoring the Demo showcase page, which I also use for development, I also introduced support for Bower to help manage the project’s dependencies and also allow others to list SPWidgets as one of their dependencies.


Having SPWidgets broken up into AMD modules provides the most flexibility for advanced development while at the same time, through the use of the build process, continue to allow for the single jQuery library to be generated. In one of my next posts I will demonstrate how to build a quick SharePoint web app that utilizes a few of the modules available in SPWidgets.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s