The Generative Design code package is a book of p5.js sketches, not a library
Code package of the book: Generative Design – Creative Coding for the Web with JavaScript in p5.js
At a glance
- What is it?
- Code-Package-p5.js holds the source for the book Generative Design: Creative Coding for the Web with JavaScript in p5.js, organised into three chapter directories with an index page, a shared generative-design-library and a budo dev server. It is Apache-2.0 licensed and released with the book as a single archive.
- Who is it for?
- Code-Package-p5.js fits a reader who bought or read Generative Design and wants the sketches running locally rather than reading them as images in a book, since the archive is arranged as browsable HTML pages rather than a module you import. It does not fit a developer looking for a reusable generative art library, because the shared code here is the book's own library and the project is versioned with the book rather than as an npm package.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
It is the book's source, arranged as a browsable gallery
The repository holds all of the source code for the book Generative Design: Creative Coding for the Web with JavaScript in p5.js, and the README opens by telling the reader to follow the Setup and Running the Sketches sections. The tone is that of a companion archive for a book rather than a software product.
The authors are Benedikt Groß, Hartmut Bohnacker, Julia Laub and Claudius Lazzeroni, with contributions by Joey Lee and Niels Poldervaart, and the book's second edition site is at generative-gestaltung.de/2, which is the homepage of the repository as well.
The top level listing shows the shape immediately.
01_P/
02_M/
03_A/
data/
index.html
libraries/
styles/The three numbered directories are the book chapters, and the numbering with a letter suffix suggests a chapter and section structure, 01, 02 and 03, which is how a book is laid out. The index.html at the root is the list of all sketches, and the npm start script opens it automatically, so the archive is meant to be browsed as a gallery rather than read as source.
The supporting directories are the interesting part for a developer. The data/ directory holds the assets the sketches reference, the libraries/ directory holds the shared code, and styles/ holds the stylesheets that give the pages a consistent presentation. That separation is what lets the archive work as a browsable book site.
The changelog.md at the root tracks changes across the versions, and the version 1.4.3 in package.json matches the v1.4.3 tag from 2025-05-14, with v1.4.2 from 2024-11-22 and v1.4.1 from 2024-04-29 before it.
Two scripts do the real work of vendoring the libraries
The package.json is small but the two extra scripts are where the interesting engineering sits.
"scripts": {
"start": "npm run watch",
"watch": "budo --host localhost --dir . --open --live --watch-glob '**/*.{html,css,js}'",
"setup": "cd libraries && node setup.js",
"encapsulate": "cd libraries && node encapsulate.js"
}The watch script runs budo with live reload, watching html, css and js files, opening the browser automatically, and serving from the current directory. That is the reading experience for the archive, and it is a single command once the dependencies are installed.
The setup and encapsulate scripts are the unusual ones, and they are the reason the package.json has an install section with a sources mapping. The install hook maps the p5 package to node_modules/p5/lib/p5.min.js, the generative-design-library to its dist bundle, and g.js to a path inside node_modules, and the setup script in libraries/ copies those files into the libraries/ directory. The encapsulate script in the same directory does the reverse kind of work, wrapping the library into a form the sketches can load.
The reason for this is visible in the README's explanation of why a web server is needed at all. The sketches are plain pages that load their libraries by relative path, so the libraries have to exist next to the pages rather than being resolved by a bundler. The setup step performs that copy once, after npm install, and the encapsulate step packages the shared library for inclusion.
So there are two ways to work with this archive. You can run the sketches as static pages, which is what a reader does, or you can contribute changes to the shared library, which is what the setup step is for. The README draws exactly that line, saying the setup allows you to download the dependencies related to contributing changes to the project, and that if that sounds too foreign you can jump to Running the Sketches.
A local web server is not optional for some sketches
The Running the Sketches section explains a failure that beginners always hit, and the explanation is worth repeating because the symptom is confusing.
Most of the sketches work without a local web server, but some will not run properly since they use external files, images or data, to create and inform the visualization. The README gives two options for serving them.
The first is any local server, and the simplest is Python's built-in one.
$ cd path/to/folder
$ python -m http.server
# check localhost:8000The default port is 8000 and you can change it by specifying the number after the command, for example python -m http.server 5000.
The second is npm start, which uses budo and gives live reload, and it opens index.html in a new browser window so you can click through the list of sketches.
The footnote explains why the server is needed at all. Some sketches work only as expected when the files are placed online, as they rely on security-sensitive functionality like loading external files. If you view them locally without a web server, you get some kind of cross-origin errors in the browser console.
That is the browser's file access policy rather than a bug in the sketches, and it is the single most common reason a sketch appears broken when the archive is opened by double clicking an HTML file. The rule of thumb from the README is simple: if a sketch that loads external assets shows nothing, serve the directory rather than opening the file directly.
The dependency list is a working creative coding toolchain
The dependency list is a good indicator of what the book teaches, because each library corresponds to a technique the sketches demonstrate.
The core is p5 at ^1.11.13, the drawing library the whole archive is built on, plus generative-design-library.js at ^0.1.2, which is the shared helper library the book develops alongside the sketches, and g.js at ^0.1.17, which is the generative library the book is closely associated with. Those three are the ones the install script copies into libraries/.
The rest are the supporting cast. chroma-js at ^2.6.0 for colour manipulation, which is unavoidable in a book about generative colour, and opentype.js at ^1.3.5 for working with fonts and glyph outlines. tooltipster at ^4.2.8 for the tooltips the sketches show, and jquery at ^4.0.0, which is there for the DOM work the generative canvas cannot do on its own.
The build tooling is present too. budo is the dev server, cheerio is an HTML parser used by the setup and encapsulate scripts to rewrite the library references in the pages, fs-extra and fs-sync are file helpers, glob finds files, and the source-map family, source-map-concat, source-map-dummy and source-map-resolve, handles source maps while the library is being bundled.
That last group explains what the encapsulate script is for. Combining the shared library and its dependencies into one file, while keeping the source maps meaningful, is a fiddly operation and it is exactly what a source-map-concat plus a dummy plus a resolver combination is for.
Where this code package is the wrong thing to reach for
The first wrong case is a developer looking for a generative art library. This is not that. The shared code in libraries/ is the book's own library, published as generative-design-library.js and versioned alongside the book at 0.1.2, and the repository is the archive for a specific publication rather than a maintained software project. The release history makes that clear, with versions named after the book, Generative Design Code Package for p5.js, Version 1.4.3, 14 May 2025.
The second wrong case is a production application. The archive has no build pipeline for deployment, no type checking, no test suite and no packaging. The npm scripts are start, watch, setup and encapsulate, and the whole point is to be opened in a browser. Adapting it into a product means taking the sketches apart, and at that point you want g.js or p5.js directly.
The third wrong case is expecting current tooling. The repository has an .eslintrc and an .eslintignore and a .editorconfig, so linting is configured, but there is no lint script in package.json and no CI configuration described. The package-lock.json is present, so the dependency set is pinned to a known state, and the dependencies themselves are of a generation, jquery at version 4 and glob at 7 among them, that will age.
The fourth wrong case is a team expecting a maintained upstream. The last push to master was on 2026-10-14, but the newest tagged release is v1.4.3 from 2025-05-14 and the versions move with the book, so the repository is not a place where a bug gets fixed on request. For a book archive that is entirely appropriate. For a dependency it would be a problem.
How it differs from a p5.js sketch collection on the web
The comparison worth making is with the many sketch collections published on CodePen, Glitch and similar sites, and the difference is the packaging.
A web sketch collection is usually a set of standalone pages, each with its own HTML file, its own script tag block and its own copy of the library. It works, and it is easy to share a single sketch. What it does not have is a shared codebase that the sketches build on, so the techniques in sketch 40 duplicate the techniques in sketch 3, and the author of the collection maintains a library only if they build one separately.
This archive takes the other approach. The libraries/ directory is the shared code, the chapters are numbered directories that reference it, and the setup script's job is to make sure that shared code is physically present next to the pages. The result is that the book can teach a library incrementally, adding to it over the course of the chapters, and the sketches are the exercises that use it. A collection of standalone pages cannot teach that way, because each page would need its own copy of the final library.
The second difference is the reader experience. The index.html with a list of all sketches, a live reload server and a consistent stylesheet is a book-shaped interface. You move through the chapters in order, you see the sketches in a grid, you click into one, you interact with it. A CodePen collection is a feed you browse. The archive is deliberately the other thing.
The third difference is the licence, and it is a permissive one. All of the book's source code is licensed under the Apache License Version 2.0, with a LICENSE file at the root. For an educational work that a reader might want to adapt, that is a better outcome than a book that arrives with a restrictive notice, and it means the sketches can legitimately end up in your own work.
Editorial conclusion
Code-Package-p5.js fits a reader who bought or read Generative Design and wants the sketches running locally rather than reading them as images in a book, since the archive is arranged as browsable HTML pages rather than a module you import. It does not fit a developer looking for a reusable generative art library, because the shared code here is the book's own library and the project is versioned with the book rather than as an npm package. Before using it, read the Setup and Running the Sketches sections, note that a local web server is required for the sketches that load external files, and check the current version, 1.4.3 from 2025-05-14, with the last push on 2026-10-14.
Frequently asked questions
How do I run the sketches in the Generative Design code package?
Install node.js, navigate into the Code-Package-p5.js folder and run npm install, then run npm start. That launches a budo web server with live reload on localhost and opens index.html, the list of all sketches, in a new browser window. You can also use any local server, for example python -m http.server on port 8000.
Why do some sketches fail with cross-origin errors?
Some sketches load external files such as images or data, and browsers refuse those loads when the page is opened directly from the filesystem. The README explains that such sketches only work as expected when the files are served, so the fix is to run a local web server, which is what npm start does.
What are the npm setup and encapsulate scripts for?
The setup script runs node setup.js inside the libraries/ directory to copy the p5, generative-design-library and g.js builds out of node_modules next to the sketches, and the encapsulate script runs node encapsulate.js to package the shared library. The package.json install section maps each dependency to the file it copies.
Who wrote the Generative Design code package and what licence is it under?
The book is by Benedikt Gross, Hartmut Bohnacker, Julia Laub and Claudius Lazzeroni, with contributions from Joey Lee and Niels Poldervaart. All of the book's source code is licensed under the Apache License Version 2.0, with a LICENSE file at the root of the repository.
What is the current version of the Generative Design p5.js code package?
The package.json version is 1.4.3, matching the v1.4.3 tag from 2025-05-14, with v1.4.2 from 2024-11-22 and v1.4.1 from 2024-04-29 before it. The last push to master was on 2026-10-14, and a changelog.md at the root records the changes.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/generative-design-code-package-p5-js)Was this useful?