

Introducing Famo.us-Angular - zackbrown
http://thomasstreet.com/blog//famous-angular/2014/04/28/famous-angular.html

======
mbell
Yesterday I came across famo.us and spent a good 20 minutes between between
their github page and their home page trying to figure out what it is. I still
have no idea what it actually is. My best guess so far is some sort of
frontend component framework that renders with WebGL but there was some talk
in places of it covering the backend to, so is it like meteor + a front end
library or something of the sort?

~~~
zackbrown
Yes, it's a front-end framework. One of the coolest thing about it is its
mobile rendering performance (write one JS app, deploy everywhere with awesome
performance across devices and browsers.)

Now, via Famo.us-Angular, you can tap into that performance with AngularJS,
too.

~~~
mbell
> One of the coolest thing about it is its mobile rendering performance (write
> one JS app, deploy everywhere with awesome performance across devices and
> browsers.)

Again...WTF does that even mean? So they only use CSS3 transforms that are GPU
accelerated? So it's a CSS3 animation library? The vague documentation seems
to imply a grander vision which is unclear.

~~~
zackbrown
> Again...WTF does that even mean? So they only use CSS3 transforms that are
> GPU accelerated? So it's a CSS3 animation library? The vague documentation
> seems to imply a grander vision which is unclear.

The core of Famo.us is a rendering engine. Instead of using the DOM to
represent its UI hierarchy or using the browser to render that hierarchical
DOM to screen, it uses an internal scene graph representation and handles the
rendering of the scene graph to screen through an abstracted output layer. The
browser DOM is just one of its supported outputs; another is WebGL, and
there's no reason there couldn't be other outputs, outside of the browser--I
think this extensibility is part of the 'grander vision.' The scene graph is a
very robust graphics model, so it would be a great choice for a model if
someone were to reinvent HTML from scratch today. Again, 'grander vision,'
maybe.

In the case of rendering to the browser, the way it works is by flattening and
compositing its scene graph, creating a DOM node for each 'Surface' (which is
a leaf node of the Famo.us scene graph) and handling the 3-space (or really,
2.5-space) positioning with CSS3 Matrix3D transforms, which are GPU
accelerated. Since the DOM isn't needed for hierarchy (again, all of the
calculations are handled by the engine) the Famo.us-outputted DOM is a
simplified set of sibling nodes underneath a single parent (the Famo.us
container,) and it continuously updates the Surfaces' DOM representations'
Matrix3D properties (performantly, leveraging requestAnimationFrame) as the
scene graph gets updated by the program running on the Famo.us engine.

So that's pretty much what Famo.us is. Does that help? A slightly less
technical, if more practical explanation might be about how you can "write one
JS app [and] deploy everywhere with awesome performance across devices and
browsers."

------
_zen
I know Famo.us is pitched at app building, but how about websites? Would
Famo.us-Angular be worth it for making a landing page with cool animations, or
should I just stick with the simpler animate.css because it's good enough?

~~~
dgraunke
Another Thomas Street dev here. I'm already using famous-angular on some
client projects that are just that — animation-heavy desktop sites.

It's awesome. The API for working with 3D and animations/transitions is so
much nicer than straight HTML+CSS. And I love having a render loop that's
about 100x better tuned than I could come up with in the time available.

~~~
chalettu
Hi dgraunke. I am working on some projects and really anxious to try out
famous-angular integration. Do yall have any alphas or betas of your angular
integration js available yet? I'd be more than happy to be a tester for it.

~~~
dgraunke
Hey there. Shoot me an email at david (at) thomasstreet (dot) com.

