kubeio

Thanks for highlighting that. Prettier was actually the culprit because of the non-JS `^` operator. Fixed it.

Trust me, you don't want to see the source code right now. But I'll do another article and possibly open-source a library of it.

That will be one of the goals of one of my next articles. But it cannot be implemented like Apple does (with a delay on switch between dark and light). What is possible though is to get an average of the current image behind the object and to extrapolate it to either black or white. Then the layer on top of it would do the opposite.

It is a simple React + Motion + Tailwind + Vanilla SVG here.

But it was just a first try, lots of things are still unoptimized. I'll try to do better in a next article.

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 did a quick performance fix, should be a bit better, at least on Chrome.

(Safari stills seems to be a bit slow to render SVGs)

Anyway, I did not expect this blog post to be on HN, so still things to improve on it.

I used React with vanilla SVG and Motion to animate.

Haha, I’m the author of the post.

I planned to fix the performance issues before posting here (since I knew HN would be quick to point that out), but somebody posted it first. You’re absolutely right — it’s pretty slow right now and needs optimization.

And it’s not just the refraction/displacement map: plenty of other parts, like visualisations, aren’t optimized yet either.