Hi Harbs, Piotr, see this link [1] and [2]
This are only CSS rules to layout content. Here you have all the use cases we could have in a Royale app. things inside things that layouts responsively using percentage widths (see width:75% in examples and how this resizes with the resize of a window, and more... Don't see nothing we must do that is not there. And is only CSS. So my point is: 1.- They are using the browser layout implementations vía CSS or in other words the native rendering engine of a browser, and that's without doubt the most performant we can go 2.- This is accomplished in the most easy and simple way to go that is through CSS code without any JS programing. So, finaly, we only need to do as easy as that. generating good simple html and css. We already did that leveraging MDL (and only encapsulating what mdl people did), now is what I do with Jewel, trying to put that knowledge and the standards things I see in encapsulated patterns to make it easy to program in Royale. So again, I continue without know what we need that is not there. Since if in that examples we have all things...we're done...we only need to encapsulate it in Royale as css and make it accesible vía Royale API, and we don't need to deal with any complex programmatic code. Maybe I'm missing something here. Thanks [1] https://www.w3schools.com/w3css/w3css_responsive.asp [2] https://www.w3schools.com/w3css/w3css_layout.asp 2018-03-27 0:42 GMT+02:00 Piotr Zarzycki <piotrzarzyck...@gmail.com>: > 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 <harbs.li...@gmail.com>: > > > 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 <harbs.li...@gmail.com> 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>* > -- Carlos Rovira http://about.me/carlosrovira
