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.
Top comments (0)