p5.js in 2026: a JavaScript sketchbook for the web, and where it stops being the right tool

The problem p5.js solves is starting, not scaling

Most graphics APIs ask you to set up a rendering context, manage a resize path, and wire a frame loop before anything appears. p5.js removes that preamble. The README's landing example is the whole argument: a setup function, a draw function, and a circle that follows the pointer. There is no context object to hold, no requestAnimationFrame call to schedule, no canvas element to create by hand. The library creates the canvas, calls draw on a loop, and exposes mouseX and mouseY as globals.

That design targets a specific audience. The README names artists, designers, educators, beginners, and anyone else, and describes the project as an approachable language and an exploratory tool. The lineage matters too: p5.js was created by Lauren Lee McCarthy in 2013 as a new interpretation of Processing for the web. If you have written a Processing sketch, the shape of the code will be familiar, but the runtime is the browser, so the output is a page rather than a desktop window.

The trade-off is baked in. Global functions and a global frame loop are excellent for one sketch on one page and awkward inside a component tree that mounts and unmounts. That is not a defect; it is the cost of the entry point being this short.

What actually happens between setup() and draw()

The mechanism visible from the repository is a library that runs in the browser and takes over a canvas. According to the README, p5.js enables thinking of a web page as your sketch, which is a fair summary of the model: a p5 sketch is a page, and the library owns the drawing surface on it.

The dependency list in package.json shows what sits underneath the drawing API. colorjs.io handles colour, libtess handles polygon tessellation, @davepagurek/bezier-path covers bezier geometry, and pako, gifenc and omggif deal with compression and GIF encoding. acorn, acorn-walk, escodegen, esrap and zimmerframe point at source parsing and transformation, which is what you would expect from a library that also ships a web editor and a friendly error system. zod appears alongside them, presumably for validating structured input.

Build tooling is rolldown, configured through rolldown.config.js, with the build script running rolldown -c. Tests run under vitest, including browser tests through @vitest/browser and @vitest/browser-playwright, and there is a separate bench script using vitest bench. Types are generated rather than hand-written: the generate-types script runs the docs build first and then node utils/typescript.mjs. If you consume p5.js from TypeScript, that pipeline is where the declarations come from, and it explains why type accuracy tends to track documentation quality.

Installing p5.js and drawing something that reacts

The fastest path needs no install at all. The README points to the p5.js web editor, where you can start coding in the browser, and to the tutorials and reference on p5js.org. For a local page, the sketch itself is the README example. Save it as sketch.js, open the page, and you should see a white canvas with a circle tracking your cursor.

function setup() {
  createCanvas(400, 400);
  background(255);
}

function draw() {
  circle(mouseX, mouseY, 80);
}

For a project with a bundler, the package name is p5 and it is published on npm, per the npm version badge in the README. The package.json declares "type": "module", so it is ESM-first.

npm install p5

The repository's own dev loop is separate from consuming the library, and it is worth knowing if you intend to contribute. The contributor guidelines link to a quick start for developers, and the scripts are npm run dev for the preview directory, npm run build for a production bundle, npm test for vitest, and npm run lint for oxlint.

Adding p5.js to an existing page, and the React question

Dropping p5.js into a page that already has markup works, but the sketch takes over its canvas, so scope it. Give the sketch its own container and let p5 create the canvas inside it rather than appending to the body, otherwise the layout you already have will fight the sketch.

The harder case is a component framework. p5.js expects setup to run once and draw to run continuously, while a component may mount, unmount and remount. Nothing in the README describes a React binding, and the library does not ship one; the instance mode that p5.js offers is the usual answer, because it lets you keep the sketch's state in a local object instead of on the global scope. Treat that as the design constraint it is: if you need the sketch's lifecycle to match a component's lifecycle, you are writing the glue yourself.

Sound and images follow the same pattern. The README lists sound among the repository topics and the project maintains community libraries, but the core README does not document a load-and-play example, so check the reference and the libraries page before assuming an API shape. Loading assets is asynchronous in the browser, and a sketch that draws before an image finishes loading will show an empty frame; that is a browser behaviour, not a p5.js one, and the library's preload conventions exist to manage it.

Where p5.js is the wrong choice

The library is a sketchbook, and sketchbooks do not come with accessibility guarantees. A canvas is a bitmap. Text drawn into it is not selectable, not searchable, and not exposed to assistive technology the way a heading or a paragraph is. If your output is a chart that a screen reader user must read, or a form, or anything that has to be indexed, drawing it into a canvas is the wrong move. The project's own stated priority is accessibility, and the README links to a contribute/access page, but that is about access to the project and its community, not a claim that canvas output is accessible by default.

Performance is the second boundary. The draw loop runs continuously unless you stop it, which is fine for a 400 by 400 sketch and wasteful for a static diagram. Long-running sketches also accumulate state in globals, and that state is hard to reason about once the sketch grows past a few hundred lines.

The third boundary is scope. p5.js is a client-side platform. It runs in the browser. If you need server-side rendering of the same visuals, or a headless render pipeline, the README does not describe one, and the repository's test setup uses a real browser through Playwright rather than a headless canvas. Do not assume a server path exists because the library is JavaScript.

p5.js against plain canvas and against Processing

The nearest alternative is the Canvas API itself. Plain canvas gives you a context object and explicit control: you decide when to clear, when to redraw, and how to structure state. p5.js gives you the frame loop, the drawing vocabulary and the coordinate helpers. The difference in approach is who owns the loop. With plain canvas you write the loop and can stop it, throttle it or drive it from data. With p5.js the loop is the default and you opt out. For a single interactive artwork, p5.js saves real work. For a dashboard with dozens of small charts, the loop is overhead you did not ask for.

The other alternative is Processing, the desktop project p5.js is based on. The README is explicit that p5.js is a new interpretation for the context of the web, and that the project has allowed itself space to deviate and grow while drawing inspiration from Processing. The practical difference is distribution: a Processing sketch is a desktop application, while a p5.js sketch is a URL. If your audience needs to open the work without installing anything, the web context decides it. If you need the desktop runtime, p5.js is not a substitute.

Within the p5.js ecosystem, the web editor at editor.p5js.org is itself an alternative to a local setup, and for teaching it removes the install step entirely.

Licence, maintenance and what an upgrade costs

p5.js is licensed under LGPL-2.1, per the license.txt file in the repository root. That is a copyleft licence with a linking exception typical of libraries, but the terms are what they are, and if you modify the library itself and distribute it, the obligations differ from merely importing the npm package. This is not legal advice; read license.txt and, for commercial distribution, get your own answer.

The project is not archived, and the last push was on 2026-09-20. Releases are frequent: v2.3.3 on 2026-09-07, v2.3.2 on 2026-07-30, v2.3.1 on 2026-07-21. Note the version mismatch you will meet in the repository: package.json still reads "version": "2.3.2" while v2.3.3 is the latest release, which is normal for a repo between release commits but worth checking when you pin a version. The README also points at a 2.0 beta site and the repository carries rfc_p5js_2.md, so the 2.x line is an active design conversation rather than a frozen API.

Upgrade cost is concentrated in two places. The API surface is wide, and a major version can change drawing defaults or names, so a sketch that runs today is not guaranteed to run unchanged across a major bump. Second, the maintainers are mostly volunteers, as the README states directly, and it asks for patience on issues. That is a real constraint on how fast an upstream fix will arrive. Pin your version, read the release notes for the versions between your pin and the target, and keep the sketch's own code small enough that a rename is a ten-minute fix.

Editorial conclusion

Adopt p5.js when the goal is a sketch, a teaching exercise, a generative artwork or a prototype where the canvas is the product, and start from the p5.js web editor or a script tag before wiring it into a build. Do not adopt it as the rendering layer of a data-heavy application interface. Before committing, check the version field in package.json against the v2.3.3 release, confirm the LGPL-2.1 terms against your distribution model, and read rfc_p5js_2.md if you depend on pre-2.0 behaviour.

Frequently asked questions

Official sources

1. License: LGPL-2.1
2. processing/p5.js on GitHub
3. Project website
4. README
5. Releases