We Keep Coding

What is the purpose of Angular animations?

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.

CSS/JQuery/Angular transition on form submit

I ran into this beautiful UI mockup on Behance and am very curious about the best way to implement this.
https://www.behance.net/gallery/25264659/Google-transitions
Essentially, I would like my search bar and logo to animate up to the top exactly like this after the form (aka the text input) has been submitted.
My app is an Angular app, so would it be more practical to create an Angular directive? Or implement this with pure CSS or JQuery (independent from Angular)?

Your animation will be independent of AngularJS. In regards to performance of the animation JQuery is by far the absolute slowest. The standard would be to use CSS transitions / animations. If you are not comfortable with CSS then user something like velocity.js. It has a syntax similar to JQuery but used window.requestAnimationFrame making it potentially even faster then CSS.
All Angular would be used for would be used for would be to call the animation or add / remove a class to cause the CSS transition to animation when the search is underway.
As for the animation itself I unfortunately cannot help much with, those things tend to take a lot of effort to get looking good.

Zoom in/out in a container

I want to implement a system to zoom in/zoom out a container div in "real time" with javascript.The container contains different subdivs which are connected through a line using the jsPlumb library My webpage looks something like this:
Is there any 3rd party library which will help me to implement this ? Please advise me where to start. Thank you in advance.

Looking around the internet, there doesn't appear to be any libraries for what you intend to do- although I would love to be proven wrong.
Edit: While working on something completely unrelated to this, I came across a library called zoom.js that allows you zoom in on any element. It's API looks quite easy to use, but it is still a proof of concept, and doesn't work on IE. The creator said specifically to not use it in anything important, which is why I'm keeping my old answer too.
However, looking through the source code for zoomooz, I'm pretty sure that here's how you do it: Use the jQuery animate function to slowly apply the change in the css transform property. More specifically, you want to use the scale(XValue, YValue) function for this.
A couple things to remember about using CSS transform:
Set the transform-origin property, so that the page fits inside of the screen when scaled, instead of going outside the borders or something similar.
Include browser specific prefixes like -webkit-transform, -ms-transform, and -moz-transform in addition to transform.
CSS transform is an experimental feature, according to Mozilla, so make sure it is compatible with the browser your users are using.

Keeping DRY between Javascript and 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.

What's the best way to apply a drop shadow?

What is the best method for applying drop shadows? I'm working on a site right now where we have a good deal of them, however, I've been fighting to find the best method to do it. The site is pretty animation heavy so shadows need to work well with this.
I tried a jQuery shadow pulgin. The shadows looked good and were easy to use but were slow and didn't work well with any animations (required lots of redrawing, very joggy).
I also tried creating my own jQuery extension that wraps my element in a couple gray divs and then offsets them a little bit to give a shadow effect. This worked well. It's quick and responsive to the animation. However, it makes DOM manipulation/traversal cumbersome since everything is wrapped in these shadow divs.
I know there has to be a better way but this isn't exactly my forte. Thoughts?

ShadedBorder is a good looking and easy to use Shadow-Library. check it out

You don't need to wrap those shadow-divs around the other content, just set them a little askew and place them on a lower z-index !-)

if your main problem is to navigate the DOM, just add a class and/or id to your element, and refer it with JQuery selectors. even better if you store the ref in a variable, so you don't need to select it too frequently

Although it is yet to have full cross-browser support, you might like to try using the CSS 3 text-shadow property.

It largely depends on how frequently your images will need to be changing, and the colored areas that they'll be covering. Because I'm guessing that you'll be needing to pay attention to IE6 compliance, most alpha-PNG solutions will cause such horrible jittery-ness that you'll spend more time in performance optimzation than you would have wanted to guess.
To solve this in the past, since our images are modified less than once a month, we call the images through a caching-PHP script which automatically applies the shadow using a pre-defined background color so we don't have to rely on any transparency. This results in faster downloads (fewer HTTP requests) and a faster-interface because there's less Javascript/CSS magic in the works.
I understand that this is a very old-school solution, and the above solutions would be entirely acceptable if your images were static, but being cross-browser compliant and animated will likely force you to do a solution of this style.