Re: [Understanding Royale] Why MXML->JS->HTML instead of MXML->HTML

[Erik de Bruin]

> I’m 99.9% sure that browsers mark the structure as dirty when something is
> written, but none of the actual calculations and rendering happen until
> something is read or the next rendering cycle in the browser happens.
>
> I’m not sure if we’re disagreeing here.
>

We are not, just finding common ground in terms of terminology and point of
view.


> One question I have is what the performance implications are of using CSS
> vs. locally specified element styles (where the CSS does not need to be
> calculated from CSS declarations). Logically, local styling of elements
> should be more performant. I’m not sure what kinds of optimizations
> browsers have in terms of CSS lookups (and whether this is something even
> worth considering).
>

I'm pretty sure you'll be unable to measure any performance differences
between using a tag attribute (e.g. 'width') or a CSS property (e.g.
'style.width'). I would think these are simply aliases for some lower level
object field.

If you want performance optimization, I think time is better spent making
sure the most is gotten from the GCC minification and stuff like that. And,
as always, beware of premature optimization ;-)

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [Understanding Royale] Why MXML->JS->HTML instead of MXML->HTML

[Harbs]

I’m 99.9% sure that browsers mark the structure as dirty when something is 
written, but none of the actual calculations and rendering happen until 
something is read or the next rendering cycle in the browser happens.

I’m not sure if we’re disagreeing here.

One question I have is what the performance implications are of using CSS vs. 
locally specified element styles (where the CSS does not need to be calculated 
from CSS declarations). Logically, local styling of elements should be more 
performant. I’m not sure what kinds of optimizations browsers have in terms of 
CSS lookups (and whether this is something even worth considering).

> On Nov 22, 2017, at 12:22 PM, Erik de Bruin  wrote:
> 
>>> 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.
>> 
> 
> I'm not sure I agree. An addition to the DOM means that the structure
> changed and that it needs to be re-rendered. This means that in addition to
> other things, at least the 'cascading' bit of CSS needs to be re-evaluated
> before the browser can render the new state.
> 
> Again, I'm certainly not arguing against the RoyaleJS architecture! I was
> there when it was created and stand by many of the decisions we made. I am
> in this thread because Olaf's question chimed with my thinking on possible
> alternative framework architectures.
> 
> Thanks,
> 
> EdB
> 
> 
> 
> -- 
> Ix Multimedia Software
> 
> Jan Luykenstraat 27
> 3521 VB Utrecht
> 
> T. 06-51952295
> I. www.ixsoftware.nl

Re: [Understanding Royale] Why MXML->JS->HTML instead of MXML->HTML

[Erik de Bruin]

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

I'm not sure I agree. An addition to the DOM means that the structure
changed and that it needs to be re-rendered. This means that in addition to
other things, at least the 'cascading' bit of CSS needs to be re-evaluated
before the browser can render the new state.

Again, I'm certainly not arguing against the RoyaleJS architecture! I was
there when it was created and stand by many of the decisions we made. I am
in this thread because Olaf's question chimed with my thinking on possible
alternative framework architectures.

Thanks,

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [Understanding Royale] Why MXML->JS->HTML instead of MXML->HTML

[Erik de Bruin]

> > I have no idea how the browser works internally but I thought that if we
> add
> > an HTML element to the DOM by using JS the browser has to parse it
> > afterward?
>
> I might be wrong, but I don’t think so. AFAIU, if you add elements to the
> DOM via JS, it simply gets added to the DOM tree directly. It has nothing
> to do with the DOM parser. Internally, the browser does not use the HTML
> markup. It’s just a language that the browser needs to understand to create
> the tree. Using JS bypasses the parsing step.
>

OK, terminology... The HTML parsing may be 'bypassed', but not the render
steps and I think those are triggered by each JS based DOM addition. Having
most, if not all, nodes present at page complete would certainly minimize
the number of loops, shaving off some much needed nanoseconds ;-)

I really think this is not where you want to optimize, the gains are simply
way too small. Browsers are incredibly smart rendering engines. I was just
arguing a technical point, to increase my understanding.


> > Is there a need to dive into this JS code (The part of the code that
> creates
> > and manipulates the DOM) if something went wrong? Or is it easy enough to
> > follow what's going on?
>
> I find it easy to follow. The DOM structure exists in the browser once
> it’s created, so the structure can be examined there. I think you can even
> dump the HTML markup representation of that structure if you really want.


 All major browser have a 'developer tools' window that will show you the
HTML markup as rendered. Not simply the source you put in, but the DOM the
browser is actually displaying at that time. Which includes all additions
and changes made through JS. This is actually an interesting way to debug
things, and since it doesn't depend on how the DOM is create, it works for
whatever framework is used.

Thanks,

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [Understanding Royale] Why MXML->JS->HTML instead of MXML->HTML

[Erik de Bruin]

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

In general, I want to comment that the transpiler can basically output
whatever we want it to. That means that - if it turns out to make sense -
MXML -> HTML is possible for future frameworks. I'm working on the AS/MXML
-> WebAssembly transpiler, and I'm thinking about what framework
architecture could make the best use of WASM based logic. I think it's
worth considering everything, given that this is a chance to start another
framework from scratch.

Thanks,

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [Understanding Royale] Why MXML->JS->HTML instead of MXML->HTML

[Harbs]

> On Nov 22, 2017, at 11:25 AM, Olaf Krueger  wrote:
> 
>> No need for the browser to parse HTML markup. 
> Could you explain this a bit more?
> I have no idea how the browser works internally but I thought that if we add
> an HTML element to the DOM by using JS the browser has to parse it
> afterward?

I might be wrong, but I don’t think so. AFAIU, if you add elements to the DOM 
via JS, it simply gets added to the DOM tree directly. It has nothing to do 
with the DOM parser. Internally, the browser does not use the HTML markup. It’s 
just a language that the browser needs to understand to create the tree. Using 
JS bypasses the parsing step.

> I am also interested what your experience is about the readability of the
> transpiled code.
> Is there a need to dive into this JS code (The part of the code that creates
> and manipulates the DOM) if something went wrong? Or is it easy enough to
> follow what's going on?

I find it easy to follow. The DOM structure exists in the browser once it’s 
created, so the structure can be examined there. I think you can even dump the 
HTML markup representation of that structure if you really want.

Re: [Understanding Royale] Why MXML->JS->HTML instead of MXML->HTML

[Olaf Krueger]

Forgot something:
I remember that I've read sometimes here about problems to apply standard
CSS3 to MXML (HTML) elements.
Is the JS/DOM stuff one reason for this because it is maybe harder to
provide full CSS3 support?

Thanks,
Olaf



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: [Understanding Royale] Why MXML->JS->HTML instead of MXML->HTML

[Harbs]

Good question. When I started using the framework I was wondering the same 
thing.

Most JS frameworks use HTML templates mostly because the HTML is the markup 
used for the structure of the app.

Since we’re writing MXML, there’s no real reason to output HTML.

The way other frameworks deal with modifying the HTML is by complicated tree 
lookups to match up the JS state with the HTML structure. Whether or not the 
HTML comes from html files or MXML files, for us to support arbitrary HTML, we 
would need a similar system. While possible, I’m not sure it’s a direction I’d 
go.

There’s quite a few performance advantages to constructing the DOM tree via 
Javascript:

1. No need for the browser to load additional files.
2. No need for the browser to parse HTML markup.
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.

Harbs

> On Nov 21, 2017, at 11:32 PM, Olaf Krueger  wrote:
> 
> Hi,
> I noticed that the compiler builds JS from MXML and the JS finally creates
> the HTML elements dynamically at runtime.
> I just wonder what is the benefit of this and if it would also possible to
> introduce a component set that builds HTML from MXML directly.
> 
> 
> Thanks,
> Olaf
> 
> 
> 
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/