They Myth of Writing Code from "Scratch"
document and the
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).
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)
Here is an example of how to create the classic bouncing ball animation in HTML5 Canvas (using the native Web API), here it is again using the p5.js library (you'll notice that netnet throws a few errors, that's because p5.js does some unconventional things in their code in the interest of being as beginner friendly as possible, here's that same sketch written in a slightly different way, without errors, which also sets us up to add other libraries into this sketch later on)
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...
...Paper.js for creating vector graphics (as opposed to raster graphics, like p5.js), ml5.js for experimenting with machine learning (AI) (built on top of another popular AI library called tensorflow) and hydra.js for creating realtime WebGL "shaders" (this library also abstracts another Web API called WebRTC)
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
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.
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*)
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)