I've been wondering for some time now why should I use Angular animations over CSS animations. I see few areas one might consider before using them:
Performance
In the first step I found this question which deals only with performace side of things. The accepted answer is not satisfying for me because it states that one should use CSS animations wherever possible so that optimizations like running the animations in separate thread can apply. This doesn't seem to be true, because Angular documentation states
Angular animations are built on top of the standard Web Animations API and run natively on browsers that support it.
(emphasis mine)
And when we look at Web Animations API Draft we see that the same optimizations can apply to Web Animations as to CSS specified in sheets.
While it is possible to use ECMAScript to perform animation using requestAnimationFrame [HTML], such animations behave differently to declarative animation in terms of how they are represented in the CSS cascade and the performance optimizations that are possible such as performing the animation on a separate thread. Using the Web Animations programming interface, it is possible to create animations from script that have the same behavior and performance characteristics as declarative animations.
(emphasis mine again)
Apart from some browsers like IE don't support Web Animations, is there any reason to use either CSS declarations over Angular animations or vice versa? I see them as exchangeable performace-wise.
More control over the animations
This might look as an argument for Angular animations, because you can pause animation or use JS variables with it etc., but the same is true while using eg. CSS animation-play-state: pause or using CSS variables specified in JS, see documentation.
Now I can see it might be inconvenient to set the CSS variables in JS code, but the same is true while using Angular animations. These are typically declared in #Component animations field and don't have, except for via the animation state data bound property, access to instance fields (if you don't create your animation via AnimationBuilder of course, which btw is also not very convenient or beautiful either).
Other point is, with Web Animations API it is possible to inspect, debug or test the animations, but I don't see how this is possible with Angular animations. If it is, could you please show me how? If it isn't, I really don't see any advantage of using Angular animations over CSS ones for the sake of control either.
Cleaner code
I've read for example here a paragraph stating that separating animations from "normal" styles is actually separation of behaviour and presentation. Is really declaring animations in styles sheets mixing those responsibilities? I saw that always the other way, especially looking at CSS rules in the #Component animations gave me a feeling of having CSS declarations on one too many places.
So how is it with Angular animations?
Is it just a convenience utility to extract animations away from the rest of the styles, or does it bring anything worthy feature-wise?
Does a usage of Angular animations pay off only in special cases or is it a convention a team chooses to go all the way with it?
I would love to here about tangible advantages of using Angular animations. Thanks guys upfront!
So I did some research and although I didn't find any argument for nor against Angular animations performance-wise (as already stated in the question above), there are very good arguments to use Angular animations feature-wise which should be good enough for purists who want to have CSS only in sheets, at least in certain cases.
Let me list some useful features where each alone makes a convincing case for Angular animations. Most of them can be found in Angular animations documentation:
Transition styles - these styles are only applied during transition from one state to another - only while an element is being animated, and one uses them like this:
transition('stateA => stateB', [style({...}), animate(100)])
Trying to do the same with CSS only might not be as expressive in terms of which previous state led to the next. And it can be outright clunky if the animation has to differ based on the initial state but the end state is the same.
The void state together with :enter and :leave aliases (void documentation, :leave and :enter documentation) - Let you animate elements being added or removed from the DOM.
transition('stateA => void', animate(...))
This is very cool because previously, although it was easy enough to animate the addition, the removal was more complicated and required to trigger animation, wait till its end and only after that remove the element from the DOM, all with JS.
Automatic property calculation '*' (documentation) - Allows for performing traditionally difficult animations like height transitions for elements with dynamic height. This problem required either to set fixed height on element (inflexible), use max-height with tuned transition function (not perfect) or query element's height with JS (potentially causing unnecessary reflows). But now with Angular it is as easy as this:
trigger('collapsible', [
state('expanded', style({ height: '*' })),
state('collapsed', style({ height: '0' })),
transition('expanded <=> collapsed', animate(100))
])
And the animation is smooth and "complete" because the actual height of the element is used for the transition.
Animation callbacks (documentation) - this is something that wasn't possible with CSS animations (if not maybe emulated with setTimeout) and is handy eg. for debugging.
Unlike stated in the question, it is actually possible to use instance fields as params in Angular animations, see this question. I find it much easier to use than manipulating CSS variables through DOM API as shown here on MDN, not mentioning the limited support in some browsers.
If you need any of the features listed above, Angular can be a better tool for the task. Also when there is many animations to manage in a component, and this is just my personal opinion, I find it easier to organize animations the Angular way than have them in sheets, where it is harder too see the relationships between them and various element states.
Related
I'm currently working on a new project and only just started diving deep into CSS animations.
My question is: how do I create a timeline of animation ques? Meaning, how do I let one animation run after the other one ends, EFFICIENTLY..?
An example of what I'm trying to achieve: https://www.v2.aristidebenoist.com/
Greensock.js is the way to go in my opinion. You can script everything with fine grained detail and it has a ton of useful plugins and built in tools for common animation needs:
https://greensock.com/timelinelite
Look into CSS keyframes: https://css-tricks.com/snippets/css/keyframe-animation-syntax/ and https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animations/Using_CSS_animations
You can create a series of different keyframe sets, then trigger different ones by updating classes on root containing elements with javascript for example.
On the MDN link, look further down the page for the animation events documentation. You can hook into those to know when animations start/iterate/end.
This is being addressed in CSS Animations 2 via the animation-timeline property:
animation-timeline: auto | none | <timeline-name>
This property gives the user greater control over synchronizing / de-synchronizing CSS animations.
Currently (June 2021), this property is not supported by any browsers, but CSS implementations do move quickly some times!
While I understand that Angular 2's animate is primarily used to animate the transition between states in a fixed time, this is not always what is most convenient.
In my case, I have a slide-able element, that I wish to animate based on how far I have moved it from its default position. That is, I want to provide the handler dynamically with, for example a float number between 0 and 1 representing how far along the animation I should be. Can the angular 2 framework handle this? Can I perhaps, somehow, bypass the default animate(time) property, and directly call the underlying function that changes the css?
I'm not 100% clear on your problem, but I don't think what you're asking for is possible with Angular animations. Angular's animations are built on top of the Web Animation API, which itself is just a streamlined means of interacting with CSS Animations. CSS animations are defined with keyframes + durations (see https://css-tricks.com/almanac/properties/a/animation/).
Theoretically, you could create a complex set of keyframes that you "stepped through" based on the position of your slide-able element, but it would be a hack and not really what you're asking for.
To accomplish your goal, I think you'll need to use custom Javascript or find an outside library to help you. You're a little vague on the project details, but, as an example, a library like Tether might help you.
GSAP claims to use HTML5 to perform outstanding animations for web use, but says clearly in the their article on Greensock.com that it does not use the canvas frame work in html5. It is clear that they are using Javascript from the provided script, but it is very confusing to interpret. In what other way would they use html5 animations without the canvas? And if they do use pure HTML5 does this mean that HTML5 animations are significantly faster than CSS, jQuery, and Javascript?
There's not such thing as "html5 animations".
There are, mainly, CSS3 animations (with either CSS transition or CSS animations) and Javascript animations.
CSS3 animations are generally well optimised (with a few quirks) but lacks support (old IEs) and flexibility (you'll have to use JavaScript to tweak them.) They're best for hover effect (with transitions) or basic animations.
JavaScript transition used to be based on a setInterval. A timed loop, and inside this loop the styles are changed. JQuery does this, and not very well.
Recently, Window.requestAnimationFrame() was introduced to replace these setInterval animations. Support is limited (old IEs), performance is top notch (because the browser can skip frames), and it's always style updates inside.
What GSAP does is using this requestAnimationFrame() while optimizing for less repaints and adding a lot of useful features (reverse, timelines, stagger...) On basic animations, you can achieve the same performances with CSS3 or your own JS code... if you know what to do.
There are also others animations (canvas, svg... event webgl) but more specialized.
In my limited experience with GSAP, and during some discussion with the developer of Velocity.js, it seems that GSAP has some very convoluted code that is quite difficult to interpret; I'm not sure if this is because they're purposefully obfuscating the code or that they do some very crazy optimizations... Maybe a bit of both. They may have also taken native code and created a Javascript implementation. In any case it makes reading the source quite difficult to do.
As far as your question about HTML5 animation, which I'm taking to mean animating objects on the DOM without Javascript, if you're using a compliant browser, you can achieve many animations via the CSS transform and transition property, the former being about DOM object transformations (moving it 10px to the left) and the latter being about how the object moves as it transforms (does it move linearly over a period of time, or use a user specified cubic bezier curve to describe its motion?). With current compliant browsers, the main difference in these properties besides vendor prefixes like -webkit- and -moz- is small. What this means is that you can reliably get animations on DOM objects across those browsers if you take case of the prefixes. You can use these transform/transition properties to manipulate almost any DOM object property.
In terms of speed, it depends. CSS animation is generally the faster between it and Javascript, but it lacks control because it's hard/impossible to manipulate certain properties like key frames. Javascript animation is slower, but using a good library makes this difference negligible and in some cases Javascript animation can be faster. It really depends on what you're trying to achieve. CSS and newer Javascript library animation is considerably faster than jQuery due to some reasons listed here.
*: Of course some browsers, like IE9 and 10, while being relatively compliant, do miss some properties and have quirks about their rendering engines.
To animate an element, we can use css animations, or we can do it in javascript.
Reading up on this, it seems like css animations are expected to render more quickly than javascript animations, since the browser can execute css animations in native code. This info was gathered from posts dated from 2008 - 2011.
With ios 6, is this still the case? In the release notes, I found this item:
"WebKit no longer always creates hardware-accelerated layers
for elements with the -webkit-transform: preserve-3d option.
Authors should stop using this option as a way to get hardware
acceleration."
http://developer.apple.com/library/ios/#releasenotes/General/RN-iOSSDK-6_0/_index.html
Since I'm pretty new to animations in the web, I'm not sure what the current status is,
Thanks
CSS animations and transitions will always be faster than JavaScript ones, simply because there is just a single instruction to be handled, as opposed to having to follow all the JS instructions required for the same effect.
I'd interpret the release message as "It is no longer guaranteed that a value of preserve-3d enforces hardware acceleration" (and should not be used as a hack to assert HA). If the UA chooses not to use HA, it will have good reasons for that.
Regardless, native implemented CSS transitions are still faster than manual JS animations (in general, at least). Also, there is no cause for using JavaScript when you can achieve the same thing with short [basic] CSS.
Say you've got a menu that toggles open and closed with a button. My standard way of going about this would be to write the CSS for a closed menu, and write Javascript that specifies (or animates to) an open menu state.
Lately I've gotten into Active.js, a client-side MVC framework. It provides for view classes with builders for making DOM fragments, and those fragments can be given methods that handle things like animation and DOM state.
Something feels wonky about describing the initial state in CSS, and then describing alternate states in JavaScript. Without animation, it would be sensible to just do it all in CSS and just use javascript to add or remove DOM classes.
My other idea is to describe all of the states (folded, unfolded, red, green) of a DOM object in JSON (rather than CSS) and give my ActionView object methods for animating between those states. Is anybody doing this? Other ideas?
As far as animation goes, it wouldn't be a violation of DRY to have basic styling in CSS and then the animation or styling you can't achieve in pure CSS in javascript because you still don't have any repetition if done right. If you think its a more "pure" way to do things you can try to keep more of the styling in javascript or CSS, but those are just the languages you are using and if you consider them both expressions of the same underlying DOM its entirely appropriate to use the more expressive or compatible language wherever needed.
I typically take CSS as far as it will go and then start using jQuery to do the things that CSS can't handle or are not cross browser, like animations.