The p5.js online editor is switching its default version to the 2.x line this month — a change that reads like routine version-bumping in the release notes, but is quietly carrying something bigger underneath: an experimental WebGPU renderer that the Processing Foundation team has had in active development for about six months.
What’s actually changing under the hood
Starting with p5.js 2.2, a WebGPU-based renderer sits alongside the existing WebGL renderer rather than replacing it outright. p5.strands, the shader-authoring layer p5.js introduced to make writing custom shaders more approachable, is being extended so that shaders written against it can target WebGPU as well as WebGL — meaning code written today has a real path to running on the newer graphics API without a rewrite. Compute shader support, which WebGL never offered in any practical form, is in active development on top of that renderer.
None of this is cosmetic. WebGL caps out in ways that creative coders run into constantly — particle systems that choke past a few tens of thousands of instances, generative work that has to fake general-purpose computation through fragment shader tricks. Compute shaders remove that ceiling.
It’s not just p5.js
Three.js hit its own WebGPU milestone with r171, where WebGPU support became close to a drop-in replacement — automatic fallback to WebGL 2 on browsers that don’t support it, and Three Shader Language (TSL), which lets a shader be written once and compiled to both WGSL and GLSL instead of maintaining two separate versions. The practical payoff shows up in scale: compute-shader-driven particle systems in Three.js are now handling upward of a million instances, against a WebGL-era ceiling that usually sat closer to fifty thousand.
Combined with WebGPU’s browser support finally reaching Chrome, Edge, Firefox, and Safari (including iOS) as of late 2025, this is less “one library added a feature” and more “the two most-used creative coding frameworks in the browser both quietly cleared the same technical hurdle within months of each other.”
What to actually do with this
If you teach or learn with p5.js, the practical effect is small right now — the WebGPU renderer is experimental, and WebGL remains the safe default for anything you need to just work. But it’s worth deliberately trying a sketch against the WebGPU renderer this month, specifically to find out what breaks. The gap between “experimental renderer exists” and “experimental renderer is what students are using by default” tends to close faster than expected once a project the size of p5.js commits to a direction.