Processing and p5.js — A Production-Focused Review for Media Artists

Processing and p5.js are the standard on-ramp for creative coding. They are the right tools to learn first and the wrong tools to deploy for a five-year installation. This review does not argue you should avoid them — it argues you should know exactly what they are built for and exactly where they stop working. That is a different conversation from most of what you will read about these tools.

What Processing and p5.js Actually Are

Processing is a Java-based programming language and environment for visual artists. p5.js is its JavaScript sibling for the browser. They share a philosophy and a foundation. They are architecturally different tools.

Processing was initiated in 2001 by Casey Reas and Ben Fry, both at the Aesthetics and Computation Group at the MIT Media Lab. The goal was explicit: a programming environment that put visual output first and code complexity second. A tool for artists, not computer scientists. That founding intent — and the open-source commitment that came with it — is why it still runs twenty-five years later.

The Processing Foundation was established in 2012 as a 501(c)(3) nonprofit. Daniel Shiffman joined Reas and Fry as a third project lead. The Foundation’s mandate is to promote software literacy in the arts, particularly through its suite of related projects: Processing (Java), p5.js (JavaScript), Processing for Android, and Processing for Pi. Its 2025 Impact Report notes a pivotal year of evolution, and the Foundation was awarded a €249,900 service agreement by the Sovereign Tech Fund in 2025. Financial reserves have declined from USD 10.7 million at the end of 2022 to USD 8.7 million in 2025 — a 19% decrease that reflects the realities of sustaining open-source infrastructure, not a crisis.

p5.js was created in 2013 by Lauren Lee McCarthy, who led the project until 2020. The current p5.js lead is Kit Kuksenok (2024–present). The relationship to Processing is philosophical more than technical: p5.js brings the same drawing-first, code-second ethos to the browser via JavaScript. As of March 2026, the repository sits at v2.2.3, with 23,600+ GitHub stars, 3,800+ forks, and 14,107 commits. p5.js 2.0 is in active development (beta at beta.p5js.org), with v1.x remaining the default in the p5.js Editor until at least August 2026.

Why Most Artists Start Here — The On-Ramp Case

The reasons to start with Processing or p5.js are legitimate and numerous. No licence cost. Immediate visual feedback. A tutorial ecosystem that no other creative coding tool comes close to matching.

Daniel Shiffman’s Coding Train — the YouTube channel and learning platform at thecodingtrain.com — offers over 35 videos on p5.js alone, alongside dedicated Processing curricula. The channel’s approach is deliberately accessible: no assumed background, immediate visual results, systematic escalation of complexity. For someone entering creative coding from a fine art or design background, this is the path of least resistance. Correctly so.

The institutional footprint matters. Processing is taught in art schools, design programmes, and new media courses across Scandinavia and Europe. The discourse.processing.org forum — active as of April 2026, with PCD @ Worldwide 2026 coordinating celebrations for Processing’s 25th anniversary — is the kind of community infrastructure that takes decades to build. Questions get answered. Beginner work is taken seriously. The entry cost in frustration is low.

For small-format screen-based works, participatory web pieces, or projects where the brief includes “running in a browser”: these tools are not just acceptable, they are correct. The problem is not the tools. The problem is the assumption that the on-ramp and the destination are the same place.

Production Limits — When Processing Is the Wrong Tool

Processing is the best teaching language for creative code. It is not the best deployment environment for a five-year installation with real-time sensor input and multi-channel video. These are different claims. Both are true.

The architectural ceiling is structural, not accidental. Processing is single-threaded by default. Its GPU pipeline runs via OpenGL through JOGL, which trails significantly behind modern GPU capabilities. A complex particle system generating real-time response to motion sensor input, feeding four output channels simultaneously: Processing will hit frame-rate limits that TouchDesigner or openFrameworks handles without effort. The issue is not that the sketches will look wrong. They will be too slow, or the code required to push past the limits will become a maintenance problem faster than you expect.

Three specific scenarios where Processing becomes the wrong choice:

Real-time GPU workload. If the work requires shader-heavy processing, multi-layer compositing at high resolution, or generative 3D at stable frame rates: Processing’s OpenGL path is a handicap. It was not designed for this. openFrameworks or TouchDesigner handle it natively.

Multi-channel video routing. A four-screen installation with independent video feeds, projection mapping, or live compositing across outputs: this is not what Processing is for. The lack of native NDI, Syphon, or Spout support means every integration is an addon, and addons have their own maintenance lifecycles. HC Gilje’s large-scale projection work — see his profile here — has been built primarily in Max/MSP and his own Video Projection Tool, precisely because the signal-routing architecture of those environments suits permanent installation work in ways Processing does not.

Long-running stability. A Processing sketch will run for a long time on a locked machine. But the default memory model in Java has implications for applications running continuously for months: garbage collection pauses, creeping memory consumption from rendering objects that are not properly disposed. These are solvable — but solving them requires Java-level understanding that most media artists who learn Processing do not have, and should not need to develop just to run their work.

p5.js vs Processing — The Browser Question

p5.js runs in a browser tab. That is its largest advantage and its most serious production constraint. They are, in certain contexts, the same thing.

Browser-native deployment is genuinely powerful for participatory work. A piece that runs on any device with a browser — no installation, no platform restriction, no IT department to negotiate with. For web-based commissions, educational contexts, and festival pieces with a short lifecycle: p5.js is the right tool. The v2.2.3 release and the active 2.0 development track signal that the Foundation is investing seriously in keeping this current.

The same browser runtime that makes deployment frictionless becomes a problem the moment the installation context shifts. A JavaScript runtime is not a stable substrate for long-duration unattended deployment. The browser updates. Chrome’s garbage collector makes decisions about memory that will end your piece at 3 AM without warning or logging. Security updates change WebGL API behaviour in ways that can silently break rendering. A gallery running a p5.js installation on a locked-down kiosk running a pinned browser version can mitigate some of this — but “mitigate” is not the same as “solve”.

p5.js with ml5.js is the most accessible AI integration available in this ecosystem. ml5.js — built on TensorFlow.js, developed and maintained by the NYU ITP/IMA programme — offers BodyPose, HandPose, FaceMesh, ImageClassifier, SoundClassifier, and a custom neural network layer, all running in the browser without installation. For an interactive participatory work where visitors stand in front of a camera and the piece responds: this works. The ml5.js team recently shipped a major version with breaking changes, and users encountering issues are directed to the FAQ for accessing the previous version. That sentence is a signal about the operational maturity of the toolchain for unattended gallery deployment. It is not quite there.

The honest framing: use p5.js for web-based works and short-lifecycle gallery pieces. Use Processing when the work needs to survive a macOS update cycle on a dedicated machine without maintenance calls.

Community Health 2025/2026 — Where Governance Stands

Numbers, not impressions. Verified in April 2026.

The processing4 repository on GitHub has 389 stars, 161 forks, and 243 open issues. Latest release: Processing 4.5.2 on January 29, 2026. The Processing Foundation GitHub page notes that Reas and Fry led the project until 2023, with the Foundation now holding copyright and coordination. Processing is in a maintenance phase. Not declining — maintained. For production stability, that is good news. The Foundation’s energy and new investment is concentrated on p5.js 2.0, not on new Processing features.

p5.js is the more active project by every measure. 23,600+ stars, v2.2.3 as of March 2026, 14,107 commits on the main branch, active contributor pipeline. The 2.0 development track (at beta.p5js.org, with a separate dev-2.0 branch) signals sustained investment. The Processing Foundation announced no Fellowship in 2026 while it redesigns the program — a governance note worth tracking, but not a crisis signal for the codebase itself.

The discourse.processing.org forum shows ongoing activity: PCD @ Worldwide 2026 coordination threads are active, technical questions receive responses, and the community covers Android, Raspberry Pi, Arduino integrations alongside core visual work. The community is mature and warm rather than rapidly growing. For someone deploying work: that means answers exist, but cutting-edge feature development is happening in p5.js and p5.js 2.0, not in processing4.

ml5.js sits outside the direct Processing Foundation orbit — it is developed and maintained by NYU ITP/IMA. Active enough, with regular model updates, but the recent breaking-changes release underscores that it is still finding its production stability model. Not a reason to avoid it for the right projects. A reason to know what those projects are.

Nordic Artists Using Processing and p5.js in Installation Practice

Documentation on specific Nordic artists building permanent gallery installations in Processing or p5.js remains fragmentary. This is worth naming honestly rather than papering over with unverifiable claims.

Jonas Jongejan (DK) — formerly at Google Creative Lab, now at Anthropic — has worked extensively in creative coding contexts, including the immersive light installation “Light Leaks” with Kyle McDonald, created for CLICK Festival Denmark in 2013 and subsequently shown at La Gaîte Lyrique (Paris, 2014) and Scopitone Festival (Nantes, 2015). The technical implementation used computer vision and structured light scanning — not p5.js as a deployment environment for an ongoing installation. This is the important distinction: Jongejan is a p5.js ecosystem figure through his tool-building and web work, not through permanent gallery installation in p5.js. The browser and the gallery are different deployment contexts.

Timo Toots (EST) — whose Memopol series won the Ars Electronica Grand Prix in 2012 — represents the kind of durable, data-driven interactive installation work that sits in the Processing lineage philosophically. Memopol ran across multiple venues over years. Whether it was built directly in Processing is not publicly documented in detail; what matters for this review is the model it represents: code-based, data-driven, long-running, institutional. That model is achievable in Processing. The toolchain decisions behind Memopol are not widely documented in English.

The broader pattern in the Nordic scene is that artists who started in Processing — learning the language in school, building early sketches, getting first commissions — have tended to migrate toward TouchDesigner, openFrameworks, or Max/MSP as their work scaled up in hardware complexity and exhibition duration. Processing is the door. Not all rooms are behind it.

Migration Paths — When You Outgrow Them

Most artists who outgrow Processing or p5.js do so because the production context changed, not because they personally got better at coding. A sketch becomes an installation. A web piece becomes a permanent commission. The tool that was right for the prototype is structurally wrong for the deployment.

Processing → TouchDesigner is the most common migration path. The signal: you need real-time sensor input (depth cameras, IR sensors, body tracking) feeding into live video processing, with output to multiple surfaces and hardware control (DMX, MIDI, projection mapping). Processing can handle fragments of this via libraries. TouchDesigner handles all of it natively, and the signal-routing architecture makes complex multi-channel setups manageable rather than heroic. What you lose: the open-source licence safety of Processing. What you gain: a professional production environment that your gallery’s technical team probably already knows. See the full critical review of creative coding tools for a detailed framework.

p5.js → Cables.gl for the browser-native visual programming path, when the artist wants to stay in a browser/web context but needs the node-based workflow of visual programming rather than JavaScript code. Cables.gl is MIT-licensed, genuinely free, and handles WebGL/WebGPU compositing well. It inherits browser dependencies just as p5.js does — the limitations are similar, the workflow is different.

p5.js → Processing (desktop) for the specific case where a web prototype needs to become an offline installation. Not a full rewrite — the Processing and p5.js APIs are intentionally similar — but a port. The browser JavaScript assumptions do not translate automatically. OSC communication, hardware serial, file system access: these all change.

Processing → openFrameworks for artists who want C++ performance, Linux deployment, and a permissive MIT licence with no commercial risk. The hardest migration technically. Also the most architecturally sound for permanent long-running installations. The AI tools context is handled separately in the AI creative coding tools review — including what ml5.js and ml.star can and cannot do in production deployment.

The temptation is to stay on Processing because you know it. Five years into a practice built on a tool that cannot route multi-channel video cleanly: the sunk cost is real but the migration cost keeps growing. The decision is not binary — Processing and a migration target can coexist — but the longer the delay, the more institutional knowledge you are asking yourself to rebuild under deadline pressure.

Frequently Asked Questions