JavaScript libaries

Mar 20, 2023

Is there a way to implement external or additional JavaScript libraries into storyline?

If so, how?

I require some functionality within storyline not given within the current implementation. To achieve what I require, I need to implement the p5 javascript library. How can this be achieved?

I know there is a limitation of 32ooo chars for a standard javascript trigger, so it's not as simple as including the library in the trigger. 

Also, does anyone know why ONLY a limit of 32k chars per trigger has been implemented, please don't state it as a limit of the LMS, as I know that is not the answer?


13 Replies
Eric Santos

Hi Math,

It appears that your first post was flagged as part of our spam filtering; as you have thought, it's probably because of the hyperlink. Our team monitors flagged posts for false positives and releases them to the community as soon as possible. Your post is now live; feel free to delete the duplicate if you wish.

My apologies for the inconvenience, and you shouldn't run into this issue again.

John Cooper

At the risk of showing my ignorance (which is legendary), can I ask a question on this topic? If the JavaScript library you are wanting to load has an ESM module format version, isn't it simpler to load it via an 'import' statement in the JavaScript code trigger? e.g.

async function loadMods() {
await import("");

I appreciate this function may itself have to be called from an async function. but this worked for me when loading the latest pdf-lib,js library into my notetaker demo I posted a few weeks ago.

By dynamically loading the library in this way there is no need to modify the index.html file at all. Which makes it a whole lot simpler if you are thinking of embedding the Storyline into RISE for example.

Math Notermans

With my WebObject solution you neither have to change the index.html. All is loaded automatically. 

When you are certain online sources will stay and remain available...and donot run into Cors issues on the LMS, then your solution works fine. Benefit from the WebObject solution is, that it is always available, and will not be changed or updated if you donot want to.

John Cooper

Hi Math, Phil

Thanks for the responses both you guys have way better JavaScript skills than me - but I'm still not sure why I wouldn't use the method I'm suggesting:

  • You don't need to amend anything in the exported SCORM or drop any files anywhere in my solution either.
  • I generally pick up the  JavaScript libraries I need dynamically from one of the main library repositories like pkg or NPM or GItHub. I don't think they will be going anywhere soon - a lot of code would fail worldwide if they did!
  • If I'm worried that the library might change and amendments could affect my code, then I would include the version number in the url - otherwise I pick up the latest version of the library.

It just seems so much simpler - assuming that there is an ESM version of the library available - obviously not all libraries have converted from cjs to the new standard.

Math Notermans

Both have pluses and minuses. Both work. Both have drawbacks. Mostly depends on the scenario and scripts you need. If those are always the same...and repeats course after course ( eg. using jQuery ) you can use either method.

Pluses WebObject method:

  • Once setup, it is inherited in the Storyline project and you never need to think about it.
  • Copying a default course setup like this...and all libraries are available.
  • You can easily create custom libraries or scripts and add them.
  • Good extendable.
  • As Storyline still is 32bit, its fully compatible with SL


  • When you change something to a folder a WebObject points at, you have to remove the WO from Storlyline and add it again.

Pluses using online sources

  • Less code needed to load the libraries


  • As its online, you need a live connection
  • As its online, your loading times increase. Can have impact on mobile.
  • You dont have control over the sources, for some institutions this is crucial
  • As it depends on triggers/urls in SL, you need to ensure they work
  • As Storyline is 32 bit not all packages/sources will work
  • CORS security can block packages
  • To make use of custom scripts you need to upload and maintain them

So i do think this depends on personal preference. But when you work with custom developed scripts ( i do ), the WebObject approach is far better.

Martin Gregson

Thank you for all the input.

I think this information would be very useful if it were put on the best practices page.

As it's been said, the methods mentioned in this thread all have their pros and cons. But more than anything, this information would be extremely useful if it was placed in a more central place to access. 

It might also be a good idea for a screencast of how all these methods can be accomplished.

Once again, many thanks to you all for the input.