It’s famo.us now: HTML5 doesn’t work

JavaScript is now powerful enough to replace CSS3

Max Dunn
5 min readDec 6, 2013
I was one of the “lucky” 400 attendees to this meetup.

It was freezing in San Francisco tonight as I headed out to the famo.us “private code release” event. So cold that I almost didn’t go, but it would have been a shame to squander my ticket to this event with a waiting list of 2,000 developers.

It was worth the discomfort: if nothing else, the event was a perfect snapshot of current SF startup culture, and it is hard to say whether the technology or the hype was more impressive, but both were out in full force.

Steve Newcomb kicked it off with the context of where we are at in this historic time, as several monumental factors define the current age:

  • JavaScript has now been ubiquitous in browsers for some time (wasn’t that a powerful moment?) and JQuery changed the world by making this power accessible. Steve seems to have been personally transformed by the power of the beautiful JQuery API.
  • HTML5 is upon us, for good and bad.
  • WebGL is about to have its JavaScript moment — does everyone realize that WebGL is in every browser by default now, with only one notable exception? How long can Apple possibly hold out? And won’t it be a transformative moment when Safari finally accepts the inevitable?
  • The fourth big thing, of course, is famo.us itself.
Steve Newcomb is at the crossroads of technology

Steve is not in love with CSS3 animation. Animators and game developers do not have time to dabble in things that don’t perform. Throughout the evening there were repeated calls, “who here has been burned by the HTML5 hype?” There were no CSS-loving hecklers in the audience, but instead the burn victims came out of the closet in greater numbers as the evening progressed.

famo.us bypasses all the hell of HTML5 performance by exploiting the amazing, ubiquitous, JavaScript engine itself, ignoring cumbersome HTML and CSS renderers. famo.us is a rendering engine built in pure JavaScript that attains a high level of performance. “60 frames per second for anything” was the basic claim, and the demos were certainly impressive.

The classic Periodic Table demo at famo.us — source code is still not publicly available.

After two and a half years of development, tonight marked the time they are really bringing the technology out there. “70,000 developers” signed up to try famo.us, though I seriously wonder how many actually got code to play with before now.

The great news is that famo.us will be free, and open source, in its entirety. All the engines, all the widgets, everything. And their goal, with the API, is to provide a JQuery-like way to make it easy to access this awesome power. The way Steve explained his joy about the fact famo.us will be free, one got the feeling that he had overcome some serious investor resistance: the plan to monetize this effort with freemium offerings tangential to the core technology probably didn’t gain approval without significant debate.

Dave Fetterman and Mark Lu

Dave Fetterman continued the rant against textbook HTML5 (the form where you use HTML and CSS) with convincing authority, as he was a major player in the Facebook HTML5 efforts, as well as their work to go native when the “proper” web app approach didn’t attain quite the desired level of performance.

What is the Achilles’ heel of HTML5 performance? Dave wanted to believe in web standards, he really did, and with the Facebook web app, they had the images… they had content, they had everything except… smooth scrolling.

“The battlefield is littered with scroll views”

Mark Lu demonstrated both the power of the famo.us API and the performance attainable to solve just such a challenge. With very little code, in a few minutes, he coded Twitter, and we were all able to experience extremely nice scrolling on our devices.

We were able to hit the sample app from our phones

Yes, it really did perform. The “physics engine” not only gave the scrolling a great feel, but provided snappy gratuitous 3D navigation effects, proving that famo.us provides performance for web apps indistinguishable from native performance, at least in this case.

I went home impressed with the technology, wondering about its true quality as well as its future, and shaking my head about the hype.

I am among the 70,000 people who signed up to try the beta, yet since few if any of us got code to look at before tonight, I consider that statistic meaningful only as a measurement of how well they have promoted this; it says zero about the technology. “Join the beta: tell us your github identity, your twitter feed” — if they fail at the API they can pivot and do recruiting. (Not that Steve Newcomb would do this, he expressed disdain for the “lean startup” philosophy).

In terms of performance, direct JavaScript can dramatically outperform CSS animation. Given Apple’s intentional neutering of browser performance, and the Chernobyl-like impact of non-upgrading Android devices (courtesy of Google’s experiments), performance is certainly not what it should or could be. Yet there remain a thousand ways to build a famo.us-like framework — as always, the devil is entirely in the details.

Heading home

Will their API be as wonderful as Steve Newcomb envisions? I hope so. I share his passion for making this sort of thing easy for normal people to work with, yet I won’t know how far along famo.us has truly progressed towards this vision until we take some time to play with the code. Certainly if the code, API, and organization work then famo.us could really take off, yet it seems they have mainly just validated the general concept of such an approach, and the coming months and years will determine both how well this concept takes off and whether their engine/API are sufficiently magical to compete with the plethora of similar engines/APIs that will arise as it gains ground. Wonderful to see code.

Oh yeah, code… I almost forgot. The few bits they have shared so far are at codepen.io/befamous.

famo.us on codepen

--

--

Max Dunn

Silicon Publishing co-founder focused on Adobe InDesign Server and online editing solutions. Author of WYSIWYG XML Authoring in the XML Handbook.