Processing och p5.js — en produktionsfokuserad recension för mediekonstnärer

Processing och p5.js är standardrampen in i kreativ kod. De är rätt verktyg att börja med och fel verktyg att driftsätta i en femårig installation. Den här recensionen argumenterar inte för att du ska undvika dem — den argumenterar för att du ska veta exakt vad de är byggda för och exakt var de slutar fungera. Det är en annan konversation än den mesta av det du annars hittar om dessa verktyg.

Vad Processing och p5.js faktiskt är

Processing är ett Java-baserat programmeringsspråk och en miljö för visuella konstnärer. p5.js är dess JavaScript-syskon för webbläsaren. De delar en filosofi och en stiftelse. De är arkitekturellt sett olika verktyg.

Processing initierades 2001 av Casey Reas och Ben Fry, båda vid Aesthetics and Computation Group på MIT Media Lab. Syftet var uttalat: en programmieringsmiljö som satte visuell output först och kodkomplexitet i andra hand. Ett verktyg för konstnärer, inte datavetenskap. Det grundläggande intentionen — och open source-åtagandet som följde med den — är anledningen till att det fortfarande körs tjugofem år senare.

Processing Foundation etablerades 2012 som en 501(c)(3) ideell organisation. Daniel Shiffman anslöt sig till Reas och Fry som tredje projektledare. Stiftelsens mandat är att främja mjukvarukompetens inom konsten, framförallt via sin uppsättning relaterade projekt: Processing (Java), p5.js (JavaScript), Processing for Android och Processing for Pi. Stiftelsens finansiella reserver sjönk från 10,7 miljoner USD i slutet av 2022 till 8,7 miljoner USD 2025 — en minskning på 19 procent som speglar verkligheten i att upprätthålla open source-infrastruktur, inte en kris. År 2025 tilldelades stiftelsen ett serviceavtal på 249 900 euro från Sovereign Tech Fund.

p5.js skapades 2013 av Lauren Lee McCarthy, som ledde projektet till 2020. Nuvarande p5.js-ledare är Kit Kuksenok (2024–nutid). Relationen till Processing är mer filosofisk än teknisk: p5.js för samma ritning-först, kod-sedan-mentalitet till webbläsaren via JavaScript. Per mars 2026 befinner sig repositoriet på v2.2.3, med 23 600+ GitHub-stjärnor, 3 800+ forks och 14 107 commits. p5.js 2.0 är under aktiv utveckling (beta på beta.p5js.org), med v1.x kvar som standard i p5.js Editor till åtminstone augusti 2026.

Varför de flesta konstnärer börjar här — infartsrampen

Skälen att börja med Processing eller p5.js är legitima och talrika. Ingen licensavgift. Omedelbar visuell återkoppling. Ett tutorialekosystem som inget annat kreativt kodverktyg ens är i närheten av att matcha.

Daniel Shiffmans Coding Train — YouTube-kanalen och lärplattformen på thecodingtrain.com — erbjuder över 35 videor om p5.js ensamt, bredvid dedikerade Processing-kurser. Kanalens ansats är avsiktligt tillgänglig: ingen antagen bakgrund, omedelbart visuella resultat, systematisk eskalering av komplexitet. För någon som kommer till kreativ kod från bildkonst eller design är detta minsta motståndets väg. Och det är rätt.

Det institutionella fotavtrycket spelar roll. Processing undervisas i konstskolor, designprogram och nya medier-kurser över hela Skandinavien och Europa. Forumet på discourse.processing.org — aktivt per april 2026, med PCD @ Worldwide 2026 som koordinerar firandet av Processings 25-årsjubileum — är den typ av communityinfrastruktur det tar decennier att bygga. Frågor besvaras. Nybörjararbete tas på allvar. Ingångskostnaden i frustration är låg.

För småformat skärmbaserade verk, deltagandebaserade webbprojekt, eller projekt där beställningen innehåller frasen "ska köra i en webbläsare": dessa verktyg är inte bara acceptabla, de är korrekta. Problemet är inte verktygen. Problemet är antagandet att rampen in och slutdestinationen är samma plats.

Produktionsbegränsningar — när Processing är fel verktyg

Processing är fortfarande bäst som undervisningsspråk för kreativ kod. Det är inte bäst för en femårig installation med realtidssensorinput och flerkanalig video. Det är två skilda påståenden. Båda är sanna.

Arkitekturstaket är strukturellt, inte av misstag. Processing är enkeltrådat som standard. Dess GPU-pipeline körs via OpenGL genom JOGL, vilket halkar avsevärt efter moderna GPU-kapaciteter. Ett komplext partikelsystem som genererar realtidssvar på rörelsesensorsignal och matar fyra parallella utmatningskanaler: Processing stöter på bildhastighetstak som TouchDesigner eller openFrameworks hanterar utan ansträngning. Det handlar inte om att skisserna ser fel ut. De blir för långsamma, eller också kräver koden som behövs för att pressa igenom begränsningarna ett underhållsarbete som tilltar fortare än man tror.

Tre specifika situationer där Processing blir fel val:

Realtids-GPU-belastning. Om verket kräver shader-intensiv bearbetning, flerlagers kompositing i hög upplösning, eller generativ 3D med stabila bildhastigheter: Processings OpenGL-väg är ett handikapp. Det var inte designat för detta. openFrameworks eller TouchDesigner hanterar det nativt.

Flerkanalig videostyrning. En fyra-skärmars installation med fristående videoflöden, projiceringsmapping eller levande kompositing över utmatningar: det är inte vad Processing är till för. Avsaknaden av nativt stöd för NDI, Syphon eller Spout innebär att varje integration är ett tillägg, och tillägg har sina egna underhållscykler. HC Gilje — vars storskaliga projiceringsarbete du hittar i hans profil här — har byggt sin praktik primärt i Max/MSP och hans eget Video Projection Tool, just för att signal-routingarkitekturen i de miljöerna passar permanent installationsarbete på sätt som Processing inte gör.

Långvarig stabilitet. En Processing-sketch kör länge på en låst maskin. Men Javas standardminnesmodnell har konsekvenser för applikationer som körs kontinuerligt i månader: garbage collection-pauser, smygande minnesförbrukning från renderingsobjekt som inte städas upp ordentligt. Det är lösbara problem — men att lösa dem kräver Java-kunskaper på en nivå som de flesta mediekonstnärer som lär sig Processing varken har eller bör behöva skaffa sig bara för att hålla sin installation igång.

p5.js mot Processing — webbläsarfrågan

p5.js körs i en webbläsarflik. Det är dess största fördel och dess allvarligaste produktionsbegränsning. I vissa sammanhang är de exakt samma sak.

Webbläsarnativ driftsättning är genuint kraftfull för deltagandebaserade verk. Ett verk som körs på vilken enhet som helst med en webbläsare — ingen installation, ingen plattformsbegränsning, ingen IT-avdelning att förhandla med. För webbaserade beställningar, pedagogiska sammanhang och festivalprojekt med kort livslängd: p5.js är rätt verktyg. Versionen v2.2.3 och det aktiva 2.0-utvecklingsspåret signalerar att stiftelsen investerar seriöst i att hålla detta aktuellt.

Samma webbläsarruntime som gör driftsättning friktionsfri blir ett problem i det ögonblick installationskontexten förändras. En JavaScript-runtime är inte ett stabilt substrat för långvarig obevakad driftsättning. Webbläsaren uppdaterar sig. Chromes garbage collector fattar beslut om minne som kan stänga ner ditt verk klockan tre på natten utan varning eller loggning. Säkerhetsuppdateringar förändrar WebGL API-beteende på sätt som kan bryta renderingen tyst. Ett galleri som kör en p5.js-installation på en låst kiosk med en fastnålad webbläsarversion kan mildra en del av detta — men "mildra" är inte samma sak som "lösa".

p5.js med ml5.js är den mest tillgängliga AI-integrationen som finns i detta ekosystem. ml5.js — byggt på TensorFlow.js, utvecklat och underhållet av NYU ITP/IMA-programmet — erbjuder BodyPose, HandPose, FaceMesh, ImageClassifier, SoundClassifier och ett anpassningsbart neuralt nätverkslager, allt körandes i webbläsaren utan installation. För ett interaktivt deltagandeverk där besökare ställer sig framför en kamera och verket svarar: detta fungerar. ml5.js-teamet levererade nyligen en huvudversion med brytande förändringar, och användare som stöter på problem hänvisas till FAQ:n för åtkomst till den föregående versionen. Den meningen är en signal om verktygskedjans operationella mognad för obevakad galleridriftsättning. Den är inte riktigt där ännu.

Den ärliga inramningen: använd p5.js för webbaserade verk och kortlivade galleriprojekt. Använd Processing när verket behöver överleva en macOS-uppdateringscykel på en dedikerad maskin utan servicesamtal.

Community-hälsa 2025/2026 — governance-status

Siffror, inte intryck. Verifierat april 2026.

processing4-repositoriet på GitHub har 389 stjärnor, 161 forks och 243 öppna issues. Senaste release: Processing 4.5.2 den 29 januari 2026. Processing Foundation GitHub-sidan noterar att Reas och Fry ledde projektet till 2023, med stiftelsen som nu håller upphovsrätt och samordning. Processing befinner sig i ett underhållsfas. Inte på nedgång — underhållet. För produktionsstabilitet är det goda nyheter. Stiftelsens energi och nya investeringar är koncentrerade på p5.js 2.0, inte på nya Processing-funktioner.

p5.js är det mer aktiva projektet på alla mätvärden. 23 600+ stjärnor, v2.2.3 per mars 2026, 14 107 commits på main-grenen, aktiv bidragsgivarstruktur. 2.0-utvecklingsspåret (på beta.p5js.org, med en separat dev-2.0-gren) signalerar fortsatt investering. Processing Foundation meddelade inget Fellowship 2026 medan man omdesignar programmet — en governance-notering värd att följa, men inte en kris-signal för kodbasen i sig.

Forumet på discourse.processing.org visar pågående aktivitet: PCD @ Worldwide 2026-koordinationstrådar är aktiva, tekniska frågor får svar och communityn täcker Android, Raspberry Pi, Arduino-integrationer vid sidan av kärn-visualarbetet. Communityn är mogen och varm snarare än snabbt växande. För någon som driftsätter verk: det innebär att svar finns, men banbrytande funktionsutveckling sker i p5.js och p5.js 2.0 — inte i processing4.

ml5.js befinner sig utanför Processing Foundations direkta inflytandesfär — det utvecklas och underhålls av NYU ITP/IMA. Tillräckligt aktivt, med regelbundna modelluppdateringar, men den nyliga major-versionen med brytande förändringar understryker att det fortfarande söker sin produktionsstabilitetsmodell. Inte skäl att undvika det för rätt projekt. Skäl att veta vilka de projekten är.

Nordiska konstnärer som använder Processing och p5.js i installationspraktik

Dokumentation om specifika nordiska konstnärer som bygger permanenta gallerinstallationer i Processing eller p5.js är fragmentarisk. Det är värt att nämna ärligt snarare än att plåstra över med overifierbara påståenden.

Jonas Jongejan (DK) — tidigare på Google Creative Lab, nu på Anthropic — har arbetat extensivt i kreativa kodsammanhang, inklusive ljusinstallationen "Light Leaks" med Kyle McDonald, skapad för CLICK Festival i Danmark 2013 och sedan visad på La Gaîte Lyrique (Paris, 2014) och Scopitone-festivalen (Nantes, 2015). Den tekniska implementeringen använde datorseende och strukturerat ljus — inte p5.js som en driftsättningsmiljö för en pågående installation. Distinktionen är viktig: Jongejan är en p5.js-ekosystemfigur via sitt verktygsbyggande och webbarbete, inte via permanent gallerinstallation i p5.js. Webbläsaren och galleriet är olika driftsättningskontexter.

Timo Toots (EST) — vars Memopol-serie vann Ars Electronica Grand Prix 2012 — representerar den typ av hållbart, datadrivet interaktivt installationsarbete som filosofiskt sett befinner sig i Processing-linjen. Memopol kördes på flera platser under år. Huruvida det byggdes direkt i Processing är inte offentligt dokumenterat i detalj; vad som är relevant för den här recensionen är den modell det representerar: kodbaserat, datadrivet, långkörande, institutionellt. Den modellen är uppnåelig i Processing. Verktygskedjebesluten bakom Memopol är inte brett dokumenterade på svenska eller engelska.

Det bredare mönstret i den nordiska scenen — och det är ett mönster snarare än ett undantag — är att konstnärer som börjat i Processing har tenderat att migrera mot TouchDesigner, openFrameworks eller Max/MSP när deras arbete skalat upp i hårdvarukomplexitet och utställningstid. Processing är dörren. Alla rum finns inte bakom den.

Migrationsvägar — när man växer ur dem

De flesta konstnärer som växer ur Processing eller p5.js gör det för att produktionskontexten förändrades, inte för att de personligen blev bättre på att koda. En sketch blir en installation. Ett webbprojekt blir en permanent beställning. Verktyget som var rätt för prototypen är strukturellt fel för driftsättningen.

Processing → TouchDesigner är den vanligaste migrationssökvägen. Signalen: du behöver realtidssensorinput (djupkameror, IR-sensorer, kroppsspårning) som matar in i levande videobearbetning, med output till flera ytor och hårdvarukontroll (DMX, MIDI, projiceringsmapping). Processing kan hantera fragment av detta via bibliotek. TouchDesigner hanterar allt nativt, och signal-routingarkitekturen gör komplexa flerkanaliga upplägg hanterbara snarare än heroiska. Vad du förlorar: Processings open source-licenssäkerhet. Vad du vinner: en professionell produktionsmiljö som ditt galleris tekniska team förmodligen redan känner till. Se den fullständiga kritiska recensionen av kreativa kodverktyg för ett detaljerat ramverk.

p5.js → Cables.gl för den webbläsarnativa visuella programmeringsvägen, när konstnären vill stanna i en webb/webbläsarkontext men behöver det nodbaserade arbetsflödet för visuell programmering snarare än JavaScript-kod. Cables.gl är MIT-licensierat, genuint gratis och hanterar WebGL/WebGPU-kompositing väl. Det ärver webbläsarberoenden precis som p5.js gör — begränsningarna är liknande, arbetsflödet är annorlunda.

p5.js → Processing (skrivbordsversionen) för det specifika fallet där en webbprototyp behöver bli en offlineinstallation. Ingen fullständig omskrivning — Processing- och p5.js-API:erna är avsiktligt lika — men en port. Webbläsarens JavaScript-antaganden översätts inte automatiskt. OSC-kommunikation, hårdvaruseriekommunikation, filsystemsåtkomst: allt det förändras.

Processing → openFrameworks för konstnärer som vill ha C++-prestanda, Linux-driftsättning och en tillåtande MIT-licens utan kommersiell risk. Den tekniskt svåraste migrationen. Också den mest arkitekturellt solida för permanenta långkörande installationer. AI-verktygssammanhanget behandlas separat i AI-kodverktygsrecensionen — inklusive vad ml5.js och ml.star kan och inte kan göra i produktionsdriftsättning.

Frestelsen är att stanna på Processing för att man känner det. Fem år in i en praktik byggd på ett verktyg som inte kan rutta flerkanalig video rent: sunk cost-effekten är verklig men migrationskostnaden fortsätter att växa. Beslutet är inte binärt — Processing och ett migrationsmål kan samexistera — men ju längre fördröjningen, desto mer institutionellt kunnande ber du dig själv att bygga om under deadline-press.

Vanliga frågor