Live data from Hacker News

The famo.us controversy

blog.siliconpublishing.com

1–10 of 32 posts

Re: The famo.us controversy

#2
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.

Re: The famo.us controversy

#3
This article is sort of rambly but I agree with it.

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.

NOTE: My company has bet big on WebGL and Three.JS so I am biased in this regards: http://clara.io

Re: The famo.us controversy

#4
post #2

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.

Something like direct CSS3 transforms combined with their own UI library? I think they are going to get steamrolled by WebGL personally and also by native apps, or probably more accurately they have already been steamrolled by these two technologies.

Re: The famo.us controversy

#5
I wonder why they can do things faster through Javascript than the Browser makers can manage through C++.

Are they cutting corners because they can ignore the DOM and associated events? Or is there something else going on?

Re: The famo.us controversy

#6
post #2

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.

> Could anyone explain what famo.us is doing

Mainly hyping their vaporware product, as far as I can tell. Ok, they've made a 3D-ish periodic table with questionable UX? Great, anything actually useful?

Re: The famo.us controversy

#7
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't think the development team had died.

I smell fear here, whether it is investor fear or team fear of losing IP and control when(if) they open source the project.

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.

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 "i know you need this, but hang on" kind of way. I know it is not meant in that way, that would be silly.

WebGl is maturing and if they don't push what they have then they will lose the traction they have for sure.

Hopefully they will just release what they have soon and be done with it.

Re: The famo.us controversy

#8
post #4
post #2

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.

Something like direct CSS3 transforms combined with their own UI library? I think they are going to get steamrolled by WebGL personally and also by native apps, or probably more accurately they have already been steamrolled by these two technologies.

you might be correct. It is a h4ck for sure. A really good one and one that may have found its way into standards.

Re: The famo.us controversy

#9
TL;DR the solution to HTML5 performance is to not use HTML5.

They use JavaScript instead and get great results, but that'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.

Re: The famo.us controversy

#10
post #3

This article is sort of rambly but I agree with it. 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. NOTE: My company has bet big on WebGL and Three.JS so I am biased in this regards: http…

I would argue that the DOM is broken for current requirements and their approach is actually quite sensible - circumvent it. What I would have like to have seen is a proper, UX designer led update to hardware accelerated UIML language that is not 3D and is not HTML.

This project takes a good step in that direction, in the same vein that Bootstrap and others have.

Lots of programming and design hours are wasted because the DOM is intended for Documents and not user interfaces.

Post reply on HN