I considered WebGL, and I agree—a shader is more performant for real-time effects.
But WebGL comes with drawbacks:
- You need JS code running before anything shows up.
- Shaders can’t directly manipulate the DOM render. To make refraction work, you’d have to re-render everything into a canvas—which isn’t really “the web” anymore.
With the SVG/CSS approach, you can pre-render the displacement map (at build time or on the backend) and get the refraction visible on the very first frame. Plus, it integrates cleanly with existing, traditional UIs.
That said, this approach could definitely be improved. Ideally we’d have shader-like features in the SVG Filter spec (there was a proposal, but it seems abandoned). There are some matrix operations available in SVG Filters, but they’re limited—and for my first blog post I wanted to focus more on pedagogy, art, and technique than heavy optimization.
Comments
I considered WebGL, and I agree—a shader is more performant for real-time effects.
But WebGL comes with drawbacks:
- You need JS code running before anything shows up.
- Shaders can’t directly manipulate the DOM render. To make refraction work, you’d have to re-render everything into a canvas—which isn’t really “the web” anymore.
With the SVG/CSS approach, you can pre-render the displacement map (at build time or on the backend) and get the refraction visible on the very first frame. Plus, it integrates cleanly with existing, traditional UIs.
That said, this approach could definitely be improved. Ideally we’d have shader-like features in the SVG Filter spec (there was a proposal, but it seems abandoned). There are some matrix operations available in SVG Filters, but they’re limited—and for my first blog post I wanted to focus more on pedagogy, art, and technique than heavy optimization.
I'm on mobile and your site works much better than the WebGL one.