MMP460 – 1100 – Multimedia Project Lab – Spring 2022
Ressources for students
MMP460 – 1100 – Multimedia Project Lab – Spring 2022

JS Libraries

What are JS libraries?

JS (Javascript) is the programming language of the web. It is used to create slideshows, to sort through categories etc. There are also Javascript libraries: collections of pre-written JavaScript code that simplify the creation of common tasks and behaviors. 

While some developers like using plain/vanilla Javascript, new libraries/frameworks are constantly being developed and they can save you a great deal of time.

Framework vs. library

While both JS frameworks and libraries are as set of code written by someone else that you can use for your own projects, they differ in scope and control level.

  • Libraries are often dedicated to a single type of functionality and can be integrated into any part of your project.
  • Frameworks  determines the flow of your project and has pre-assigned building blocks you can use in certain pre-defined ways.

Here’s an interesting analogy from Brandon Wozniewicz on freecodeCamp:

A library is like going to Ikea. You already have a home, but you need a bit of help with furniture. You don’t feel like making your own table from scratch. Ikea allows you to pick and choose different things to go in your home. You are in control.

A framework, on the other hand, is like building a model home. You have a set of blueprints and a few limited choices when it comes to architecture and design. Ultimately, the contractor and blueprint are in control. And they will let you know when and where you can provide your input.

While JS frameworks can be very useful , they can take a while to get familiar with. In this workshop, we will focus on JS libraries, but here are a few popular frameworks for you to look into if you’re interested.

  • Angular.io: One of the most popular and well-maintained (by Google) cross-platform framework
  • Aurelia.io: Allows you to create components with vanilla JS

Which JS library should you use?

You may find hundreds of JS library options for a single functionality. How do you pick which one to use? Here are some tips (from Khan Academy):

  • Well documented: It should be easy to find a reference of function signatures, demos of actual usage, and a more narrative how-to-use guide. If a library has no documentation, it’s usually a sign that they are not the most developer-friendly.
  • Flexible: The demos in the documentation might look great – but might want to use a library in a slightly or completely different way than what the demos show. Look for signs of flexibility – Is it easy to send in configuration options? Is there a documented plugin architecture? Does it trigger many events that you could hook your code into?
  • Actively maintained: Browsers change frequently. Libraries that once worked can suddenly stop working, because they relied on some quirk of the browser that changed. This is specially true of HTML5 shims and polyfills (libraries that enable all new HTML5 elements and sectioning in old browsers), because browsers are frequently releasing new versions with evolving implementations of the HTML5 elements. You can figure out how recently the library was updated by checking the date in their changelog. If there’s no changelog and the library is hosted in an open source repository like Github, you can check the date of the last commit.
  • Future thinking: If you’re looking for an HTML5 “shim”, prefer a “polyfill” – a shim that mimics the API. That way, theoretically, when all your users were using browsers that supported the technology, you’d be able to stop using the library entirely, with no change to your code at all. For example, if you’re using a library to use video in your webpage, use a polyfill that will let you use the HTML5 video tag, and it will replace it with a fallback technology like Flash in older browsers.
  • Tested: All good libraries should include tests that make sure their functionality works as expected. When a library is tested, then we can have confidence there will be some degree of backwards compatibility in new versions of the library.
  • Clean code: We could treat open-source libraries as black boxes, and refuse to look inside of them, but sometimes, you may need to dig inside of the library code to debug an issue or add a new bit of functionality. Take a quick look at the code and see how easy it is to read, and if it has any red flags, like big chunks of commented-out lines of code.
  • Responsive community: You will have questions. You will encounter bugs. Ideally, you’ll be able to figure them out with developers, whether that’s the maintainers or users.
If the library is hosted on a version control site like Github, you can look at:
  • Number of forks: Lots of forks (or stars) means there are at least a lot of developers that cared enough to fork the library. That doesn’t mean they’ll help you, but it’s a start! Large libraries often have thousands of forks, more niche libraries have 100s or 10s of forks.
  • Number of issues: Are there many open issues? That might be a sign that there’s not a community effort around responding and closing issues. It can also mean it’s just a very popular project with a lot of ideas for improvement, so continue on to the next point.
  • Vibe on issues: Read through a few issues and pull requests. Are the maintainers receptive to feedback? Do they answer usage questions? Do you get a positive or negative vibe from the conversations on them?
  • External community: Are questions about the library answered on StackOverflow? Are there libraries that build on top of the library? Many smaller libraries won’t be big enough to have a visible external community, but bigger ones like Modernizr or Backbone have significant ones, and that’s a big motivation for using them. You can do a search on the internet for the library name to see what kind of results you find.

A few useful JS libraries

Here are a few well-documented and maintained libraries for common behaviors:

Food for thought