Hacker News new | past | comments | ask | show | jobs | submit login
Principles for smooth web animations (gyrosco.pe)
198 points by julianshapiro on Nov 6, 2016 | hide | past | favorite | 26 comments



The most important principle for current technologies is #1, “Don’t change any properties besides opacity or transform!”

Hopefully everyone will start copying the approach Servo uses in its WebRender engine which is basically treating the browser rendering as though it were a game, using the GPU for rendering everything; therefore guidelines like this become obsolete.

This applies to a slightly lesser extent with #2, “Hide content in plain sight.” #3 is also obsolete in Servo, as is #7, mostly.


Even if everything were GPU based, this would still be a good suggestion no? The biggest reason I see to use "transform: translateX(n)" over "left: n" is the transform doesn't make a call to reflow the content around it (unless that's what you're going for). Even with GPU acceleration, transform will still be more performant than standard positioning/sizing.

I've always followed this rule: Use transform unless you need reflows, then use top/left/height/width.


The thing is, reflow is not why using left is slow. If the element is position: absolute, you don't reflow the whole page anyway.

CSS transform is used because render is slow. With Servo-like GPU acceleration, render is not slow. Your suggestion would not be a good suggestion because using transform would be an unnecessary premature optimization then.


But why should reflow make animations less smooth in the first place? Shouldn't reflow be designed such that it doesn't affect animations?


Slight nit: Opacity can still matter, in modern games they're usually kicked to a different, more expensive render pass. However that doesn't really impact UIs as things aren't rendered front to back but in layer order.

Although opacity can have some gnarly fill implications if you go crazy with it.

Overall though, yeah web stuff falls well behind more modern UI renderers like HWUI on Android and the like.


Do browsers kick position: fixed element animations over to the GPU? If not, does that mean it's worth putting them at 0,0 and using transform for their real coordinates?


It is rather disappointing that with the current state of technology we need to go through such hoops to get smooth animations.

Also, there is completely no handle on keeping the animations smooth as webpages become more complicated and do (perhaps unrelated) updates while animations are running.


#11: Your user's browser has the final say in all matters of timing. Whatever you do, ultimately, if the browser decides that something has to be computed on your main JS thread while you are trying to hit frames and timings, you're screwed. Source: Making multiple HTML5 games with the intention of having them render at 60 fps and not missing a single frame.


The reason why transform & opacity (via CSS animations) are always recommended is because they can be done completely on the compositor thread without going back to the main thread.

If you need to run every frame of animation from JS then, yes, you're screwed. At least until https://groups.google.com/a/chromium.org/d/topic/blink-dev/Y... & https://github.com/flackr/compositor-worker)


Thanks for the explanation. Yeah, I noticed that the hard way. I now moved off JavaScript and went back to classic C++ game programming. I like it much more at this lower level with fine-grained control.


OK, so now I know why tweening's called that, and I feel like the biggest idiot in the world :-/


There are so many of these, even in basic English. Like "discover" = un-cover.


As an even more surprising example of this, "alright" isn't even a real word.

Tweening actually goes back to traditional animation where the keyframes (another borrowed term) were hand-drawn by senior artists and the frames in between were added by junior artists. This process was called inbetweening, or tweening for short.


"another" = "an other"


no-body, no-where, interrupt-able, etc


"no one" is two words.

Edit: corrected. But I can't delete? Oh, I have replies :)


Thanks, replaced it with a better example.


Google's Material motion guidelines are also great material for people looking to use web animations.

https://material.google.com/motion/material-motion.html#mate...


this is literally in the article


Wow i just went and logged in to https://gyrosco.pe/... Too many animations. Its making me wait for content to show up, lots of animations everywhere causing a lot of congnitive load. And an options to delete your account is not there.

I think animations are very much over used on that site. The article is fine. But dont do too much animations! Keep congnitive load small!


The article was awesome. I am not sure, however, the heavy animation helps gyroscope.pe's user experience, though.


Off topic... but what are you using for JS animations these days?

I've been using GSAP for almost a decade since the Flash days.


Speaking of smooth animations, the blog post is hosted on Medium, and I've always admired Medium's image zoom thing because it's so smooth!


The smoothest animation is the one you don't do.

In the best case, web animations just cause bloat and burn through your battery. In the (common) worst case, they stutter or break or cause things to on the page to hang while they load.

Just don't do it. Your website doesn't need to look like a mobile app.


This is just patently false. Animations can give a sense of continuity and context for the effect of your actions. For example, let's say that you have an alphabetized list of people, and you want to add a person to the list by putting their name into an input box above the list. If when you submitted the name it just disappeared and appeared somewhere down the list, you would likely not know what happened. If, however, there was a transition where you saw the list adapting to the new data, you would be able to understand that you added an item to it.

Sure, there are good and bad instances of animation, but to state that at best it's a battery drain is just patently false.


Very very nice article




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

Search: