[deleted]
The famo.us controversy
11–20 of 32 posts
Re: The famo.us controversy
#12TL;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.
"HTML remains slow"
Approaches to updating the DOM seem to be getting a lot smarter - tools like ractive.js are smart enough to make the smallest (fastest) changes to the DOM rather than the traditional deleting and recreating large chunks of the tree.
Edit: React also has a virtual/shadow DOM for high performance updates.
Re: The famo.us controversy
#13The 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...
Re: The famo.us controversy
#14I 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?
My suspicion is that if you simplify your UI so that it doesn't have the massive amount of automatic layout code that HTML has, you can have optmized code for it. Thus even doing it in JavaScript, because it is a much smaller subset, you can have it faster.
The question is what subset do you choose to implement. And it will necessary not be correct for all cases. Thus what would happen is that this will be one of many specialized / simplified pure JavaScript DOMs.
But the above is just speculation.
Re: The famo.us controversy
#15I 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 + (Freemium of sorts in the future, for loyalty) = WIN
TBH: I thought the same, I mean the decision to lock-out so many potential developers willingly is very bad, or just ignorant. Personally I value their startup high as a replacement of , but time is not everything, sometimes you can loose a lot of customers, because of the bad first impression you have made in the beginning.
Re: The famo.us controversy
#16This 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 stuff behind us?
Re: The famo.us controversy
#17I 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?
Generally, this happens through simplifying assumptions. For example, let's say you need to often check whether an element matches a specific CSS selector. That's easy with `elem.matchesSelector(selector)` but the browser has to assume the selector could be something complex like `#content li > ul input[type="number"]` just as easily as it could be `#phone`. Plus it has to parse the selector every time (or maintain a complex cache). If you as the developer know the selector always an ID you can just check for `elem.id === "phone"` in JavaScript and that will whip the pants off the C++ code that has to deal with an arbitrary selector.
I'd like to see what assumptions famo.us has made and whether they could have just been addressed at the CSS level. An example of that would be things like overlapping elements with rounded corners and drop shadows, which are very expensive for the rendering engine. So perhaps it was a lack of understanding of CSS jank factors that led them to decide a total circumvention was in order? We'd really need to see a side-by-side of the two and understand where the conventional solution was bogging down.
Re: The famo.us controversy
#18The 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 a JavaScript bottleneck on a webview that doesn't exist when using Nitro or some other browser?
Re: The famo.us controversy
#19This 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…
> 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.
Re: The famo.us controversy
#20This 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…
It's an open question if Apps are more like documents, or more like raster (canvas), vector (SVG) or 3D (WebGL) graphics?
I could argue that in most cases the former is the right answer. Calculating DOM is (well, I'm just guessing here) no more resource intensive than calculating word wrapping and text justification in retina quality canvas.