The Processing Foundation’s p5.js 2.1 and 2.2 releases mark a significant expansion of what the library can do on the GPU: the experimental WebGPU renderer — roughly half a year in development — is now available directly from the 2.2 build, and p5.strands, p5’s beginner-friendly shader API, has gained support for compute shaders. Follow-up point releases sharpened the picture further, with 2.2.1 flattening and simplifying the p5.strands API and 2.2.2 adding performance improvements plus millis() support inside p5.strands.
Why compute shaders in p5.strands is the notable part
Compute shaders let you run general-purpose parallel computation on the GPU — particle simulations, physics, cellular automata, image processing over enormous datasets — rather than only shading pixels as part of a rendering pass. Historically, reaching them has meant learning a shading language (GLSL or WGSL), plus a graphics API’s buffer and pipeline setup, a barrier that puts them well out of reach for most people whose entry point to code was a p5 sketch. p5.strands’ entire premise is exposing shader capability through JavaScript-flavored syntax rather than a separate shading language, and extending that premise to compute shaders is exactly the kind of accessibility work that has historically defined p5’s contribution to creative coding.
The WebGPU migration path is designed to be gentle
Notably, WebGL shaders written in p5.strands are designed to ultimately work under WebGPU as well — meaning the shader code a p5 user writes today isn’t a dead end when the renderer changes underneath it. That’s a deliberately different migration story than most graphics libraries offer, where a renderer swap typically means rewriting shaders against a new language and API. The p5.strands codebase itself was also refactored and simplified in this cycle, explicitly to make future maintenance and outside contribution easier.
Still experimental, and honest about it
The WebGPU renderer remains labeled experimental for good reason — open issues in the p5.js repository track real problems including text rendering failures in Firefox, model instancing not yet working, and performance regressions in some scenarios. That’s normal for a renderer this new, and the Processing Foundation has been transparent about the state of it rather than overselling readiness. For creative coders who want to experiment with GPU compute without committing to a full WGSL learning curve, though, it’s already a genuinely usable on-ramp — and one that didn’t exist a year ago.