libraries

They Myth of Writing Code from "Scratch"

In the JavaScript world it's not uncommon to hear a developer ask another developer "did you build that from scratch or did you use any libraries?", while this is a fairly reasonable question, no software developer ever really builds anything from "scratch", we're always building on top of systems someone else made. Even if a JavaScript developer isn't using any frameworks or libraries, they are most certainly using Web APIs built into the browser. These are APIs designed by working groups and implemented by the developers behind any given browser. The folks who built those browsers may have used other libraries or frameworks, if not they most certainly used APIs provided by the operating system (Linux, Windows or Mac). Those operating systems were developed by other developers, themselves building on the work of others who developed drivers and kernels by other folks who wrote their code to conform to the hardware created by another group of engineers who are themselves building on the designs of the folks that came before them. Writing software is always, consciously or not, a collaborative effort.

"Vanilla" JavaScript

When someone says they wrote something in "vanilla" JavaScript it typically means they didn't rely on any external dependencies, like libraries or frameworks, to write their code. That said, JavaScript, like most programming languages, comes with a built-in "standard library" which is part of the language itself. This includes built-in objects, for example the Math and Date objects. These objects, and every other aspect of the language itself, are designed and maintained by a group of folks at Ecma International, a nonprofit standards organization. But JavaScript (aka ECMAScript) is just an idea, a "specification" or description of how the language is supposed to look like and how it's supposed to work. Languages can't actually be used without a program capable of converting it into machine code the computer can actually run. These programs go by a few different names, "compilers", "interpreters", "run-times", etc. One example is node.js, a JIT (or "just-in-time" compiler).

Web APIs

Web browsers have JavaScript compilers built into them, but they also come with a bunch of APIs. An API (or Application Programming Interface) is a code-based interfaced (as opposed to a graphical interface) that gives a programmer/developer access to data or some functionality another programmer/developer wrote. It's a very broad term that can be used to describe all sorts of code-based interfaces created by devs for other devs. In the case of Web APIs, these are often JavaScript objects and functions that you have direct access to in your code (assuming that code is running in a web browser). The most fundamental of these is likely the DOM API which provides a set of objects and functions for manipulating a web page's HTML and CSS. This includes interfaces like the document and the window objects.

There are also loads of APIs of particular interest to artists. For example the Canvas API gives you access to a series of functions for creating algorithmic/generative 2D graphics (raster based images) from scratch (to learn more check out MDN's Canvas tutorial or Josh Marinacci's HTML5 Canvas Deep Dive), while the WebGL API (an API closely resembling OpenGL) can be used to generate 3D graphics (I wouldn't recommend trying to write too much WebGL from scratch, but here's an introduction to WebGL if you're curious). There's also a Web Audio API which can be used to create algorithmic/generative audio (checkout my series of interactive notes on the Web Audio API to learn more).

Libraries

When a developer writes an application using any number of Web APIs that's still generally considered "vanilla" JavaScript. It's usually when they've included a JS library into their project that they can no longer make this claim. A library is a collection of objects or functions another individual or group created for solving a set of related tasks. These are often built on top of Web APIs in the interest of making these APIs even easier to work with by either "abstracting" some of it's functionality into "higher level" functions and/or adding more functionality to them.

The Web Audio API, for example, can be used to generate sounds, but it has no concept of "music" (things like "notes" and "rythms"), this is why Yotam Mann (with help from dozens of other folks) created Tone.js a JavaScript library built on top of the Web Audio API with functions for creating the kinds of instruments and effects you might find in music applications.

Another example is three.js a library built on top of the WebGL API created by mr.doob (aka Ricardo Cabello, with help from over a thousand other folks). If you want to create a spinning cube with WebGL, you'll have to write hundreds of lines of code, but to do the same thing with three.js only takes a couple dozen lines.

Some libraries actually build on a number of different Web APIs, for example, the p5.js library (created by Lauren McCarthy with help from hundreds more) is most known as a library built on the Canvas API, but it also includes functions built on the DOM, WebGL, Web Audio and other APIs. (in some ways, p5.js is really more of a "framework", but we'll get to that a bit later)

There are loads of other libraries built on top of the Web's more "artistic" APIs we can use to fully leverage the Web's creative potential including...

Libraries are not built into the browser, instead their stored in their own .js files, which you can include (or import) in your project a number of different ways. On the web, we traditionally do this by including a <script src="path/to/library.js"></script> tag in our HTML page with it's src attribute pointing to the .js file. This can be a file locally hosted in your project, or hosted on a server somewhere else (like a CDN). You can also use the import statement to include a library directly in your JavaScript code. When you're writing JavaScript code outside of the browser using node.js you can use the require(path/to/library.js) function to import libraries (also known as "modules" in node.js lingo). If you were to open up one these libraries (by viewing the .js file itself in your code editor or in a browser) you'll see all the code the developers behind the library wrote, check out the code behind the three.js library for example, although it's much more common to find this code "minified" (often designated by the .min.js in the file name's extension) or "compressed" to make the file size smaller and more efficient (as is the case with the three.min.js file). With large libraries like three.js, it's common to actually separate the source code into numerous different files and folders to make them easier to work on and collaborate, before "building" or "compiling" all that code into a single file for distribution and use by others.

It takes a fairly experienced coder to be able to read through the source code of another JavaScript library and be able to understand how it works. This is why the developers behind most libraries also spend time to write "documentation", which usually explain what you need to do to get started using the library as well as a list of all the objects and/or functions built into it. Because of the fact that you (as the user of the library) only ever concern yourself with these functions (there's no need to look a the source code unless you plan on contributing to the library itself) we also often refer to a libraries external functions as it's "API". Some libraries don't have great documentation, but others go above and beyond to include tutorials, examples and more.

You might also see libraries referred to as "dependencies", because when we use libraries to create something, our work is dependent on that library in order to run. Some libraries are themselves dependent on other libraries, and so even when a developer only imports a handful of libraries themselves, the reality is their project may be dependent on dozens of libraries. For example, the way that A-Frame is built on top of three.js. Most of the applications we use on the Internet are dependent on dozens if not hundreds of libraries (I have no evidence for this claim, this is just my personal experience*)

Frameworks

A framework is similar to a library, but is usually a bit more ambitious in scope and often tend to be a bit more opinionated. Like a library, a framework is usually contained in a .js file you need to import/include in your project before you can use it. Like libraries, it's code is written/maintained by a group of developers which often accompany their code with documentation.

Frameworks, however, tend to be a bit bigger (sometimes built on other libraries) and more specific in terms of their purpose. A library like Tone.js can be used to create anything having to do with music, that could be a generative album, a video game, an interactive sound installation, a digital instrument used for live performance or even an entire DAW (digital audio workstation). A framework is usually designed to output something much more specific like a particularly type of application for example. For example A-Frame, is a framework for creating VR applications in HTML code (originally created by the Mozilla VR team, and now maintained by Diego Marcos, Kevin Ngo, Don McCurdy and hundreds of others) it's itself built on top of the three.js library (which itself can be used to create a VR application, but can also be used to create anything having to do with 3D graphics)

Unlike libraries, a framework usually requires that you organize your code a particular way. It may require that you give your files specific names and organize them into specific folders with specific directory structures. It might also come with additional tools and scripts for testing, compiling and even distributing the work you make with it. These days it's very common to use any number of popular JavaScript frameworks to build an application, including AngularJS, Vue.js, React) and many others.