What do web animations usually look like? Fade in, fade out, a slight movement, some scaling.
There is nothing wrong with that. Most interfaces don't need anything more complicated. Sometimes, the best solution is not to add animation at all. It keeps the UI fast, clear, and focused on what actually matters.
But every once in a while, you want to make one small interaction memorable. Not a long intro or a heavyweight full-screen visual effect, but a short response to a user's action. Less than a second — and removing a card, restoring an element, or undoing an action suddenly feels completely different.
I ran into exactly this situation while implementing yet another "remove from favorites" interaction. The usual flow is familiar: the user clicks a bookmark, the card disappears, and the surrounding elements smoothly shift into place. You can animate opacity, you can add a little transform, but these patterns are so familiar that we barely notice them anymore.
I wanted something more interesting without making the interaction distracting. I had seen a similar animation when deleting messages in a messenger. Later, I learned that this kind of effect is often called the "Thanos snap."
I assumed there had to be an existing solution. There were a few similar implementations, but none of them quite matched what I needed. I wasn't looking for a hardcoded implementation of a single effect. I wanted something that could work with regular DOM elements, remain framework-agnostic, and let me adapt the animation to the interface around it.
When I created my first open-source project, I started asking myself a question whenever I solved something interesting at work: could this be useful to other developers too?
Nobody pays me to turn these things into open-source libraries, and I still can't fully explain why I spend so much time doing it. I think I simply like the idea that code I wrote might be used by people in completely different parts of the world — from someone building their first project to an experienced developer — and that someone might notice and appreciate my work.
That small work task eventually grew into another open-source library — Vanilla Disintegrate.
It animates the removal and restoration of DOM elements using particle effects. It comes with ready-to-use presets, but you don't have to tweak configuration values blindly in your code. The website includes an interactive playground where you can adjust particle movement, timing, and sound, preview the result, and copy the generated configuration.
And if the built-in particle renderer isn't enough, you can replace the rendering approach entirely.
Below, I'll explain how it works, why "remove an element, but make it look cool" turns out to involve much more than a few CSS animations, and where the real limitations of this approach are.
After the click, the card disintegrates and the original element is removed from the DOM.
There is no special markup, no mandatory CSS file, and no component tied to a particular framework.
At first glance, it may seem like the library simply draws a nice animation over an element. But if it were that simple, a few CSS properties would have been enough.
CSS is excellent for many animation tasks. Showing a modal smoothly, highlighting a button, moving items in a list, creating a hover effect — CSS is usually exactly the right tool.
But CSS animates a DOM element as a whole. It can't take an already rendered card — including its text, image, gradients, shadows, and other visual details — split it into hundreds of tiny fragments, and give every fragment its own trajectory.
Technically, you could create hundreds of tiny elements and animate them independently. But imagine what happens to performance when there are hundreds or thousands of those nodes. And even then, how do you reproduce the real text, images, shadows, and every other detail of the original element inside them?