Last time we walked the whole long chain backwards -- Jacquard looms, the Bauhaus, the plotter pioneers of 1965, Vera Molnar and her one percent of disorder, LeWitt writing instructions instead of drawing them, right up to Processing and the browser tab you're reading this in. And I left you with a question hanging in the air: if that episode was about looking back down the chain, where does the chain go next? So today we turn around and face forward. This is the episode about the future of creative coding -- what's actually coming, what's just noise, what you should invest your precious learning hours in, and (the part that matters most) what stays exactly the same no matter how the tools change.
I'll be honest with you up front: I find "future" episodes a little dangerous to write, because the field is full of people confidently predicting things that never happen and missing the things that do. So I'm not going to sell you a shiny sci-fi fantasy. I'm going to walk you through the trends I actually see moving, be honest about which ones I trust, and -- more useful than any prediction -- give you a way to think about any new tool that shows up after this series ends. Because that's the real skill. Allez, let me show you how I try to see round the corner without falling for the hype.
Here's the thing to get straight before we look at a single trend: the people who confidently tell you exactly what creative coding will look like in ten years are almost always wrong. In 2010 nobody sane predicted that a browser tab would run real-time 3D, machine-learning models, and audio synthesis all at once. The honest move isn't to predict the future -- it's to prepare for a range of them. I like to make even my own humility concrete by modelling it:
// the future isn't one prediction, it's a probability spread. plan for the range, not the point.
function forecast(trend) {
return {
trend: trend.name,
confidence: trend.confidence, // 0 = wild guess, 1 = near-certain
move: trend.confidence > 0.7
? "worth learning now"
: "watch it, don't bet your week on it",
};
}
console.log(forecast({ name: "the browser stays the canvas", confidence: 0.9 }).move);
// -> "worth learning now"
Look at that confidence field -- that's the whole posture I want you to leave with. Some trends are near-certain (the web keeps being where creative code lives), some are genuine coin-flips (which specific ML tool wins), and treating them as if they're equally solid is how you waste a year learning something that evaporates. So everything I say below comes with a confidence attached, out loud. Don't trust anyone in this field who forgets to do that.
Let's start with the one I'm most confident about, because it's already here. Way back in episode 141 we dipped our toes into WebGPU -- the successor to WebGL that finally gives the browser proper, modern access to the GPU, including compute shaders, not just graphics. This matters enormously for us, because so much creative work is embarassingly parallel: every particle, every pixel, every cell of a simulation can be computed at the same time. WebGPU is the door to doing that at a scale WebGL made painful. Here's the shift in one model:
// WebGL: the GPU was mostly for drawing. WebGPU: the GPU is a general parallel computer.
function whatTheGpuCanDo(era) {
const powers = {
webgl: ["draw triangles", "fragment shaders", "hack compute via textures (painful)"],
webgpu: ["draw triangles", "REAL compute shaders", "millions of agents in parallel"],
};
return powers[era];
}
console.log(whatTheGpuCanDo("webgpu"));
// -> [..., "REAL compute shaders", "millions of agents in parallel"]
Remember the boids in episode 50, the reaction-diffusion in episode 52, the neural cellular automata in episode 151? All of those are simulations where thousands or millions of little things update together -- exactly the workload a compute shader eats for breakfast. WebGPU means the million-particle systems and room-scale simulations that used to need a native app now run in a link you can share with anyone. Confidence: high. This one is not a maybe -- it's shipping, and learning to think in parallel (a grid of work, not a for loop) is a genuinely durable skill. That mental shift outlives whatever the API ends up being called.
Now the trend everyone argues about. Back in episodes 92 through 104 we spent real time on machine-learning models as an artistic material -- pose detection, style transfer, image generation, and then the honest reckoning in episode 104 about tools, ethics, and authorship. That thread isn't going away; if anything it's the fastest-moving corner of the whole field. The important thing is how you frame it. A model is not a magic artist. It's a new kind of brush with very strange bristles -- powerful, unpredictable, and completely dependent on the hand holding it. Let me model the distinction that keeps you sane:
// a model is a MATERIAL, not the artist. authorship lives in the choices, not the output.
function whereIsTheArt(process) {
const machineDid = process.generatedPixels; // yes, but so does a photocopier
const youDid = [
process.choseTheConcept,
process.curatedWhatToKeep, // taste is the work
process.directedAndReworked,
process.tookResponsibility, // ethics + authorship, ep104
];
return youDid.filter(Boolean).length >= 3
? "authored work: the human judgment IS the art"
: "you just pressed a button";
}
See where the art actually lives in that function? Not in the pixels the machine emitted -- in the choosing, the curating, the taking-responsibility. That's the exact authorship argument from episode 104, and it's the thing that stays true no matter how good the models get. My honest read: machine learning becomes a normal part of the creative coder's toolbox, the way the camera became a normal part of an artist's toolbox -- and just like the camera, it won't kill the older ways, it'll sit beside them as one more choice. Confidence: high that it stays relevant, low on any specific tool -- so learn the principles of directing a generative system, not the button layout of this month's favourite. The buttons will change. Taste won't.
Here's a trend I'm genuinly excited about but honestly less certain on: spatial computing -- VR, AR, headsets, art you don't look at so much as stand inside. We got a first taste in episode 78 with WebXR, when we moved a sketch off the flat screen and into a room. The web is quietly growing the ability to place your generative work in actual 3D space, anchored to the real world through a phone or a headset. Think about what that does to everything we've built:
// the canvas is escaping the rectangle. your sketch becomes a place, not a picture.
function stageForWork(medium) {
const stages = {
screen: "a flat rectangle you look at",
xr: "a space you stand inside and walk around",
};
return {
stage: stages[medium],
// every sketch we made can, in principle, be lifted off the screen into here
unlocks: medium === "xr"
? ["scale", "presence", "your body as the camera"]
: ["ubiquity", "zero friction", "share via a link"],
};
}
console.log(stageForWork("xr").unlocks); // -> ["scale", "presence", "your body as the camera"]
Imagine the particle galaxy from episode 15 as something you can walk through, or the L-system plants from episode 54 growing around you at treesize. That's the promise. But notice I called this lower-confidence, and here's why: spatial computing has been "five years away" for about fifteen years now. The hardware keeps almost-arriving. So my advice is warmer than a bet: keep an eye on it, do one XR sketch so the concepts aren't foreign, but don't reorganise your whole practice around a headset that most of your audience doesn't own yet. If it lands, you'll be ready. If it doesn't, you lost an afternoon, not a year.
One trend I'm quietly very confident about is the opposite of headsets: cheap, weird, physical hardware. Remember the whole physical-computing arc, episodes 105 through 116 -- pen plotters, LED walls, projection mapping, a Raspberry Pi as an art platform? The through-line there is that the interface between your code and the world keeps getting cheaper and more varied. Sensors cost pennies. Microcontrollers cost a coffee. Your art no longer has to live behind glass:
// input and output are escaping the mouse+screen. cheap sensors, cheap actuators, everywhere.
function interfaceOptions(year) {
const menu = {
2005: ["mouse", "keyboard", "a screen"],
2025: ["mouse", "keyboard", "screen", "camera", "mic", "$3 motion sensor",
"LED strips", "plotter", "projector", "a Pi in a shoebox"],
};
return menu[year];
}
console.log(interfaceOptions(2025).length); // -> 10 (the menu keeps growing)
Watch that menu grow. The mouse-and-screen assumption we started this series with is just one option now among many, and the list only gets longer and cheaper. This is high-confidence and it's the most accessible frontier -- you don't need a research budget, you need a twelve-euro sensor and the input-mapping skills we already practiced. My genuine belief is that the most interesting creative coding of the next decade happens partly off the screen: light, motion, paper, space. And the skills transfer perfectly, because to your code a motion sensor is just another number coming in, exactly like the mouse position always was.
Zoom out from any single technology and there's a bigger pattern, and this is maybe my highest-confidence call of all: the browser keeps absorbing capabilities that used to require native apps. 3D, GPU compute, audio synthesis, machine learning, gamepad input, MIDI, filesystem access, real-time networking -- one by one they've become things a web page can just do. The web is becoming the universal creative runtime. Here's the trend as a growing list:
// year by year, the browser absorbs another "you need a native app for that" capability.
const browserGained = {
2011: "WebGL -- real-time 3D",
2015: "Web Audio -- a full synthesis engine",
2017: "WebAssembly -- near-native speed",
2019: "in-browser machine learning",
2023: "WebGPU -- general GPU compute",
next: "whatever needed a native app last year",
};
console.log(Object.values(browserGained).at(-1));
// -> "whatever needed a native app last year"
That last line is only half a joke. The pattern is so consistent that "it'll be in the browser soon" is a safer bet than almost any specific prediction. And this is wonderful news for you, because it means the thing you already know -- making visual, interactive work that runs in a tab and ships as a link -- keeps getting more powerful without you having to abandon it for some walled-off native toolchain. The humble p5.js sketch and the cutting-edge WebGPU piece live in the same place now. That convergence is a gift: your existing skills don't get stranded, they compound.
Alright. I've thrown a lot of moving tech at you, and if you're feeling that familiar flutter of "how am I supposed to keep up with all of this" -- good, because this is the section that matters most, and it's the calming one. Underneath every trend above, the fundamentals do not move. The tools churn; the ideas are almost boringly stable. Let me separate the two piles honestly:
// the churn scares beginners. but look how much sits in the STABLE pile. that's your home.
const creativeCoding = {
changesConstantly: ["frameworks", "APIs", "which GPU spec", "which ML model", "hardware"],
basicallyNeverChanges: [
"loops, arrays, functions", // episode 5, still true
"trigonometry for motion", // episode 13, still true
"randomness within rules", // episodes 4 + 24, still true
"colour, composition, contrast", // episode 7, still true
"map a value from one range to another", // the single most-used idea in the series
"taste, judgment, finishing things", // episodes 161-164, permanently true
],
};
console.log(creativeCoding.basicallyNeverChanges.length); // -> 6 rock-solid pillars
Look at the size of that second pile, and look at the episode numbers next to it -- half of them are from the first ten episodes of this series. Every single one is as true today as the day it was discovered, and it'll be just as true when whatever comes after WebGPU arrives. That map function -- taking a value from one range and stretching it into another -- I have used in literally every project I've ever made, and it predates my career and will outlast it. So when the churn makes you anxious, come back and reread this list. You are not standing on sand. You're standing on a bedrock of ideas that has held for decades, and the shiny new tool is just a fresh coat of paint on the same house.
So how do you decide, in practice, what to actually spend your limited learning hours on? This is the most useful rubric I can hand you, and it's simply this: prefer things that transfer. A durable skill -- how light works, how motion feels right, how to debug, how to finish -- pays off across every tool you'll ever touch. A tool-specific trick pays off until that tool dies. Weight your time accordingly:
// spend your learning hours where the payoff outlives the tool. transfer beats trivia.
function worthLearning(skill) {
const transfersEverywhere = skill.appliesAcrossTools; // durable
const diesWithTheTool = skill.tiedToOneAPI; // disposable
if (transfersEverywhere) return { priority: "high", why: "you keep this forever" };
if (diesWithTheTool) return { priority: "learn just-in-time, don't stockpile" };
return { priority: "medium" };
}
console.log(worthLearning({ appliesAcrossTools: true }).why); // -> "you keep this forever"
Notice that "learn just-in-time" verdict -- that's not me telling you to ignore tools, it's me telling you when to learn them: at the moment you need them for a real project, not hoarded in advance out of fear. The specific WebGPU syntax? Learn it when you're building the thing that needs it. How to think about parallelism, colour, motion, and taste? Learn those deeply, now, forever. This is exactly why this whole series kept explaining the why under every technique instead of just the API calls -- the why is the part that transfers, and it's the part that makes the next tool easy instead of terrifying.
The last honest worry: "if I don't learn every new thing, will I fall behind?" And the freeing answer is no -- chasing every trend is actually how people burn out and make nothing, exactly the sustainability trap we keep circling. Relevance doesn't come from knowing every tool; it comes from a strong core plus the ability to pick up new tools quickly when a project genuinely calls for one. Here's the strategy I actually run:
// you don't need to know everything. strong core + fast learning beats frantic tool-chasing.
function stayRelevant(you) {
const solidFoundation = you.knowsFundamentals; // the 6 pillars above
const canLearnFast = you.picksUpToolsWhenNeeded; // because the core transfers
const chasingEverything = you.triesEveryNewThing; // the burnout trap
return solidFoundation && canLearnFast && !chasingEverything
? "relevant AND sane -- you'll still be here in ten years"
: "reconsider: depth beats frantic breadth";
}
console.log(stayRelevant({ knowsFundamentals: true, picksUpToolsWhenNeeded: true, chasingEverything: false }));
// -> "relevant AND sane -- you'll still be here in ten years"
That !chasingEverything is deliberately in there, negated, because trying every shiny thing is a failure mode, not a virtue. The people who are still making great work decades in aren't the ones who learned every framework -- they're the ones who went deep on the fundamentals and then reached for a new tool only when a real idea demanded it. Pick two or three things to actually go deep on, ignore the rest with a clear conscience, and trust that your strong core lets you learn anything else in a weekend when you truly need it. Depth is what keeps you here. Frantic breadth is what wears you out.
Let me close by naming the thing that no trend on this list touches, and it's the thing this whole series has quietly been building toward. Every technology we discussed -- WebGPU, machine learning, XR, cheap sensors -- makes it easier and cheaper to produce output. None of them make the choices for you. As making-things gets easier for everyone, the scarce and valuable thing isn't the ability to render pixels -- it's having something to say with them. A point of view. A voice:
// as production gets trivial for everyone, the scarce thing is having something to SAY.
function whatGetsMoreValuable(future) {
const cheapNow = ["rendering", "raw output", "technical execution"]; // everyone has this
const rareNow = ["a point of view", "your voice", "taste", "why this piece exists"];
return {
commodity: cheapNow, // the machines flood the zone with these
scarce: rareNow, // this is the whole game now
lesson: "the tools got easy. that makes YOU the hard, valuable part.",
};
}
console.log(whatGetsMoreValuable({}).lesson);
// -> "the tools got easy. that makes YOU the hard, valuable part."
That lesson line is the real future of creative coding, and it's the opposite of scary. When production becomes effortless and everyone can generate a thousand pretty images, the pretty images stop being the point -- and the person behind them, with a reason and a perspective and a recognisable hand, becomes the entire point. The future doesn't make you obsolete. It makes the human part of you -- the taste, the story, the why -- the most valuable thing in the room. Which raises the obvious next question, and it's the perfect place for us to go from here: how do you actually find that voice, that thing only you would make? But I'm getting ahead of myself :-).
for loop is a durable skill. Confidence: highmap, taste -- half from the first ten episodes, every one still true. The tools churn; the bedrock holds. Reread that list when the churn makes you anxiousSo that's the road ahead as honestly as I can see it, and I hope you noticed the shape of the whole thing: page after page of dazzling new tech, and every road led straight back to the same unglamorous, permanent core we've been building since episode one. The future of creative coding isn't a tool you need to go buy or a headset you need to strap on. It's you, with your bedrock fundamentals and your own strange taste, ready to pick up whatever shows up next. That's a future you're already prepared for.
And it points right at the thing we do next, because we just landed on the one thing the machines can't hand you: a voice. When everyone can produce endless output at the press of a button, the piece that matters is the one that could only have come from you -- and that raises a genuinly hard, genuinly personal question about what "you" even sounds like on a screen. How do you find the thing that's recognisably yours, the fingerprint that runs through everything you make? That's where we're headed next time. Merci for looking round the corner with me, and go make something only you would make :-).
Sallukes! Thanks for reading.
X
@femdev