> On Nov 22, 2017, at 11:55 AM, Erik de Bruin <[email protected]> wrote:
> 
> Hi,
> 
> 
>> 2. No need for the browser to parse HTML markup.
>> 
> 
> I would say that the addition of each element triggers the browser to do a
> full DOM parse and reflow of the CSS.

I don’t think this is true. Reflow only happens when attributes of the DOM is 
*read*. Writing to the DOM does not trigger a reflow.

We do have places where we should optimize our code to lump all reads into the 
same place. So I would not make a claim that Royale is necessarily currently 
faster. However, once these cases are optimized, it should be faster.

> From that perspective, it might be
> cheaper if the backbone HTML is defined when the page loads, instead of
> being built from JS after the page load is complete. Not saying that is the
> way how all the browsers do it, but simply saying that JS only might not
> necessarily be the cheapest method.
> 
> 3. JS lookup trees are very expensive. This is the biggest performance hit
>> of using other frameworks. We avoid this by keeping direct references in
>> the Royale components.
> 
> 4. We don’t need to “find” elements because we already have direct
>> references since the framework created them. We’re probably more performant
>> than even “vanilla javascript” because we generally don’t need to even ask
>> the browser to look up elements for us.
>> 
> 
> I guess you mean "repeated lookups"? I can't imagine other frameworks doing
> document.getElementById() (or whatever sugar they use) for each object
> call, that would be a way too obvious, low hanging fruit optimization. I'm
> sure we don't want to publicly make these claims unless we know for sure
> other networks are using very expensive lookups and RoyaleJS is way faster.

I’m not suggesting we should advertise anything just yet. We still have some 
optimization work to do.

Here’s a decent article on React and Virtual DOM optimization.[1] A lot of the 
problems that the virtual DOM is solving are problems we simply don’t have. We 
do need to solve the problem of batch updates better than we currently do, but 
that’s just something which we need to “get done”. With that problem solved we 
should be way ahead.

Harbs
[1]https://www.accelebrate.com/blog/the-real-benefits-of-the-virtual-dom-in-react-js/
 
<https://www.accelebrate.com/blog/the-real-benefits-of-the-virtual-dom-in-react-js/>

Reply via email to