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

[Olaf Krueger <ma...@olafkrueger.net>]

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/

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

[Alex Harui <ah...@adobe.com.INVALID>]

Components are JS, so I don't think you can create a different component
set that output more HTML.

Because they are JS, the only way I could think of having them do anything
is to run JS that creates HTMLElements.  This has the advantage that
components that are added dynamically (later) via States or AS use the
same code paths to add to the DOM as they do at startup.

Also, many components are backed by more than one HTMLElement.

Components are encapsulations of patterns.  If you can show the pattern by
which a component can result in HTML output instead of (or along with) JS
output and that handles the kind of dynamic user experiences we want our
users to build, write it up and we'll discuss it.  There may be a way that
works.

Thanks,
-Alex

On 11/21/17, 1:32 PM, "Olaf Krueger" <ma...@olafkrueger.net> 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: 
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-roy
>ale-development.20373.n8.nabble.com%2F&data=02%7C01%7C%7C6e60b2b63d8548d75
>fed08d531276987%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364689676972
>38655&sdata=g6SGAH0%2FIX4zlLaSZ1XUohI2OTkdKyt6Ewmirzz4EgA%3D&reserved=0

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

[Erik de Bruin <er...@ixsoftware.nl>]

> 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 <ha...@gmail.com>]

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 <er...@ixsoftware.nl> 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 <er...@ixsoftware.nl>]

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

[Harbs <ha...@gmail.com>]

> On Nov 22, 2017, at 11:55 AM, Erik de Bruin <er...@ixsoftware.nl> 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/>

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

[Erik de Bruin <er...@ixsoftware.nl>]

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 <ha...@gmail.com>]

CSS3 works fine. If there’s any part of it that doesn’t work, it should be considered a bug.

To use HTML CSS (as opposed to Royale CSS which needs to be parsed), the CSS namespace needs to be @namespace "http://www.w3.org/1999/xhtml”

> On Nov 22, 2017, at 11:47 AM, Olaf Krueger <ma...@olafkrueger.net> wrote:
> 
> 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

[Olaf Krueger <ma...@olafkrueger.net>]

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

[Erik de Bruin <er...@ixsoftware.nl>]

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

[Harbs <ha...@gmail.com>]

> On Nov 22, 2017, at 11:25 AM, Olaf Krueger <ma...@olafkrueger.net> 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 <ma...@olafkrueger.net>]

Thanks, Alex and Harbs for your really helpful answers!

I have to mention that I forgot to complete my origin question by "...and
makes it sense to build HTML from MXML".
Sounds to me that it doesn't make sense.

>We don’t need to “find” elements because we already have direct references
since the framework created them

This sounds to me like a core concept that is different from other
frameworks. Shouldn't we publish this on the web page?
Even more so if it is really easier and faster than others out there e.g.
Reacts "Virtual DOM".

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

Thank you!
Olaf






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

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

[Harbs <ha...@gmail.com>]

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 <ma...@olafkrueger.net> 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/