APIs

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 device 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 (here's a demo of the Date object). 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).

API

An API (or Application Programming Interface) is a code-based interface (as opposed to a graphical interface) that gives a programmer/developer access to resoucres, 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.

Web APIs

Web browsers have JavaScript compilers built into them, but they also include a large collection APIs not included in JavaScript's "standard library". 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 DOM

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. For those curious to learn more about it, I've got an intro video tutorial to the DOM API (~1hr), as well as a couple netnet examples:

The DOM also provides us with an API for creating EventListeners which is core to event-driven programming, a "programming paradigm in which the flow of the program is determined by events such as user actions, sensor outputs, or message passing from other programs or threads". I have another tutorial on Event Based Programming with the DOM API (~1hr) as well as a few netnet examples for those curious to learn more:

There are many ways to create animations in the browser besides JavaScript, like SVG animations and CSS animations, but JavaScript is likely the most flexible and expressive ways to approach generative/interactive animations in the browser. The following netnet examples make use of the DOM API to demonstrate a few generative animation core concepts:

Other "creative" Web APIs

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 (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). There are loads more Web APIs (too many to mention here), you can find a full list of Web APIs on MDN.

REST APIs

As discussed in the World Wide Web notes, when we visit a website our browser makes an HTTP request for that HTML as well as subsequent HTTP requests any assets (fonts, images, videos, etc) linked in the HTML page. The difference between a web "page" and a web "app" is the ability to dynamically change the content of our site through user interaction and other events (using the DOM API). We can use a couple of other Web APIs to create our own HTTP requests and dynamically load data from our own server or from servers hosted elsewhere on the web. These are the core technologies that ushered in the era of Web 2.0, sometimes grouped under the label Ajax (or Asynchronous JavaScript).

The most modern approach to making custom HTTP requests in your JavaScript is using the web browser's Fetch API, and what it is most often used for is interfacing with other 3rd party REST APIs hosted on other servers elsewhere on the Web. A 3rd party (meaning operated by someone else) REST API is usually what folks are talking about when you hear them refer to things like the "YouTube API" or the "Twitter API". These are APIs written by other companies or organizations which give other developers access to data or resources hosted on their servers. The way we use these APIs is sending HTTP requests to their servers requesting specific data which the server then sends back to us, usually in a format known as JSON.

I've got a tutorial on making HTTP Requests (~30mins) in JavaScript (using old and new methods) as well as how to use these methods to request data from REST APIs (~1hr), as well as a few netnet examples demoing the basics:

Libraries

(aka "packages", aka "modules", aka "dependencies")

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.

importing libraries

Libraries are not built into the browser, instead they're 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). Another method is to 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).

the source code: inside the library

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.

always read the documentation

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.

Below are some exapmles of JavaScript libraries popular among artists...

Tone.js

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. Here's a netnet example of a basic Tone.js sketch.

three.js

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, here's a basic three.js example in netnet.

hydra

Similar to how Tone.js abstracts the Web Audio API for the specific purpose of using it to create musical works, three.js abstracts the WebGL API for the specific purpose of creating 3D scenes, but the WebGL API can be used to do other stuff as well, like process video and other realtime video effects. Another library that abstracts the WebGL API (as well as another Web API called WebRTC) for these realtimme video purposes is Hydra by Olivia Jack (and a couple dozen other folks). You can learn more about it on their GitHub as well as the Hydra Book and this simple functions reference page. Hydra is predominently used as a realtime performance tool and so it's most commonly performed with using the online Hydra editor, but like any JavaScript library you can incorporate it into anything you make on the Web yourself, here's basic hydra example in netnet which demonstrates this.

p5.js

Some libraries actually build on a number of different Web APIs, one of the most popular examples is 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"...

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.

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.

A-Frame

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). I've created a series of examples as part of an A-Frame workshop.

You might also see libraries and frameworks referred to as "dependencies", because when we use libraries to create something, our work is dependent on that library in order to run. Like A-Frame, 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. 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)

Whether we're using popular coding frameworks or plain "vanilla" JavaScript, like all cultural production, we're always building on the works that came before us. When asked by a music journalist how he felt about others "copying" his style and "stealing" some of his "signature" moves, John Coltrane responded...

...it's a big reservoir man that we all dip out of, you know [...] some of those things on there are really direct influences of listening to this cat, you see, and I don't know who he's been listening to.
John Coltrane

...like Jazz, JavaScript is a big a big reservoir that all coders dip out of. All programmers copy. The difference between a novice and an experience programmer is knowing how/where/when to copy+paste effectively.