Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
al

Famo.us vs. Greensock

Recommended Posts

So, can anyone do a performance benchmark test against this newcomer?  Is famo.us everything it claims to be?  

 

Andrew

 

Link to comment
Share on other sites

Their site is so horribly broken I don't even know what it is, what it's claiming to be, or how I'm supposed to actually get or use it... maybe once this thing is released (I'm assuming, because it seems very much like it isn't right now) I might put some effort into figuring it out.

Link to comment
Share on other sites

I went to that link but did not see anything on what it is or does.. demo menu link was greyed out so i could not even demo what they were tryng to demo. And the Documentation doesn't show examples so not sure how to test performance benchmarks.

Link to comment
Share on other sites

So famo.us is a new javascript framework with a bit of a different angle in that it replaces the browser's rendering engine with its own, which is actually written in JavaScript. (resource: http://developers.slashdot.org/story/13/12/04/2047255/famous-to-open-source-rendering-engine-replacement-javascript-framework) I've been playing around with it a few days so far and looks extremely promising, but also in infancy. I will be keeping a very close eye on it progress. It's on github (https://github.com/Famous/famous) already despite the "wait line" on the site (which is mainly for docs, tutorials, etc)

 

I guess the reason the links may not be working/greyed out is due to the fact that they're in the middle of launching and are only allowing so many people in initially. (a.k.a. generate some hype :P

 

As for comparing Famous to GreenSock, IMHO I think that's impossible to do since it's a different rendering engine entirely. So maybe not quite apples to oranges, but perhaps organic vs synthetic apples. :P lol idk...

  • Like 2
Link to comment
Share on other sites

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. 

  • Like 6
Link to comment
Share on other sites

@GreenSock: You're right, you certainly cannot sprinkle bits of famo.us throughout your code like you can do with greensock (or most JS frameworks for that matter).  Its more than an animation engine -- you write your whole project in it.  It is certainly a paradigm shift, you don't really even write any markup or CSS as everything seems to be in the JS files you build.  My initial reaction left a sour taste for sure, but it will take a little time to see what patterns and techniques emerge.

 

Yes it seems to be all about the matrix and matrix 3d transforms which is why I also thought that perhaps it would be comparable for similar types of animation.

 

Looking forward to the article :)

 

Thanks for your insights,

 

Andrew

Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

I can't imagine why you wouldn't be able to do that because GSAP can animate ANY property of ANY JavaScript object. I'm not sure exactly how famo.us is triggering render updates, but worst-case is you'd just need to add an onUpdate (or a "tick" listener to the TweenLite.ticker) to tell famo.us to update/render. Sorry, I haven't played with famo.us yet, so I can't say any of this with 100% certainty, but I know that famo.us is just JavaScript objects and GSAP can easily animate those so in theory it should work beautifully. 

I'd love to hear how it goes for you. If you run into any glitches, let us know. 

Link to comment
Share on other sites

I just spent an hour playing around with it, and it looks like TweenMax can animate famo.us stuff just fine. I have no idea about performance benchmarks but I got a Surface to animate around at 60FPS in chrome (after a few seconds of 10-20FPS performance which seems typical of HTML5 stuff).

 

The main challenge is the famo.us API basically exposes no properties. 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.

  • Like 1
Link to comment
Share on other sites

  • 7 months later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Great, thanks for the info trusktr. I haven't had a chance to get my hands dirty yet with famo.us - could you answer a few questions? 

  1. You said it's easy to use famo.us to animate an existing HTML/CSS project - is that right? So let's say I have a form built and styled nicely with CSS; can I tell famo.us to just animate that whole form up and spin it into place? And perhaps have the buttons fade/slide in? Again, I'm not asking if you can BUILD something like that in famo.us - I'm saying it's already built with regular HTML/CSS and I just want to use famo.us to animate it. Can you show a simple codepen example of that?
  2. How stable do you think the API is at this point? Should people fear that they'll build something today and then in another month or two they'll release an update that'll change bunch of stuff and require a rewrite? 
  3. If someone isn't familiar with browserify, webpack, or jspm, how big is the famo.us file that they need to load in order to get that form I mentioned above animating?
  4. Where did you pick up your knowledge of famo.us? What do you recommend for others in terms of getting started? 
  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×