Today I’m releasing ShaderPad. It is the library I wish I had a few years ago: a small, focused way to put a shader on a website without rebuilding the same graphics scaffolding every time. If you want to experiment with writing shaders, I think this is one of the best ways to get started.
Note Want to jump right in? The documentation site is live!
Motivation
If you’ve spent much time on this website, you know I mainly use my computer to doodle. Shaders are an expressive way to sketch with code. There are many shader sandboxes online, most notably ShaderToy, that make it easy to write shaders. But platform lock-in makes moving these sketches onto your own website a repetitive hassle.
After wiring up the same graphics boilerplate dozens of times, I started writing a library to make it easier. Over the years, I added features that are useful to me, from autosizing and simple save/share utils, to history buffers, to full-blown MediaPipe integrations. At this point, ShaderPad is extremely useful to me. So I open sourced it, wrote some docs, and now I’m sharing it with you.
There are a lot of artists and creative coders, especially people coming from ShaderToy and TouchDesigner, who already know what they want to make. Hopefully ShaderPad can help put more of those ideas online.
Smaller than your favicon
Lots of big companies (ahem, Stripe) bundle Three.js into their landing page just to render a single fullscreen shader. At 5.8kb gzipped, ShaderPad is over 30x smaller than Three.js. That equates to noticibly faster page loads.
There’s a reason for that size discrepancy. Three.js does wayyyy more than ShaderPad can. If you want to build a full 3D scene, use Three.js. But if all you want is a funky interactive graphic, the cost in bundle size, complexity, and setup is much smaller with ShaderPad.
The main work of designing ShaderPad was deciding what to leave out. I’m happy with where the core API landed; it’s simple enough to learn over a single cup of tea.
... continue reading