[Famo.us vs. Greensock]

Oh, by the way, also check out famo.us for Angular and famo.us for Meteor. With famous-angular you can do things like

<fa-app>
  <fa-modifier fa-size="[200,200]" ngRepeat="person in people">
    <fa-surface>
      Hello {{person.name}}.
    </fa-surface>
  </fa-modifer>
</fa-app>

With meteor-famous-views you can do things like

{{#famousContext}}
  {{#famousEach people}}
    {{#Modifier size="[200,200]"}}
      {{#Surface}}
        Hello {{name}}.
      {{/Surface}}
    {{/Modifier}}
  {{/famousEach}}
{{/famousContext}}

with spacebars (Meteor's handlebars), and

+famousContext
  +famousEach people
    +Modifier size="[200,200]"
      +Surface
        Hello #{name}.

with jade for Meteor.

[Famo.us vs. Greensock]

I haven't had a chance to do any deep research into famo.us yet, but here are a few initial thoughts:

1. You can't sprinkle in famo.us into your existing HTML/CSS project - it seems to require a complete rebuild in their proprietary API. I hear the learning curve is somewhat steep, but I'm really not sure about that. 
2. They seem to hype the use of matrix() and matrix3d() to get solid performance, and that is a technique GSAP has employed for years. I don't see any reason why their particular way of doing it would perform better than GSAP, but I haven't been able to do tests yet to know for sure. 
3. They tout the ability to do physics-based interactions but the way it's implemented appears to constantly run logic (in a way that in my view is a bit wasteful). For example, I inspected the DOM for one of their physics examples and even after the element(s) came to rest, the matrix3d() was constantly jittering between tiny translation values. The way GSAP works, even a throwProps tween (which permits very physics-like interaction) finishes at some point and stops taking up resources.
4. The physics-based interactions I played with in famo.us didn't seem as natural as what ThrowPropsPlugin delivers, like in our Draggable example: http://www.greensock.com/draggable/.
5. The file size footprint is pretty massive from what I've seen thus far for famo.us.

Point #1 seems HUGE to me; the fact that you need to rebuild your entire project in their proprietary API rather than leveraging your existing HTML/CSS/JS skillset could be a major impediment for many developers. But some may love it. I don't think it's necessarily a terrible thing at all. famo.us may be awesome for some projects. I really haven't done enough research to make an educated comparison quite yet, but I do plan to write an article once I kick the tires a bit more. 

 

With GSAP, we have made a very different fundamental design choice, opting to separate the animation layer in a way that makes it EXTREMELY flexible and fast, allowing you to plugin into virtually any rendering layer (canvas, DOM, WebGL, Pixi, EaselJS, KineticJS, whatever). We think developers will appreciate not being locked into a particular proprietary API for building their entire project. Instead, they can learn one animation API that can be leveraged in anything that JavaScript can touch - no need to switch animation toolsets all the time. Is that "better"? Not necessarily. Rarely is one product a perfect fit for every scenario under the sun. From what I can tell, the famo.us guys are sharp, and they've got lots of PR expertise and an ability to spin up a lot of hype around their product. Now that it's starting to trickle out to the masses, we'll see how the marketplace responds to whatever substance there is. 

 

Again, watch for an article that I'll write once I do more tinkering. 

 

1. Yes, you can sprinkle famo.us into any normal HTML/CSS app. You just call Engine.createContext(target) where target is the Element you want to put famo.us inside of. You also need to make sure the target has overflow:hidden if you want the famo.us stuff to be clipped inside the target.
2. Performance wise, probably not comparable. Using transform:matrix3d() in any library has the same effect. The things about Famo.us is that the API is more similar to native programming instead of HTML/CSS. It's much easier to make a dynamic app with the Famo.us API than with standard HTML/CSS, and makes developers feel right at home because it's all about imperative code, not the less-powerful declarative HTML/CSS. HTML/CSS was originally built for text documents, not apps. Also take a look at something like gss.github.io, the engine used at thegrid.io, for an alternative to both Famo.us and GSAP. github.com/jsstyles/jss might also be coming out with a constraint resolver like GSS has to make traditional HTML/CSS more powerful.
3. I'm not sure which version you tried, but currently, when a Famo.us easing curve has finished, matrix3d is done being modified. This early alpha release of Famo.us definitely needs tuning, but in concept it's amazing. The new Mixed Mode coming out this year (hopefully, or "when it's ready") that mixes DOM with WebGL has solved a ton of the problems that are seen in the current release of "old" famo.us, including a re-written physics engine (same API).
4. The Famo.us physics engine works fine. Drag functionality isn't meant to be the job of the physics engine. You can easily add touch to your world. Check out some of the physics examples: 

   See the Pen eAlwd by befamous (@befamous) on CodePen

   . Here's my PushMenuLayout that uses Easing curves, not the physics engine, but the touch functionality still feels nice, and I plan to replace Easing curves with physic soon: http://trusktr.io. Give it a moment to load since it's not optimized for production (i.e. it loads lots of files then converts them from ES6 to ES5 in the browser). Swipe from the left edge of the browser on a mobile device to "push" the menu open, or hover on the left edge with your mouse on desktop (WIP). That's made with famo.us, and it shows that touch can work smoothly. I'll be adding more UI components at npmjs.org/packages/infamous and updating the README with usage and documentation soon.
5. If you use modern package handlers like browserify, webpack, or jspm, then you can compile your app code using only the classes you've required/imported. You don't have to import the entire famo.us library, unless you're choosing to use it as a global (window.famous) which I wouldn't recommend.

You don't need to rebuild your entire project in famo.us. In fact, as an example, the famo.us carousel widget (whenever it gets released) will work as a jQuery plugin. You can call $('#myDiv').famousCarousel() and it will put famo.us just in that part of your app.

 

It's easy to mix traditional HTML/CSS, GSAP, and famo.us all together if you want. No problem. You can put GSAP inside a famo.us context, or a famo.us context inside GSAP.

 

With famo.us, it's also possible to use the animation layer on traditional HTML/CSS elements, without using the famo.us renderer. Every class in the famo.us library is a standalone class, so you can use TransitionableTranform, for example, to animate any regular DOM element.

 

Agreed, one product isn't always the best fit, and it's easy to mix GSAP and famo.us together, and with other libraries.

 

 

Anyone know if you can control the famo.us objects using Greensock?

 

You can control famo.us object from anywhere. Each class is a standalone object. Just import it (ES6) or require it (node/CommonJS) wherever you want. You can easily animate Famo.us Surfaces by writing a function that takes the result from any animation library (like GSAP's) and transform that result into a Transform array that you can pass to a Famo.us object like a Surface, TransitionableTransform, etc, just like dmb85 did:

 

You can't for instance tween the x,y position of a Surface directly, you have to call a function on its Modifier, and feed this function updated transform values. So you have to make an intermediary generic object with whatever values you want to tween, let tweenmax tween those, make a new Transform out of those values, and then feed that transform into the transformFrom() function of the Modifier. I did that by calling it via an onUpdate function in the TweenMax object.

 

Overall I was left feeling like the famo.us API is pretty clunky, but that's just my uninformed opinion using it for barely an hour.