Digital Forbes Part I: New Concepts Will Increase The Flow Of Highly Dynamic Web 3.0 Apps


Anthony Wing Kosner, Contributor

May 28, 2014

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 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, 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 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, 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 In this first part of the story I want to discuss the specific concepts that make so innovative and powerful.

Building For Web 3.0 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 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.

Rendering pages in the browser has been the bottleneck for highly reactive web apps. It is one of those vortexes at the edge of the river. Most websites that are built with front end JavaScript technology call themselves “single-page apps,” but really, these are not “pages” in any familiar sense. Indeed, director of engineering Dave Fetterman (formerly HTML5 team lead at Facebook) tells me, “ has no concept of pages.” What this means in practical terms is a radical break with the past—a new configuration. In a world where we are surrounded by screens, large (and getting larger) and small (and getting smaller), the notion of the page is archaic.

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, 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), 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 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 is the function, not the template. Earlier on, Newcomb had told me that there would be WordPress-like templates and themes for, 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 “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.

Newcomb is now forthright in saying that there are still some things that native apps will do better than  JavaScript is single-threaded so it can’t compete on absolute performance on functions that benefit from multi-threading as well as native, like scrolling views of hundreds of images, for instance. But he goes on to point out that trends in app development are moving away from things like endless scrolling lists that have given web apps trouble and towards more imaginative forms like Facebook’s Paper. Without going into all of the details, Newcomb brags that “ can do 90% of what iOS can do, but iOS can only do 50% of what can do.” 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 and also underscores the extent to which 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 components in what promises to be a lively community and eventually marketplace.

Coding Platforms vs. Coding Ideas

As important as 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 or fork their own new frameworks. It is the ideas more than the code that are primary.

This interplay of ideas is especially evident in the profusion of integrations with other popular JavaScript frameworks, including Angular, Meteor, Ember, Backbone and React. What has done is to position itself at the last possible point in the process before the browser’s rendering engine kicks in and divert the flow through its own rendering engine. Effectively this makes fairly agnostic about what back end a developer is using as long as it has a workable API that can supply data to the front end. is front end, and can communicate directly with back ends, but it can also provide rendering support for other front end frameworks. But because is highly modular, developers can choose which components to use with other frameworks. In either case, it is up to the developer to understand the ways in which the platforms they are integrating are conceptually similar and different and make their own Venn diagram for a solution. This is abundantly clear in the first of the integrations to go live,

The Angular integration was indeed a surprising development, because certain aspects of Angular’s attachment to the HTML DOM structure did not immediately seem compatible with the philosophy. The team tried two different approaches, but Newcomb was not satisfied with either and shut the project down. But designer Zack Brown from the San Francisco design studio Thomas Street, who was participating in the private beta test, raised his hand and proposed a third way. Brown figured a way to finesse the differences between the two platforms that had eluded the engineers in their first attempts. The result is a set of code elements (called directives in Angular) that can be added to any Angular app so that in the “last mile” it will be rendered performantly by This will allow Angular’s community of 800,000 developers (one of the largest in the JavaScript world) to incorporate into their familiar workflow, but it is also bound to make them think differently about Angular itself.

Meteor and especially Instagram/Facebook’s new React framework are “religiously” closer to (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

One of the main ways to spread new ideas among developers are hackathons, one of which 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 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 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 will break down barriers for developers of these new Web 3.0 apps.

– – – – – – – – – – – – – – – – – – – –

To keep up with Quantum of Content, please subscribe to my updates on Facebook, follow me on Twitter  or add me on Google+.

Great ! Thanks for your subscription !

You will soon receive the first Content Loop Newsletter