Reading Harbs and his real world example maybe that approach with saving some values is a big winner for Royale. Instead going with the current Flow of web design let's try and see what happen.
Today I had pretty interesting chat with my friend who has deeper knowledge about JS stuff. He said that too many people is going with the Flow which has been served by bigger players like Facebook - React etc. Although it is pretty awesome framework it's just failing when you have BIG fat complex application, where performance is important, not saying about quality of code. I see we may win on all of that fields. Maybe different approach is solution, instead blindly believe in the browser and better implementation in the future. Thanks, Piotr 2018-03-27 0:22 GMT+02:00 Harbs <[email protected]>: > Case in point: > > In my app, I’m using OneFlexibleChildHorizontalLayout which uses flexbox. > Great. No need for writing values. Right? > > Not so fast. > > I have fit to view functionality in my app which needs to get the size of > the flexibleChild which is the container to figure out how much to scale > the content. The entire fit function takes 36 ms to run. The height getter > on the flexibleChild *alone* takes 14 ms. If the size of the flexibleChild > was hard-coded, the getter would not take measurable time. > > I have tons of hard coded size and positioning of SVG in my app (literally > hundreds of DOM objects) and it runs ridiculously fast compared to all the > Recalculate Styles which are caused by default browser layout. > > I’d really love to get some hard numbers from comparing the approaches. > > Harbs > > > On Mar 26, 2018, at 11:28 PM, Harbs <[email protected]> wrote: > > > > With hard-coded values DOM interaction could be kept to a minimum. It > would be an interesting experiment to see what would happen if we *don’t* > rely on browser layout and hard code everything. > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
