It's not easy to say whether it's a bad practice or not. I think more than any other platform, how your application is going to be used, and who it's going to b

It's not easy to say whether it's a bad practice or not. I think more than any other platform, how your application is going to be used, and who it's going to be used by are vital points of information that you need to answer before you approach the issue: 1) Are your visual flourishes vital to the quality of your product? 2) How concerned are you with baseline performance? 3) How big is your application? Do you need disparate components to be reusable, or do you need a philosophy or underlying framework to guide development? 4) Is your application going to be used on mobile? The answer to 1 dictates how you should approach things like animating elements. Much of the time, the animation is really just a visual flourish, and can be handled with graceful degredation through CSS. Plus you can learn a few tricks using just CSS that don't trigger unnecessary redraws that might happen using JS. The answer to 2 dictates whether or not you should adopt an existing framework or library vs. rolling your own. Libraries have gotten better about making themselves available piecemeal, but if you know how to write quick code, you'll often find almost everything is not quite what you absolutely need. See Canvas game dev. Question 3 will determine what sort of framework you'll want. Something that is extendable and object-oriented, vs. something that has more self-contained reusable components. The drawback of the former is that classing in JS brings in a considerable performance hit, whereas reusable components make for much more unmaintainable code. Question 4 will play a roll in all the aforementioned questions, namely where matters of performance and DOM redraws are concerned, as that's where mobile tends to fall flat when it comes to web apps.