3 ms·

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

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?

bhouston 13y ago
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.
dmethvin 13y ago
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.

bhouston 13y ago

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.

dmethvin 13y ago

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.