HTML and CSS Reference
In-Depth Information
JavaScript Animation vs. CSS3 Animation
After learning a bit about JavaScript and animating on the
canvas
element in the previous chapter, you're most likely
wondering what the difference is between JavaScript and CSS3 animations? Both have pros and cons, in truth; look at
your campaign's end goals and requirements to determine which method to use. However, I can provide a few tidbits
of information to start you off with. First, JavaScript is an interpreted language. JS animations rely on the JavaScript
engine of the browser to interpret, parse, and execute instructions during runtime. On the other hand, browsers can
implement CSS3 animations natively in the underlining code base of the browser (the engine). Usually written in C,
C++, or something similar, this code gets compiled to machine language, so it's always present, shipped, and installed
with a browser. This allows CSS3 to often be hardware-accelerated and offloaded to a machine's GPU for intensive
operations like animation, which makes for better-performing experiences a user can notice on a mobile browser like
iOS Safari or Android's native browser.
Between the two, many developers will argue that it comes down to some combination of ease of use,
extensibility, support, and overall performance. If you need to target older browsers, JavaScript is the clear winner.
If you care only about subjective ease of use, the modern Web, and hardware support, CSS3 is a viable solution. Also,
remember that JavaScript is blazingly fast on newer browser engines! As a developer in the advertising world, where
optimization and performance are everything, you should ultimately utilize both to your advantage while taking the
requirements of the campaign and the target audience into consideration. At the end of the day, there are many ways
to pull something off. Knowing one way of doing something doesn't mean it's always the best way at any moment
and for any scenario. Understand who your target audience is and what primary browser they're running. This could
involve some browser statistics investigation on the publisher's part to figure out what their users primary user base is.
I strongly recommend you get familiar with
http://stackoverflow.com
if you aren't using it yet. If you have
questions regarding this or other topics, chances are you won't be the first one asking.
Finally, I can't perform every test known to man to figure out which animation technique is better in your specific
scenario. I want to empower you to test on your own; in return, do a service to the developer community by recording
your tests with a really great tool:
http://jsperf.com
.
Get familiar with using this if you need to re-create bugs or test
differences between multiple ways of doing something in your script.
requestAnimationFrame, setInterval, and setTimeout?
Let's talk a bit about the code that drives animation via JavaScript. Traditionally, before
requestAnimationFrame
was
available in support of IE10, Firefox 4, Chrome 10, Safari 6, and other modern browsers, animation was achieved by
calling either
setInterval
or
setTimeout
. By calling one of these JavaScript methods in repetition, the browser would
execute the command over and over again, usually until a certain condition was met and stopped the animation. If
for some reason it never stopped, the browser would execute the script forever and eventually crash or freeze (this still
sometimes happens with poorly written scripts). However, since
requestAnimationFrame
was introduced by Mozilla
and repeated by Webkit, the objective was simple: provide a native API for controlling animations in the browser
entirely. Whether it's a DOM element, CSS,
canvas
-based, or even WebGL (there'll be more on WebGL in Chapter 12),
the browser will handle and optimize any animations into a single animation phase, leading to higher animation
quality overall. If you have animation looping in a tab that's not visible—say, your advertisement's animation and the
user isn't viewing the ad—the browser won't keep it running and hogging system resources. Publishers should love
this—it means fewer resources to allocate and much less memory usage, leading ultimately to much longer battery life,
especially for mobile devices that support the new approach. I feel Microsoft's Developer Center explains it perfectly:
The msRequestAnimationFrame method provides smooth animations and optimal power
efficiency by taking the visibility of the web application and the display's refresh rate into account to
determine how many frames per second to allocate to the animation. msRequestAnimationFrame
is a very efficient way to schedule non-declarative script animations and should be used instead of
setTimeout and setInterval.
