The famo.us controversy

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.

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?

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 <Enter-Mobile-Framework-Here>, 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.

Not sure if this is useful but code just check out one of the examples on codepen and click the little gear in the JS panel. They link to the famous lib there https://s3-us-west-1.amazonaws.com/demo.famo.us/befamous/fam...

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.

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.

> 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?

If you've tried to use GreenSock on a mobile device, you'd see that it stutters quite a bit depending on the number and size of elements. I've tried all the famo.us demos on basic mobile phones and for the most part they all perform well in terms of fps. That is their main advantage, I think.

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.

> 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?

"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.