Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The famo.us controversy

blog.siliconpublishing.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: The famo.us controversy

#21

Post by potatolicious »

bhouston wrote: post #19
lhnz wrote: post #16

Earlier quoted context omitted.

What I don't understand is why we don't just skip the DOM. And by that I mean, currently people are using virtual DOMs like that provided by React.js however this still has to access the DOM when it wants to render, but couldn't we rewrite a DOM/CSS renderer with WebGL (or canvas)? Or perhaps just skip that step and come up with something nicer for specific use cases. Why aren't we leaving all of this float/clear stu…

> couldn't we rewrite a DOM/CSS renderer with WebGL (or canvas)? Of course we can. :) But writing full UIs are tons of work. Why are there no OpenGL UI libraries in wide use on desktops? The same argument should apply to a degree? Or is it just that HTML5 is way less efficient that GUI+, Swing, etc.

There are "OpenGL UI libraries" :P It's called OSX.

The main reason why we haven't seen more is because OpenGL up until now has been largely in the sphere of gaming, where standardized UIs aren't a priority.

That being said, even in gaming there are a large number of libraries available that help you implement UIs.

Re: The famo.us controversy

#22

Post by Sephiroth87 »

dmethvin wrote: post #18
Sephiroth87 wrote: post #13

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

> entirely caused by the javascript engine I've profiled a lot of web pages/apps and this hasn't usually been true in my experience. Occasionally JavaScript is the culprit but that is more often to be due to really bad O(n-squared) algorithms and script that forces layout. In contrast, the rendering engine combined with complex CSS is often the cause of "janky" page behavior. Do you have some profiler runs that show…

http://blog.dave.io/2012/07/chrome-for-ios-is-crap-but-that-...

Ok, it may not be ENTIRELY the JS engine's fault, but it's definitely the biggest part of the problem...

Re: The famo.us controversy

#23

Post by jkrems »

lhnz wrote: post #16
bhouston wrote: 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…

What I don't understand is why we don't just skip the DOM. And by that I mean, currently people are using virtual DOMs like that provided by React.js however this still has to access the DOM when it wants to render, but couldn't we rewrite a DOM/CSS renderer with WebGL (or canvas)? Or perhaps just skip that step and come up with something nicer for specific use cases. Why aren't we leaving all of this float/clear stu…

I can only speak from early teen years looking at computer game UIs. It's way harder to make a UI work in "native" ways than it appears at first sight. Especially if you do very manual rendering instead of relying on float/clear stuff. There are reasons that many people are going more and more into the embed HTML-controls into native UIs direction. One example: Your own renderer will have to handle text selection, cursor movement, and mouse interaction in exactly the way the surrounding platform does. Including things like "I'd expect Ctrl+A to jump the the beginning of this textbox".

Re: The famo.us controversy

#24

Post by bhouston »

potatolicious wrote: post #21
bhouston wrote: post #19

Earlier quoted context omitted.

> couldn't we rewrite a DOM/CSS renderer with WebGL (or canvas)? Of course we can. :) But writing full UIs are tons of work. Why are there no OpenGL UI libraries in wide use on desktops? The same argument should apply to a degree? Or is it just that HTML5 is way less efficient that GUI+, Swing, etc.

There are "OpenGL UI libraries" :P It's called OSX. The main reason why we haven't seen more is because OpenGL up until now has been largely in the sphere of gaming, where standardized UIs aren't a priority. That being said, even in gaming there are a large number of libraries available that help you implement UIs.

Ah, cool. I'm not an OSX developer.

The OpenGL UI libraries I've seen on Windows are pretty horrible/limited.

Those in games are usually based on Scaleform and are also relatively limited in terms of built-in functionality, although it has wide freedom of design:

http://gameware.autodesk.com/scaleform

Re: The famo.us controversy

#26

Post by United857 »

I first saw them demo this at the October 2012 HTML5 Developer's Conference.

We attended their last two SF "meetups" in December 2013 where they promised they would release the code right then (or the day after).

Still no release, and no further mailings. This is effectively vaporware in my view, and they can't indefinitely dangle this carrot in front of developers before we get fed up.

Re: The famo.us controversy

#27

Post by United857 »

bhouston wrote: post #19
lhnz wrote: post #16

Earlier quoted context omitted.

What I don't understand is why we don't just skip the DOM. And by that I mean, currently people are using virtual DOMs like that provided by React.js however this still has to access the DOM when it wants to render, but couldn't we rewrite a DOM/CSS renderer with WebGL (or canvas)? Or perhaps just skip that step and come up with something nicer for specific use cases. Why aren't we leaving all of this float/clear stu…

> couldn't we rewrite a DOM/CSS renderer with WebGL (or canvas)? Of course we can. :) But writing full UIs are tons of work. Why are there no OpenGL UI libraries in wide use on desktops? The same argument should apply to a degree? Or is it just that HTML5 is way less efficient that GUI+, Swing, etc.

There is an experimental "render DOM content to texture" extension supported by Mozilla called drawWindow that should solve a lot of this.

https://blog.mozilla.org/tilt/

https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende...

Unfortunately it is not yet available for web content (browser extensions only).

Re: The famo.us controversy

#28

Post by karellan126 »

X4 wrote: post #15
harwoodleon wrote: post #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 pla…

Assuming you're right, then that fear is about money, if your claim stands right. But, if the fear is money, why don't they just let every developer test it early for a fee? Σ that up and you end up with a great way to fuel your startup, without causing premature investor-friction. Here's a number: $ 5 × (100.000 × ¼) = $ 125.000 in Free Capital What that means for their customers (Early Adaptors) is this: $ 5 + EULA…

Good thought but the numbers they're playing with and hence pressure/expectations are much higher.

$5.1m invested dollars in from big VCs already http://www.crunchbase.com/company/famo-us

VCs were betting on the longshot that famo.us delivers and actually works as a layer/graphics engine for non-native apps (a $100m+ play for sure). We all saw those bets and the founder certainty as a guarantee this technology would actually live up to the hype where I think we should look at this one more like the VCs did. A 1 in 20 shot and changes everything if it happens vs. expecting it to happen and factoring it in our plans.

Hate to say all this because I'm building a browser limit pushing project myself that could have used famo.us...

Re: The famo.us controversy

#29

Post by acjohnson55 »

harwoodleon wrote: post #10
bhouston wrote: 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 becaus…

True, but I think it's crucial to be able to embed these Documents efficiently in the user interface, with all the text interaction people are used to, and vice versa. Perhaps that's the future of webapps.

Re: The famo.us controversy

#30

Post by cnp »

Ugh, this resonates with me completely. Every time I see these guys I think: Ok, I can use Greensock'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'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.)
Post reply on HN