DEV Community: Avani

CSS Animation Libraries Are a Crutch Until You've Hand-Coded One SVG Transition

Avani — Fri, 04 Sep 2026 10:36:23 +0000

Most animated interfaces you see today were built by someone who never once had to answer the question: what actually happens between frame one and frame two.

GSAP, Framer Motion, Lottie, they're all genuinely good tools. I'm not here to tell you to stop using them. I'm here to tell you that if you've never built a single interaction by hand, without them, you're missing something those tools can't teach you, and it shows up in the work.

The tell

You can usually spot an interaction built entirely inside a library's defaults. The easing feels generic. The timing is technically smooth but emotionally flat. Everything transitions the same way regardless of what the transition is actually communicating, a hover state and a page transition move with the same personality, because the personality came from the library's default config, not from a decision someone made on purpose.

I noticed this most clearly building a live SVG drink configurator, where every ingredient choice had to visually update the drink on screen in real time. I could have reached for a library immediately. Instead I built the state updates and fill transitions manually, which meant I had to actually decide, by hand, how fast a color should shift, whether it should ease in or out, and what it should feel like when two changes happened close together.

That forced a level of intentionality that picking a library preset never would have. I wasn't configuring an animation. I was designing one, frame by frame, decision by decision.

What you actually learn

Hand-coding one real SVG transition teaches you things no library documentation will:

Why easing curves change the emotional read of an interaction, not just its speed
How to keep an interaction feeling responsive even when the underlying computation isn't instant
What actually causes jank, and it's rarely what people assume it is

Once you understand that, going back to a library is a completely different experience. You're not accepting its defaults because you don't know better. You're overriding them on purpose, because now you know exactly what you want and why.

Your Full-Stack Project Doesn't Need Four Databases. Mine Did, and I'd Do It Differently Now.

Avani — Fri, 04 Sep 2026 10:26:15 +0000

During an internship, I built a full-stack ticket management system on Spring Boot, with MongoDB, MySQL, and Aerospike all running underneath it. Three data stores, one project. At the time it felt like proof I understood the ecosystem. Looking back, it was closer to proof I hadn't yet learned to say no to a database.

How it actually happened

It wasn't one bad decision. It was three reasonable-sounding ones stacked on top of each other.

MySQL handled the relational data, users, tickets, assignments, the stuff with clear structure and clear relationships. That part made sense from day one. MongoDB got added because some ticket metadata was unstructured and "just throw it in Mongo" felt like the obvious move, without anyone asking whether that unstructured data was actually going to grow into something that needed a document store, or whether it was five fields that could've lived in a MySQL table with a JSON column. Aerospike came in for caching and fast lookups on high-traffic ticket queries, which was the most defensible addition of the three, but even that got applied more broadly than the actual traffic patterns justified.

Each decision, in isolation, had a story. Together, they meant every new feature had to consider three different data models, three different failure modes, and three different places a bug could be hiding.

What it actually cost

Nobody warns you about this part clearly enough: the tax isn't paid once at setup. It's paid every single time afterward.

Every schema change is now a question of which store owns that data. Every bug report starts with "okay, which database is this even coming from." Every new person joining the project has to learn three systems before they can meaningfully contribute, instead of one. None of that shows up in a demo. All of it shows up six months in.

What I'd actually do differently

I'd start with one database and force myself to justify every additional one, not the other way around. MySQL alone probably could have handled 90% of what we needed, including the "unstructured" metadata, which in practice was more structured than anyone wanted to admit when Mongo felt like the trendier answer. Aerospike earns its place if the caching need is real and measured, not assumed.

The actual skill isn't knowing how to wire up multiple databases. Any tutorial teaches you that. The skill is knowing when a second database is solving a real problem versus when it's solving the problem of your resume looking more impressive.

I understand why it happens. A stack full of named technologies feels like proof of range. But the projects that actually hold up under real use are usually the boring ones, one well-chosen database, doing its one job, with nothing extra bolted on to look sophisticated. I know that now. I didn't when I was building it.

Stop Reaching for a Component Library Before You Understand What It's Hiding From You

Avani — Fri, 04 Sep 2026 10:25:34 +0000

I built a drink configurator for a fake coffee shop last month. Every time a user picked a different milk, size, or add-in, the drink illustration on screen actually updated, live, built entirely in SVG with vanilla JavaScript. No framework. No animation library. No component kit.

It took longer than it would have with a UI library. It also taught me more about how the DOM actually works than three years of assembling prebuilt components ever did.

The convenience trap

Component libraries exist for a good reason. Nobody should hand-roll a date picker from scratch for the fortieth time in their career. But somewhere between "don't reinvent the wheel" and "I've never actually built a wheel," a lot of developers, myself included at one point, stopped understanding what their own interfaces are doing.

Drop in a UI kit, wire up the props, ship it. It works. It looks fine. And it means you never had to think about how state changes propagate to the DOM, why a transition stutters at 200ms but not 300ms, or what happens when two animations fire on the same element at once.

That gap doesn't matter until it does. It shows up the moment something breaks in a way the library's docs don't cover, or a design spec asks for an interaction the library simply wasn't built to do.

What building it by hand actually taught me

When I built the SVG drink configurator, I had to answer questions a component library would have quietly answered for me:

How do you update individual SVG paths without re-rendering the whole element and losing the animation state?
What's the actual cost, in repaint terms, of updating fill colors on a dozen elements simultaneously versus staggering them?
How do you keep an interaction feeling instant when the underlying update logic isn't instant?

None of these are exotic problems. They're the same problems every animation library solves for you under the hood. The difference is I now know how they're solved, instead of just knowing which prop to pass.

I hit the same thing again building a multi-page site with hand-illustrated SVG art and per-page color-tinted overlays. Every page needed a slightly different visual treatment, and because I wasn't working inside a component system's assumptions, I could actually make each page distinct instead of every page looking like a reskinned template.

This isn't an anti-library take

I'm not arguing you should hand-build every button and every modal on every project. That's not craftsmanship, that's wasted time on solved problems. Use the library for a client project with a deadline. Use it for the fortieth date picker.

But if you're a junior dev, or you're trying to actually get better rather than just ship faster, build the hard, custom, hero interaction of at least one project by hand. Not because it's more impressive on a resume (though it is), but because it's the only way to find out what you don't actually understand yet.

The library was never hiding complexity from you as a favor. It was hiding it because most of the time, you don't need to see it. The problem is a lot of developers never go looking either.