null The 80,000 developers who signed up for the beta have had access to the code for weeks, and in some cases months, but the impact will soon be felt far from San Francisco’s SoMa neighborhood where Famo.us is based. Why it took more than null .
In contrast to the prevailing ethos of “ship early and ship often,” which was popularized (though not invented) by Facebook, Famo.us founders Steve Newcomb and Mark Lu committed to diligently solve many of the difficult problems in web app performance before shipping. Web app development is very fertile ground for innovation because there is so much demand for apps and because the app making process itself has so many pain points. Every new framework or platform promises to make the pain go away but generally succeeds at merely moving the pain around. Let me try to explain why Famo.us should be different.
Speaking of shipping, product development of any kind is a flow problem. You have an idea you want to introduce in a market. Imagine your idea as a potential boat and your market as a river. You have to both build the boat and get it into the water. Once in the water, your boat has to successfully navigate away from the unpredictable vortexes near the shoreline and out into the deep, middle channel of the river that will take you quickly in the direction you want to go.
Here’s the point, the arrow of time flows in one direction. Since the iPhone was introduced almost seven years ago, the app model has superseded the website model in terms of how people want to consume content and services on their screens. This, I believe, is the real reason for Apple’s success. Just as Google has benefitted from the overall growth in web traffic and Facebook has benefitted from the overall growth of social media, Apple’s fortunes have risen with our raw consumption of apps.
Three years ago, Famo.us founder Steve Newcomb clearly saw the potential for apps that would deliver content and services in new and innovative ways and he tried to figure out what were the main obstacles that app makers would have in fulfilling that promise. The obstacles that blocked the flow for developers turned out to be nested within each other such that solving one led to identifying another. In Part II of this story, I will discuss the specific barriers to developers that Newcomb and his team have engineered away with Famo.us. In this first part of the story I want to discuss the specific concepts that make Famo.us so innovative and powerful.
Building For Web 3.0
Famo.us fits into a larger technology story, the growth of the contextual web (mobile product designer Dakota Reese Smith null ) Web 3.0 is not only the “semantic web,” or the “social web,” or the “mobile web,” or the “Internet of Things.” It is all of these things, but the common denominator is of matching content to immediate need, to context. From the point of view of apps and screen-based content interfaces in general, this means designing for a lot of interaction, both explicit in terms of tapping and swiping and implicit in terms of inference from available data, and for highly dynamic changes of state.
This is also exactly the set of problems, on the front end, that Famo.us is fixing for web apps. Instagram/Facebook has recently shared its front end app platform, React and it’s matching backend Flux, that it uses to address these issues. It is interesting to see the strides that Facebook, in particular, has made in this direction considering that its epic shift away from HTML5 to native apps in 2012 was the backdrop to Newcomb’s decision to try to fix the browsers’ rendering problems in the first place.
The page was relevant to Web 1.0, the published web, which Google evaluated on the basis of “page rank.” As the web became more transactional and social (Web 2.0), Google used all of the user-generated linking between pages as a proxy for quality and relevance. With Web 2.0 came the rise of mobile, and here Apple’s influence became dominant. Mobile devices, Apple’s in particular, trained us to treat everything as an app to be tapped and swiped. They also trained us to be more aware of the temporal and spatial context within which we were accessing content. In this regard, Google Now has claimed the high ground from Apple Siri, but nonetheless consumer expectations of mobile apps were largely shaped by the early success of the iPhone and its app ecosystem.
Technology evolves towards greater flow through greater compactness. Professor Adrian Bejan, writing in Advances in Heat Transfer, points out that “The evolution toward greater density of volumetric flow, or functionality, is another way to describe the evolution of technology for greater human and machine movement on Earth.” In order to create more dynamic, contextual apps, the concept of the page must be decomposed into something smaller and more nimble. Imagine, following my boat analogy, that an ocean liner is decomposed into an intelligent swarm of kayaks.
In Bejan’s terms, Famo.us has created an “easier volumetric flow architecture” for rendering web pages. The direction of technological evolution, in thermodynamic terms, goes from natural convection to forced convection and eventually to conduction. All of the specific manipulations of DOM structure in Web 2.0 are analogous to forced convection, but there is a limit to how much flow can be created in this way. Instead of a monolithic page, which is a “large” structure relative to a web page (and in many case identical to it), Famo.us introduces smaller components that work together in a more conductive manner. Bejan writes, “These tiny flow systems are not poured into the human-scale box like beans in a sack. They must be assembled, connected, and constructed to flow together so that they bathe the available ‘whole’ completely.” For the highly dynamic apps of Web 3.0, the page needs to treated as a set of components that can be orchestrated independently. null
When you read the code for a Famo.us app you see that it is composing a “context”—a scene not a “page.” This is closer to the way games are built than apps and even farther still from traditional page-based websites. Into this context, you introduce “surfaces” which contain your content. Crucially, between the context and the surfaces are “modifiers,” which change the opacity, position, color, etc. of the elements below it in the “render tree.” By creating nested hierarchies of these elements it is possible to create very sophisticated “views” of your content that can be renedered withour performance penelty associated with the traditional DOM tree. And in a further break from most web platforms, the atomic unit of Famo.us is the function, not the template. Earlier on, Newcomb had told me that there would be WordPress-like templates and themes for Famo.us, but when designers and developers got their hands on early versions of the code, everybody wanted to “roll their own” anyway, so the emphasis shifted to lower-level components instead of pre-assembled templates.
Beyond facilitating originality, this more atomic approach is in line with the performance obsession that drives Famo.us. “If your atomic unit is the template,” Newcomb told me recently, “you can never go smaller.” What he didn’t say, but which I know from experience, is that as soon as you have templates, people will start bending them in all kinds of unintended and unforeseen directions which is one of the ways that performance gets out of control.
Famo.us has launched with over 80 basic low-level components that can be combined into widgets, a handful of which have also been released as part of the core code. Many of these components use the similar naming conventions to equivalent iOS classes (i.e., UITableViewController.) This will make it easy for iOS developers to adopt Famo.us and also underscores the extent to which Famo.us has recreated the best aspects of iOS for web technologies. Because it is free and open source, developers will be building and sharing their own widgets built on Famo.us components in what promises to be a lively community and eventually marketplace.
Coding Platforms vs. Coding Ideas
As important as Famo.us is as a new coding platform,null . Once you begin to think in terms of surfaces, the traditional page becomes just a special, static case of a more dimensional way of conceiving of displaying information. Other developers will run with this idea and either improve Famo.us or fork their own new frameworks. It is the ideas more than the code that are primary.
Meteor and especially Instagram/Facebook’s new React framework are “religiously” closer to Famo.us (not so tightly tied to HTML), so I would expect these integrations to be available soon. Each of these integrations becomes a tributary to the river, to continue the analogy. But since each framework has its own conceptual structure, care must be taken to make sure that a given combination does not degrade the dependable performance that is at the heart of Famo.us.
One of the main ways to spread new ideas among developers are hackathons, one of which Famo.us hosted last week at the HTML5 Developer’s Conference in San Francisco. Developer Matt Hayes, of Austin, won first prize for his Mystery Command app, which is a Famo.us version of the original Flash-based Tone Matrix app. This engaging, game-like interface plays a random sequence of tones that can be turned on and off by clicking squares in a grid. It is a great example of the kind of highly-interactive one-off client side app that people can build quickly with Famo.us. Other demos included a video rating app called Curve by Mat Tyndall, Theresa Light‘s animated Click Map, de Mobo‘s multi-screen display for digital signage and Roshan Jobanputra‘s City Lights game.
Look for Part II tomorrow in which I discuss in more detail how Famo.us will break down barriers for developers of these new Web 3.0 apps.
– – – – – – – – – – – – – – – – – – – –