Watch: Reviewing CSS Animation Performance

By Tim Evko

How to Hit 60fps with CSS Animation

In this video we’ll look at CSS animations, frame rates, and why some CSS properties are better to animate than others.

This is part 1 of the How to Hit 60fps with CSS Animations series. Watch out for part 2, coming soon.

Loading the player…

  • Jared

    Excellent video Tim! Looking forward to part !

  • Mike White

    Does it matter that it’s “purple” rather than a Hex value?

    • Tim

      That shouldn’t effect animation performance

      • Mike White

        K. Good to know. I’m always more of a fan of the hex than the color values. Probably because I’m a snob.

      • Mike White

        K. Good to know. I’m always more of a fan of the hex than the color values. Probably because I’m a snob.

  • Kenneth Davila

    Interesting, but shouldn’t best practice already be to use transform? Not sure what level of developer this is catered to, but at least it’s good to know that without using transform your animation is going to suffer.

    • Ross Z-Trigger Clutterbuck

      I’m sure developers who think jQuery and Sass are good things probably need to be told what best practice is.

      • Kenneth Davila

        Please enlighten the masses on how the use of jQuery and or SASS/LESS css precompiling are not good practices. I am interested to know your thoughts.

        • Ross Z-Trigger Clutterbuck

          They are pointless and unnecessary tools created to help bad developers continue to write bad code, backing them into a development corner, not understanding anything outside of the tiny world jQuery and Sass roped them in to.

          If you know how to write JavaScript and know how browsers work then jQuery is unnecessary. Compensating for browser and platform differences was never as hard as elitists and fashionistas would have you believe, and although I fully support helpers and utilities to streamline the development process, jQuery (specifically) fosters such a bloated codebase and sloppily conceived and created code you rapidly fall into the trap of not being able to “see” anything other than the jQuery way. Add to that we’re rapidly approaching a wonderful point where browsers across platforms have pretty much adopted the standards and therefore are unified in how to write for them – why do we therefore even need jQuery any more? jQuery itself no longer supports older browsers and their fractured programming interfaces, which is why jQuery exists. jQuery has made itself irrelevant.

          And Sass is just retarded. Originally so badly conceived the syntax was changed to be almost identical to CSS so “CSS developers have a familiar syntax”. So what’s the point then? You write almost-CSS to compile to real CSS but then have to check over the real CSS to ensure it’s correct and not ridiculously bloated, only then to either modify the real CSS manually and directly, or modify the almost-CSS and compile it again. And you think this is good practice?

          The only thing Sass is good for is vendor prefixing, and outside of the realms of transitions and animation there’s not that much vendor-prefixing going on any more. Every single example I’ve seen evangelising the use of Sass has been nothing more than ways to make bad CSS easier to write, and the attempts by an increasingly elitist and obnoxious industry to make web development more complex than it needs to be.

          If you’re creating definitions that require specificity greater than 2 nodes deep then you are doing it wrong. If you have a style that exists in so many places you need a variable or mixin to change them all in one hit you are doing it wrong. If you are so scared of find-and-replace, or the concept of DRY scares you so deeply you resort to bloating your code and workflow you are doing it wrong.

          CSS is not hard, it just needs a little forward planning and logic. Once you do that you don’t need Sass. CSS post-processors, on the other hand, do have some merit – you don’t need to complicate your CSS development with mixins, variables, functions and all that cruft that attempts to turn a bunch of style definitions into the next front-end programming language, but having vendor-prefixes done for you is wonderful. But do it after you’ve written the sheet.

          But I return the question to you – care to enlighten the masses how to use of jQuery and Sass ARE good practices?

Get the latest in Front-end, once a week, for free.