famo.us

The famo.us controversy

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.
How fame.us works

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.

6 Comments
  • Marco Falsitta, you are completely wrong. You just haven’t realized it yet. Famo.us isn’t designed to be used by UI and UX people, it’s designed to be used by developers/programmers, just like with Native UIs. Make your design, then hand it off to the person who will build it.

    The Famo.us render tree is *so much better* than traditional HTML5 DOM has been. If you take a class in Object Oriented Graphics and Game Programming, you’ll probably realize this. You’re first tests might be limited in this knowledge. It’s not a bad thing. It just means go learn 3D game engine programming first, then come back and be enlightened. 😉

    What you’re asking for, is something like a cassowary layout system, which famo.us makes easy to build. There already is on for Famo.us, but I’ll let you find it.

    Hint: Here’s a website made with such layout engine rendered with Famo.us: http://blitzagency.com

  • Marco Falsitta

    From a UX coder and designer perspective, Famo.us has been a big disappointment. The transformation approach to surfaces is very limiting e very unintuitive, it implies that you plans ahead how you want things to be placed. I personally believe that a responsive and interactive UI has to do with the flexibility to continually morph and modify your objects on the page. I might be wrong but from my first tests to try to use Famo.us with that intention it was just unintuitive and limiting (jQuery offers much more creative potential). Trying to use “the current” Famo.us basic building block (Surfaces, Modifiers and Transformations) is too unintuitive, unfriendly and constraining. This might be the reason why they are providing pre-made objects such Grid Layout, Header-Footer layouts and now widgets.

  • […] well, and does exactly what it says it will, but it’s not intended to be as game changing as famo.us’s creator intends his project to be. d3 could be integrated into a famo.us […]

  • Great recap. The available demos are pretty cool, and have worked better than I expected across platforms.
    Interesting that Fetterman joined the effort. That does say something.
    Talking “directly to the GPU” sounds suspicious, or at best a maintenance nightmare.
    Worthwhile if they can pull it off. I hope they are well funded.

  • Edward Irby

    I’m not really sure how I feel about famous a lot of what they’re doing especially for UI we can do now with a basic understanding of the DOM, math, and browser limitations. There are loads of micro libraries that assist with this. I think for pure backend and JS Devs (those who sometimes don’t want to learn markup and css) then sure it’s a great thing. I like knowing and understanding the the spec. I like being aware of what is performant in each environment to tweak it for each in my own way. I love frameworks like Ractive js which I think are doing a better job at taking over the UI because they enable me to do more not take over.

    Also if you really want to see their code just check out one of the examples on codepen and click the little gear in the JS panel. They link to the famous lib there https://s3-us-west-1.amazonaws.com/demo.famo.us/befamous/famous.lib.js

  • […] source: The famo.us controversy […]

Leave Your Comment

Your Comment*

Your Name*
Your Webpage