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
