Mobile development is a big problem. Users demand mobile apps, and they often demand that these apps have native-level performance, fit, and finish. At the same time, the apps need to be delivered "yesterday," which just doesn't happen with apps written in native code. To top it all off, users expect apps to work on, at minimum, iPhones, iPads, Android phones, and Android tablets, and they won't be completely satisfied unless a Web or desktop version&nbsp;also&nbsp;is available.

Mobile Web applications are one set of solutions to the time-to-market and profusion-of-devices problems, but they have problems of their own. Mobile Web UIs aren't usually very flexible, they often can't be made to "sizzle," and they often suffer from runtime performance issues. Even worse, mobile Web apps typically don't work when disconnected and don't retain their state after a context switch -- for instance, when a user answers a phone call.

Hybrid apps combine a native shell with a Web app, and they can sometimes be made to work disconnected. But they still suffer from performance issues. This is because the rendering of a heavily nested HTML document is inherently time-consuming and because the WebView control encapsulated by shells such as PhoneGap tends to be old and slow compared to the latest mobile browsers.

Enter Famo.usTo address some (and, Famo.us hopes, eventually all) of these issues, Famo.us developed a high-performance JavaScript framework for mobile applications that looks more like an animation or a game system than like conventional Web infrastructures. Famo.us 0.1.2, currently in a controlled beta test period, already demonstrates high performance for Android and iOS mobile Web applications. Famo.us doesn't really support desktop browsers yet, except for Chrome, and there are known bugs with Safari, Firefox, and Internet Explorer.

I found Famo.us reasonably easy to learn and use, but I'm a senior developer with a varied background, and I was learning and using it on site at the Famo.us offices, where I could bring questions and issues to the developers and architects.

Although Famo.us currently is being rolled out to 1,000 new beta testers every day, the beta is scheduled to be open to the public on May 19. The founders' vision is for there to eventually be 50 million Famo.us developers. The fact that IDC estimates that there are only about 14 million software developers in the world at present doesn't faze Steve Newcomb, the CEO. He has plans to bring designers who don't currently have coding skills into the Famo.us fold.

I'll focus on what Famo.us has to offer now and will touch on some of the company's future plans.

The Famo.us frameworkThe high-level summary is that Famo.us is a modular JavaScript framework that can generate a virtual site using surfaces and styles, modified by transforms and rotations and rendered to HTML &lt;div&gt; tags, Canvas, or WebGL. When rendered to HTML, the &lt;div&gt; tags have absolute positioning and create a flat render tree. There's none of the time-consuming flow calculations you normally see in deeply nested HTML documents with relative positioning. At the next level above surfaces, you see views, which are collections of surfaces with their own behaviors, input and output event handlers, and a certain amount of encapsulation of their interior render trees.

Animation in Famo.us can use easing curves or physical simulations. It has a full-blown, game-like physics engine with a matrix-based graphics pipeline.

The framework builds from the simple to the complex. In fact, you can use it at whatever level works for your application. If there are high-level views that do what you want, use them. If not, build your own UI from surfaces, transforms, and animations, and you can turn that into a new view.

Displaying content and style. The most basic way to display content in Famo.us is to create a context, create and style a surface, and add the surface to the context:

There are a few points of interest in this little bit of code. To begin with, Famo.us uses require statements for modularity; only the required parts of the framework are loaded. The require statement is not standard JavaScript but comes from the RequireJS framework, a JavaScript file and module loader. According to Mark Lu, CTO, Famo.us does not actually need RequireJS per se, but it does need some sort of loader. Famo.us recommends RequireJS for what it provides in terms of debuggability.

The context is the rough equivalent of an HTML body tag, but Famo.us allows multiple contexts in an app, and it can also render contexts to canvases and WebGL, as I mentioned earlier. The surface is the equivalent of an HTML &lt;div&gt; tag. The properties look like CSS, only using camel case instead of dashes. That's because the standard CSS property names with dashes are not valid JavaScript -- the dash is interpreted as a minus sign or subtraction operator. Ultimately, these styles become their equivalent CSS properties when rendered.

Figure 1: The layout lesson in Famo.us University demonstrates how to use some of the predefined views in the Famo.us framework. As in all Famo.us University lessons, the left-hand column holds instructions, the middle column is a live code editor, and the right-hand column is a live preview.

Finally, the context is first created virtually and then rendered. All the complexity of the render tree lives in the JavaScript data. The generated HTML is a flat collection of absolutely positioned &lt;div&gt; tags.

Transforms. Rather than rely on the slow HTML flow-positioning engine, Famo.us uses matrix3d WebKit transforms to put the &lt;div&gt; tags where they should go. Transforms include translation, rotation, change of scale, and composition of multiple transforms. Transforms themselves are static, but modifiers (discussed in the next section) can change the application of transforms to renderable elements over time.

If you're a game developer, this will sound awfully familiar. Famo.us basically renders elements in the same way a console game engine does. If you're primarily an HTML developer, you'll need to get used to this way of thinking to develop with Famo.us -- but it probably won't take you long, especially if you've had enough math to be comfortable with matrices.

Render Tree. A Famo.us render tree, which lives in the JavaScript code, consists of a root context, renderables, and modifiers. In addition to a plain surface, a renderable can be an image surface, an input surface, a canvas surface, a video surface, or a container surface (used for clipping nested surfaces). A modifier acts on all nodes below it in the render tree, controlling their layouts and visibility. Modifiers can be chained, which basically means that their matrices will be multiplied. Modifiers allow for changes in the size, transform, origin, and opacity of renderable elements. These are the attributes that the framework can change at its target speed of 60 frames per second.

Views. Writing every app from the ground up using basic renderable surfaces and modifiers is possible but violates the first principle of programming: Be lazy. Views are groups of renderable surfaces and modifiers that hide their internals. Views always have input and output event handlers for communication with the "outside world." There are half a dozen pre-built views in the Famo.us framework at this point, to handle common uses like scrolling elements and grid layouts. More views are under construction, and it's easy for developers to subclass views to encapsulate desired behaviors.

Animations.In Famo.us, applying a modifier over a span of time leads to an animation. The framework has two kinds of animations: easing curves (currently&nbsp;more than 30&nbsp;are&nbsp;predefined) and physics transitions. Easing curves happen over a predictable, defined duration, whereas physics transitions take as long as needed given the parameters of the simulation. Physics transitions include spring, wall, and snap. In general, I find that physics-animated transitions feel more satisfying than ordinary easing and tweening animations.

In the long term, as more designers become involved in Famo.us apps, I expect the Famo.us physics engine to become more prominent. Most designers can visualize physical systems, although they may not be able to visualize mathematically defined curves unless they've seen them.

Figure 2: The Famo.us Toolbelt is a command-line utility for installing and updating Famo.us projects. It includes a development Web server, linting capabilities, and the packaging of finished projects. Here we are updating an existing project in a Bash shell on a Mac.

Events. Famo.us has an event model with pipes, subscriptions, listeners, filters, maps, arbitration, and handlers. The View base class has both input and output event handlers predefined so that it and any derived view class can communicate with the world outside its encapsulated render tree. The event model seems to be a bit confusing, but then so is the HTML DOM event model. The basic difference between the two is that the plumbing in Famo.us events is explicit, and the plumbing for DOM events is implicit, bubbling up the tree until the event is caught. With the DOM, you take what you can get and hope it's what you wanted. With Famo.us, you're in control.

Famo.us UniversityFamo.us University (Figure 1) is a set of online courses to help you learn the Famo.us framework. The courses run in the Chrome browser, and they use a cloud installation of the Famo.us framework and an online JavaScript editor. Each Famo.us University lesson has an instruction pane, a code editor pane, and a preview pane. Changes you make in the code editor pane are reflected in the preview pane after each keystroke.

Famo.us University doesn't require much of a computer. I went through the courses using a MacBook Pro, but I could just as easily have used an inexpensive Chromebook. Newcomb hopes to parlay the light client-side requirements of this online training system into a way to bring programming education to the disadvantaged and the third world.

Famo.us ToolbeltAlthough the Famo.us University lessons run online and require very little from your client computer, you'll need a bit more horsepower for the real thing. The Famo.us Toolbelt (Figure 2) is a command-line utility that uses Git, Node.js, Grunt, Bower, and Yeoman. The Toolbelt reminds me of the command-line scaffolding generators used in some other programming environments, such as Rake or Ruby on Rails.

You don't have to use the Toolbelt, but you can save quite a bit of time if you do, especially for scaffolding. You don't have to use all its facilities, either. For example, you don't absolutely need to use its development server, and, if you do want to use the development server but don't want the strict linting that runs at the same time, you can comment out a couple lines of script.

You'll want to use a good JavaScript editor or IDE when developing Famo.us apps. The 10 JavaScript editors and IDEs I reviewed in February should include at least one that will work well for you.

Demos and samplesAt the moment, Famo.us University has about 15 demo apps posted. You can try them all online, and you can download the source if you're logged in to the site. There are far more samples and demos in the Famous and FamousPrivateBeta repositories on GitHub, although the quality of these may vary. Additional samples are under development by multiple groups including Famo.us employees, Famo.us contractors trying out to become employees, Hack Reactor students working with Famo.us, and independent beta testers contributing their own work to the repositories. Famo.us has a stated goal of being able to reproduce all the Capptivate.co animations with the Famo.us framework.

Responsive design, integrations, and other futuresFamo.us does not currently provide an easy way to create responsive mobile websites. It has taken a few steps along that road (for example, with the layouts shown in Figure 1), but it doesn't go as far as I'd want.

Figure 3: The Plugg social music-streaming app for the iPhone, currently in beta test, was built using Famo.us.

I like to see sites and apps that serve layouts and graphics&nbsp;appropriate&nbsp;to the detected devices. For example, an iPad held in landscape mode might show three columns, whereas an iPhone held in portrait mode might show one column, with the other columns available as alternate tabs or via a swipe gesture. Similarly, differently sized graphics fit differently sized devices. At the least, the app should be able to automatically apply size transforms to master graphics to match the current device resolution.

Famo.us is just beginning to integrate with MVC frameworks and other JavaScript frameworks. For example, work is underway to build TodoMVC apps by combining Famo.us with AngularJS and Backbone&nbsp;and to integrate Famo.us with Meteor. Thomas Street and Famo.us have announced an integration between AngularJS and Famo.us to be released in May. In addition, discussions are going on between Famo.us and the jQuery Foundation.

People are already wrapping Famo.us mobile Web apps in PhoneGap and Apache Cordova to make hybrid apps. Famo.us has plans to introduce its own fork of Apache Cordova, which will use the latest Chrome engine instead of the older, slower, native WebView installed on Android phones. The cloud-based builders for the resulting Famo.us hybrid apps might well require a subscription from developers, similar to what Adobe does with PhoneGap Build.

Should you be Famo.us?One of the outside groups working at Famo.us when I was there was finishing up an iPhone app called Plugg (Figure 3), which is a social music-streaming app. According to Sander Frans, CEO and founder, the developers of Plugg tried to implement the UI in HTML5 but could never get the pizzazz the designer wanted. Writing in pure native iOS code would have taken at least six months, and it would have left them needing to start over for Android. Implementing Plugg mostly in Famo.us took a couple of months, and it won't take too long to port to Android because only the native code will need to be rewritten.

The Plugg developers were working in parallel with the Famo.us developers prior to the Famo.us launch, so they had to periodically revise their app as the framework changed. That's a hardship typical of developing with an unlaunched framework, but you could argue that the time needed to develop an app like Plugg would be shorter now that Famo.us is on an actual release cycle.

Should you put in the effort to learn this new way of writing mobile apps? Unless you're a serious JavaScript developer, or you have a background in game development, learning Famo.us may not come easily. But if you're fed up with the time it takes to develop native apps, and you can't live with the speed and UI limits of mobile Web apps, then yes -- Famo.us is for you. There's a lot of hype around this new framework, and 90 percent of it is deserved.&nbsp;

Copyright 2017 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.