New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Using JavaScript Libraries in DNN

In December 2013, version 7.2 of the DNN Platform was released, which included a new type of extension, the JavaScript Library. At Engage, we've found this to be very useful to us in many scenarios, and we've been investing in creating a solid body of libraries, but I don't think that many other developers or theme designers are aware of it and how they can make use of it.

JavaScript Library packages are deceptively simple. At one level, they just package a single JavaScript file. However, the existence of this package provides a number of straightforward benefits:

  1. DNN allows multiple versions of a JavaScript Library package to be installed, so different extensions can request different versions.
  2. However, if different extensions on the same page request different versions, the highest version wins, which reduces script conflicts.
  3. The library defines metadata about the JavaScript library, such as where in the document it is included (e.g. html5shiv is automatically included in the page's <head>, but most other libraries can wait until the end of the </form>, speeding up initial rendering time)
  4. Additionally, a CDN URL can be included with a JavaScript package, allowing a host administrator to flip a switch and benefit from globally distributed versions of the script (this also provides the benefit of domain sharding). Along with this, a JavaScript expression to test is also included, so that DNN can fallback to the local version of the script if the CDN is inaccessible.

So, how do I get these wonderful benefits in my DNN website? The first step is to check out the Usage section of the wiki article on JavaScript Libraries, and see what it looks like to use JavaScript Libraries in your own extensions. Once you're ready to use them, you'll need to have them available to you. Engage has created a handful of packages for libraries that we're using (see them on the Forge), but I'm sure that this doesn't contain every library that you might use on your site or in your extensions. If you grab a copy of our JavaScript Libraries repository on GitHub, there is a PowerShell script in there to generate a package based on information from Bower. Reach out to me on Twitter if you're interested in contributing more packages.

The real benefit of JavaScript libraries starts to come when they're used by more and more components in a website. Let me or other folks working on DNN or in the MVP group know what you need to make better use of features like this that DNN provides, so we can create the best platform for your web applications. If you're interested in helping out, the README in Engage's GitHub repository has a Roadmap section with some ideas.


Jonathan Sheely
The library system still doesn't handle multi file dependencies does it? Most of the libraries I would want to use this feature with have a css file.

Also many libraries contain a core library and additional optional files. Having to create a separate libraries for each of theses seems kludgey if this is not handled.
Jonathan Sheely Friday, January 23, 2015 5:39 PM (link)
Brian Dukes
I definitely agree that it will be better when these libraries can easily package CSS alongside the JavaScript file; however, I think that even if you're including the CSS yourself, you still get benefits from the JavaScript being in a library, even if you're not getting _additional_ benefits with the CSS.

Are you referring to something like Bootstrap, which has a single JS file that contains a number of different plugins. You could include a single plugin, or the single file that includes them all. In this scenario, I'd think that there would be a JavaScript Library for each individual plugin, and then, perhaps, a library that represents all of those together (see for an example; the JavaScript Library code could handle this better, but it works). Is your issue just that it's difficult to create a package for each plugin? Or something different?

Thanks for the feedback, I appreciate getting more folks thinking about these.
Brian Dukes Friday, January 23, 2015 5:49 PM (link)
Jonathan Sheely
I was thinking more like AngularJs that has the core library angular.js but then has version dependent addins like angular-sanitize or angular-route

im not sure it makes sense to create a package for for each individual file vs one package that could include them all. (assuming you cant already do that)
Jonathan Sheely Friday, January 23, 2015 6:10 PM (link)
Bruce de Beer
I have been trying to use this feature also, and was discouraged by the lack of support for css and granular script files.
Bruce de Beer Saturday, January 24, 2015 12:01 PM (link)
Brian Dukes
@jsheely So, is this just a packaging issue, or do you envision that your interactions with the API would be different? We can definitely create a single zip that includes many JS Libraries (and I don't know why I didn't think to do that with my jQuery.cycle2 example); it would just be a manifest with many package elements. Does that sound like what you're looking for?

@Bruce & @jsheely, can you give me an idea of how you'd like to see CSS files included? Would we add a CSS library extension type, or would we associate a CSS file with a JavaScript library? Would it be included on the page automatically, or would you explicitly request it?
Brian Dukes Monday, January 26, 2015 11:23 AM (link)
Jonathan Sheely
In an ideal world I would like to see an API like this. Then the resource package just needs to allow for this type of API.

1. Loads the entire package. If there are 10 resources added into the manifest it will load all 10 (css,javascript)

2. Load a specific version. Again will still load all files associated with this version of the package.

3. Load specific files from the resource package. Instead of loading everything you get just what you want.

I could see some additional flexibility in the overloads to perhaps only load all CSS files or all Javascript files. I'm not married to that overload variable order / typing but I think it expresses my thoughts.
Jonathan Sheely Monday, January 26, 2015 11:41 AM (link)
Mark McAvoy
It would be kind of nice if you could just enter a GitHub url and that contains a maintained list of common libraries which you can just install into DNN. Kind of like NuGet does for Visual Studio.
These would make adding all those common libraries a breeze.

@jsheely I do like the ideas on how to load the libraries with multiple files/css/packages
Mark McAvoy Monday, January 26, 2015 12:30 PM (link)
Brian Dukes
@Mark doesn't the Forge provide this for DNN?

@jsheely If I were to create an angular package that didn't its own JS file, but had dependencies on "angular-core" and "angular-sanitize", I could then call JavaScript.RequestRegistration("angular"), and get all of the resources related to that package. To me, that feels better than having to pass specific files from a package. Is that enough of what you're looking for, or am I missing it?

So we need the ability to define CSS libraries, and define dependencies between the different client resource library types. And then a unified API, in addition to the JavaScript API. Sound right?
Brian Dukes Tuesday, January 27, 2015 5:17 PM (link)
Daniel Mettler
Thanks for bringing these issues to the surface. We've had a lot of issues with this because of the sheer complexity when trying to create ready-to-use Apps. For example, packaging the scripts together w/the App made sure the App worked - IF no other modules or the skin happened to do something to the page before our App got to do something.

The problem is - it only works if everybody uses this. Otherwise it fails. I'm thinking of assembling DNN-Best practices, this sounds like a must-have!
Daniel Mettler Friday, January 30, 2015 5:21 AM (link)

Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Davies (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out