Hacker News .hnnew | past | comments | ask | show | jobs | submitlogin

I disagree. Achieving smooth animation without a library is extremely difficult. If you look at what the modern libraries actually do you'll see that they have two features which are tricky to implement from scratch: frame rate limiting and easing. Frame rate limiting means that if you are running lots of complex animations at once the libraries will drop frames to ensure that all animations complete in the allocated time. Easing gives you a pleasing speed-up / slow-down effect during your animation which makes them look far more natural. This is a fair amount more complicated than simple animations set up just using setTimeout.

Of course, you can roll that stuff yourself - but why duplicate all of that effort?

Also, DOM manipulation with the regular DOM is amazingly inconvenient when compared to manipulation using a library such as jQuery. The DOM is a pretty verbose API with a lot of weird quirks (removing a node: "theNode.parentNode.removeChild(theNode)") - jQuery provides a much more sensible API, which in turn means that I find myself using DOM manipulation a lot more since it isn't such a pain to do.



Timed animation isn't that tough.

Just track the actual number of frames an animation has taken so far and the number of frames it needs to take to complete in the time taken. For bonus points re-average your framerate each time an animation ends by keeping track of the number of frames an animation actually was able to take.

And as far as easing goes...

http://www.robertpenner.com/easing/


How are they tricky to implement from scratch :/ The animation effects you talk about are pretty simple mathematics.

eg

function timerMethod() { currentFrame = (currentTime - startTime) * numFrames / animationDuration; }

And to do 'easing' as you call it, you could just use sin/cos, or a small lookup table.

The main reason to duplicate effort is to firstly learn how these things work, and secondly to get a better solution matched more optimally to your use case.

I personally like the DOM... theNode.parentNode.removeChild(theNode) makes quite a lot of sense. But it's probably a matter of taste that one.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: