I've been going to meetups and talking with Developers about frameworks they use and often when I remark that we chose Famo.us/Angular to develop our web app at Mediahound, Inc. I often get a puzzled look. Either the engineer I'm speaking with doesn't really know about Famo.us, or all they know about is the Periodic Table example that graced the Famo.us homepage for over a year. This article will hopefully extol both the virtues and hazards of working with Famo.us so early on in their development process.

First, let me describe how we landed on the decision to incorporate Famo.us in our web app at Mediahound, Inc. After a six week analysis of different JS frameworks we finally decided to go with Angular. We liked the separation of concerns, the modular thinking that will progress in Angular 2.0, the fast two-way data binding, unit testing built right in, etc. I could go on and on about Angular, but this article is about Famo.us right?

After a week of tinkering with the newly announced Famo.us/Angular last summer, we really liked the integration of the two frameworks created by Thomas Street. A clearly defined set of Angular Directives cut down the time it took for engineers to create templates. The highly performant views provided by Famo.us' handling of CSS 3D Transforms were both exciting to work with and had incredible potential for rich, app-like interactions in a web site. This brings me to one the first point I want to make about Famo.us.

Famo.us is a way to declare your Views in a MVC. Famo.us lacks the other elements of a MVC which may leave developers questioning why it even exists. "Isn't Famo.us supposed to replace other MVCs?" is a question I'm often confronted with. The short answer is no, however it seems Famo.us is trying to become the defacto solution for handling the views in your next web app. This is probably why the company announced several integrations this past year with Angular, React, and Meteor. At times it seems like Famo.us wants to take over the entire front end, announcing a collaboration with Adobe PhoneGap that would rival jQuery Mobile and also module pattern a la jQuery UI widgets which made some bloggers question if Famo.us was trying to replace jQuery.

"But isn't it too early to adopt?" remarked another developer. Well, if IE support is a requirement well then, yes. Famo.us relies on 'transform-style: preserve-3d' which hasn't been implemented in IE11. According to Famo.us they are working closely with Microsoft engineers to fix issues in IE. The Modern.IE development portal has support for preserve-3d slated for the latest Preview Release of Windows. Hopefully Microsoft will get their act together in IE12 and Famo.us will just work, but given the haphazard history of adhering to specs handed down from the W3C, this developer isn't holding his breath. If Internet Explorer isn't a huge requirement, then Famo.us is ready to go right now! We built a Responsive web app at Mediahound, Inc. using Famo.us/Angular that launched this past October. You can check it out at https://www.mediahound.com and while you are there sign up for beta access!

The most interesting implementations of Famo.us this next year will be how Developers use it with existing libraries and frameworks. This pen I recently uploaded demonstrates a Three.js scene running on the Famo.us Engine. A Three.js camera translates through the scene using a Famo.us Transitionable and Easing. The user can distort the GLSL vector shader that textures a 3D mesh with a mouse drag or touch using a Famo.us GenericSync.

A Famo.us GenericSync allows a developer to map touch, scroll, mouse events and more to a single EventHandler. This drastically cuts the amount of time it takes to make interactive web components adapt to multiple devices. If rich Transitions and EventHandlers weren't enough to get you excited, Famo.us is working on a robust Physics Engine and Render Tree that will allow developers to mix DOM and WebGL objects in the same coordinate space. They call it 'Mixed Mode'. With all the major browsers supporting WebGL, Apple adopting WebGL in Safari for iOS8 and more Android manufacturers including WebGL in their default browsers, this approach makes a lot of sense for the web. The possibilities for games are usually the first thing to come to mind, but Game Developers looking to Famo.us may be disappointed by the relatively limiting Physics Engine still under development. Famo.us pairs with existing libaries well as the example above demonstrates, lending a library like Three.js handy Transitionables and Gesture Handlers.

3D isn't only the realm of WebGL. CSS can be manipulated in 3D space using CSS3 3D Transforms. Famo.us taps right into the highly performant CSS3 Matrix Transformations with Javascript so you don't have to do the matrix math yourself. Famo.us Surfaces can be transformed in 3D space at 60fps. The trade off for this performance is that you have to release control over the DOM tree to Famo.us. Famo.us flattens the DOM into a seemingly never ending field of div one developer I worked with called "DIV HELL". But once you wrap your head around how famo.us groups and deploys div and you class all your Surfaces, finding them in the DOM tree is rather easy. This trade off is one that some developers may have a hard time dealing with at first. After creating a few Views with hundreds of Surfaces all translating on the page at 60fps, this concern may quickly go away.

Developers spend less time writing CSS when building a Famo.us/Angular app because of how the positioning and sizing of elements is handled by Famo.us. A developer can use arrays like this one : [0.5,0.5] to center an element in a container. It may seem like all this matrix math and styling happening via Javascript is just plain bad development at first. But in practice, Famo.us/Angular has cut down the development time for components in our web app drastically. CSS3 3D Matrix Transformations greatly outperform jQuery animations or similar Javascript libraries, making them ideal for use in parallax scrolling experiences, interactive animations, large grid based layouts, the list goes on. With this level of performance, this developer is fine with handing a little control over to Famo.us.

For a personal project, I am creating set of UI Components that use Famo.us and d3. Each component is created with Famo.us, while the lines drawn between the objects and in the timeline component are made with d3. Click the small circle on the lower part of the slider and then connect it to the input of the timeline. Now drag the slider around and see the timeline draw a graph of your movement over time.

The idea with this project is to create UI components with Famo.us that follow a module pattern that others could easily extend and use in their own projects. These components will be like a supped up dat.gui! This prototype isn't quite there yet, but it will be ready for public consumption early next year. With the AMD style module pattern Famo.us is adopting, it should be relatively easy to include Famo.us in any project using libraries like Require or Common. This past fall, Famo.us released a version of the framework that is not dependent on any module pattern and instead places a global object on the window. Still, I prefer to inject Famo.us into modules using at least an anonymous define function.

In conclusion, Famo.us is a great platform to adopt for your next web app. However, here are several trade offs to using Famo.us now. You may have to quickly adapt to breaking changes in major releases of the still early in development framework, but overall the changes are documented fairly well on thier Github repo. The largest roadblock for most developers may be support for Internet Explorer, but this could change with the release of IE12 next year.

This developer sees a bright future in Famo.us, particularly when paired with a solid MVC like Angular. It is possible to create innovative web apps using the platform right now and I bet ya we will see a lot more pens using Famo.us in 2015!


4,521 1 14