The famo.us controversy

This article is sort of rambly but I agree with it.<p>WebGL is the best way to talk directly to the GPU not through CSS3 transforms. Any experienced developer would be pretty insane to try to supplant a 20 year old community effort (OpenGL) for efficient GPU communication, especially one that has involved deeply all the GPU vendors.<p>NOTE: My company has bet big on WebGL and Three.JS so I am biased in this regards: <a href="http://clara.io" rel="nofollow">http:&#x2F;&#x2F;clara.io</a>

I am perplexed. I for one am running a project that would have absolutely embraced famo.us as part of the UX. There have been lots of smoke and mirrors, a few emails dotted in to ensure we didn&#x27;t think the development team had died.<p>I smell fear here, whether it is investor fear or team fear of losing IP and control when(if) they open source the project.<p>Whatever the issues they are harming the credibility of the platform. I was an evangelist to begin with - a library built in JS that can silence the compiled crowd is a sure feat.<p>Now I am more of a skeptic. If this is how long it takes to release the codebase, imagine what updates will be like. I know in the newsletter Steve has been trying to appease, but all that it sounds like now to me is a flash of arrogance over owning a toy that no one else can play with, in an &quot;i know you need this, but hang on&quot; kind of way. I know it is not meant in that way, that would be silly.<p>WebGl is maturing and if they don&#x27;t push what they have then they will lose the traction they have for sure.<p>Hopefully they will just release what they have soon and be done with it.

I first saw them demo this at the October 2012 HTML5 Developer&#x27;s Conference.<p>We attended their last two SF &quot;meetups&quot; in December 2013 where they promised they would release the code right then (or the day after).<p>Still no release, and no further mailings. This is effectively vaporware in my view, and they can&#x27;t indefinitely dangle this carrot in front of developers before we get fed up.

I wonder why they can do things faster through Javascript than the Browser makers can manage through C++.<p>Are they cutting corners because they can ignore the DOM and associated events? Or is there something else going on?

The slowness problem when making an hybrid app (at least on iOS) is entirely caused by the javascript engine, since the webview doesn&#x27;t use Safari&#x27;s Nitro, so I don&#x27;t see how rendering the page that way would make it faster...<p>Unless they are purely talking about websites, then I don&#x27;t see why would they even bring app native&#x2F;hybrid apps...

Ugh, this resonates with me completely. Every time I see these guys I think: Ok, I can use Greensock&#x27;s TweenMax and get every single bit of performance as these dudes are getting in their crazy hyped render engine. Its just totally, completely, silly IMO -- but that said, I&#x27;m also willing to be proved wrong. (It also makes me think of Mr. Doobs Periodic table that he put out after the very first demo using the Three.js CSS3 renderer that he wrote. How many lines of code was it, 10, 25? Both clocked at 60fps.)

I am not familiar with clientside JavaScript. Could anyone explain what famo.us is doing and whether it has merit? Their demo looked less impressive than WebGL ones.

DOM animation is done native, by GPU.<p>WebGL... you can&#x27;t even do fonts.<p>And DOM is more accessible by creative designers.

TL;DR the solution to HTML5 performance is to not use HTML5.<p>They use JavaScript instead and get great results, but that&#x27;s hardly fixing the problems of HTML5 like the article made it out to be. HTML remains slow, they are just putting forward the idea that JAVASCRIPT apps may be as fast as native apps.