famo.us is a 2.5-year-old Silicon Valley startup that claims to have solved the performance challenges of HTML5.
HTML5 Performance
“Performance challenges?” you might ask, but only if you hadn’t yet heard the tales of Facebook and LinkedIn turning an about face from HTML5 in favor of native applications. As I blogged about a year ago, HTML5 has had mixed results in the wild, driving many to adopt native or hybrid native/html5 strategies. As I discussed in describing the event where I first encountered famo.us, the classic example of poor HTML5 performance is the scrollview. Quoting Trunal Bhanse of LinkedIn:
“Mobile devices have less memory and CPU power compared to Desktop computers. If you render a very long list in the HTML, you run the risk of crashing the device. This makes it challenging to build large, interactive HTML5 apps for mobile devices. Native technologies provide UITableViewControllerto build long, infinite scrolling lists. UITableView contains reusable UITableViewCells which are optimized for memory, performance and responsiveness. For HTML5, we did not have any solution. So we set out to build one!”
The article by Bhanse is a great example of the hurdles one has to go through to create an experience with HTML5. Shouldn’t something like this be easy?
The famo.us solution
The story of famo.us is that the founder, Steve Newcomb, set out to build a modern app in HTML5, and hit the same sort of obstacles that Facebook and LinkedIn had faced with regard to performance. His talented engineer co-founder Mark Lu managed to surmount the challenge by employing tactics from gaming software. Rather than relying on traditional approaches, they bypassed the html and css renderers and went to pure JavaScript.
The famo.us founders have explained in numerous presentations how they went about creating their own rendering engine, and have showed impressive demos. Latest reports are that the famo.us library has four components: a rendering engine, a physics engine, a gesture engine for input, and an output engine. famo.us says they plan to open source the entire library under the Mozilla Public License Version 2, some time in 2014.
Controversy
While the general response to famo.us has been an enthusiastic clamor from developers to join the beta (70,000 have reportedly signed up), and there is certainly rapt attention at developer conferences and meet ups, the way they are going about promoting this technology has rubbed many in the development community the wrong way. There are several things that seem to have triggered skepticism.
Very lofty ambition
Steve Newcomb is a very passionate person. He talks with a style that echoes Steve Jobs: his goals are nothing short of changing the world. A seasoned entrepreneur, Newcomb has written essays about “Cult Creation” as a metaphor for his company- and team-building success. From his LinkedIn profile description of his work at famo.us:
“Microsoft and Apple owned the OS, Oracle owned the database, and Google owned the search engine, but no one has ever owned the UI layer. Whoever does own it for mobile devices will own something insanely valuable – every tap event that exists for each user. Imagine the company that owns the UI layer on top of Facebook, Twitter, LinkedIn and Gmail, that would enable that company to build the first unified social graph.”
Perhaps there is a bit more than saving the world on his agenda… When I saw Newcomb speak in San Francisco, he told a story of building a computer with his father, and the moment of joy when typing a “k” key on the keyboard made a letter appear on the screen. This was perhaps a perfect metaphor for his mighty framework coming together, but it was also eerily similar to a scene in the movie “Jobs.” It is sometimes hard to tell where the genuine technology passion ends and the hype begins.
Fuzzy, dramatic, words
Newcomb is a consummate salesperson, and when he describes the technology, he can make statements that are slightly inaccurate technically. One huge example is his oft-repeated claim that famo.us talks to the GPU directly. For example, from a VentureBeat interview:
“We saw Javascript could do a raw game rendering engine, but we found a way to render an app and pass that render to the GPU, skipping all the things that we were waiting on the browser companies to fix. We found a way to bypass it by having a direct mathematical conversation with the GPU.”
Technically, the conversation is not so direct (see this presentation or this explanation to see the more granular picture). The “direct to GPU” message may work with investors, but this sort of thing does not work as a sound byte with developers, but instead triggers their BS meters. In Newcomb’s defense, he has provided more detailed grounding in reality in his more in depth presentations.
A beta without any code
I am not up to date with all the latest tactics in promoting startups, but with other JavaScript frameworks, or software generally for that matter, I have never seen a beta as selective as the famo.us beta. As of now famo.us reports “70,000 beta testers” but has not yet indicated that any of these developers have received any code. I drove to San Francisco in the freezing cold for an event billed as a “code release” to find that little if any code has been released to the public. TechCrunch quotes Newcomb at the 16,000-inquiry mark:
“16,000 developers have signed up for the beta, but ‘we are not letting any of them touch anything yet.'”
What is the point of a beta? The lack of anything tangible for the development community to test certainly sets famo.us at square zero in terms of developer adoption, whether or not they have done anything meaningful for web development.
Building another standard?
So, the “traditional” approaches to standards-based developments were for documents, not apps, and we must then do something different. Newcomb has outlined a vision of a JQuery-like, accessible-to-mere-mortals, approach to such an API. That sounds absolutely great, once we get past abandoning standards 20 years in the making, but an elegant, human-usable API is a goal orthogonal to the performance work they have demonstrated. It would seem that if famo.us were serious about such a goal, they would engage some of the 70,000 signers-up with some actual code sooner than later.
And the WebGL clock ticks…
At the “code release” in San Francisco, Newcomb spoke of how beautiful it was when all browsers supported JavaScript by default, and reminded us that everyone but that holdout, Apple, has now got WebGL on by default. Will Apple ever do the right thing? It sure appears likely. Funny that Apple, once perceived to have an “underdog” status, has now assumed the stature of its old nemesis, Microsoft, as a champion of delaying and impeding standards (this is the scene in Animal Farm where Napoleon stands up). This can’t last: Apple will be forced, probably quite soon, to support WebGL. It is, after all, a simple flag to switch; the support is there under the hood. It would be supreme irony if this switch happens before famo.us releases any code. Certainly the “direct to GPU” sort of behavior can be handled in raw WebGL. A “physics engine” is a nice-to-have but WebGL alone, when functional on mobile, may offer performant scrollview and the core capabilities touted by famo.us, especially when open source libraries tested by the development community attain JQuery-like power. I sincerely hope that famo.us is as great as they imply, and that the code will be available soon. There is simply insufficient data to assess the value of this framework at this time.