royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlosrov...@apache.org>
Subject Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles
Date Sat, 14 Apr 2018 02:18:58 GMT
Hi,

I think the discussion now should center in numbers.

I added "performance.now()" to typedefs (how could we live without this
until now? :))

I added this code to Jewel Button:

public var start;

        public var end;

        override public function addedToParent():void

        {

            COMPILE::JS

            {

                start = performance.now();

            }

            super.addedToParent();


            COMPILE::JS

            {

                end = performance.now();

                var time = end - start;

                trace('Button Execution time: ' + time);

            }

        }


Here's execution on current develop:

Button Execution time: 0.20000000949949026

Language.js:237 Button Execution time: 0

2Language.js:237 Button Execution time: 0.10000000474974513

Language.js:237 Button Execution time: 0.20000000949949026

4Language.js:237 Button Execution time: 0.10000000474974513

Language.js:237 Button Execution time: 0.09999997564591467

Language.js:237 Button Execution time: 0.20000000949949026

Language.js:237 Button Execution time: 0.10000000474974513

Language.js:237 Button Execution time: 0

Language.js:237 Button Execution time: 0

2Language.js:237 Button Execution time: 0.10000000474974513


Here's the execution on "feature/uibase-classname"


Button Execution time: 0.1999999803956598

3Language.js:237 Button Execution time: 0.10000000474974513

Language.js:237 Button Execution time: 0.20000000949949026

2Language.js:237 Button Execution time: 0.10000000474974513

Language.js:237 Button Execution time: 0.1999999803956598

Language.js:237 Button Execution time: 0.20000000949949026

Language.js:237 Button Execution time: 0.10000000474974513

Language.js:237 Button Execution time: 0

2Language.js:237 Button Execution time: 0.10000000474974513

Language.js:237 Button Execution time: 0

Language.js:237 Button Execution time: 0.10000000474974513

Language.js:237 Button Execution time: 0


I think numbers are near identical right?


So given very close numbers should make us choose the more simplest code


right?


Carlos





2018-04-14 2:58 GMT+02:00 Carlos Rovira <carlosrovira@apache.org>:

> Hi Alex,
>
> just studied you changes and want to ask you a few things:
>
> 1) Why className and classLists methods must remain unsynced? I think this
> is not necessary and seems to me a bit unnatural since when I add styles
> though classList in a element this makes the internal list changed, and if
> I then do "trace(element.className)" it will report the updated list...so I
> think both are synced by default
>
> 2) Now Button has two new methods that must make various operations with
> arrays (join, push, splice...), this means in almost all jewel components
> override at least computeFinalClassNames and insert new custom methods for
> add/toggle/remove and each one will make various operations: in the case of
> toggle will do a push or splice and then the normal classList toggle
> operation.
>
> 3) we are introducing a new array property per component to store what
> classList already do
>
> So for me we are introducing lots of complexity, with more code splitter
> in every class, each one with more operations of array operations that
> finaly makes the same call I did. And generating complexity since className
> should be used by users only at init time and then use the rest of
> classList apis...
>
> The only difference for me is that you want to avoid the classList initial
> add method that in most of the cases will add from 1 or 2 classes and up to
> 3-4-5. I think normal components would have 3 on average...
>
> This related to lots of sites saying "use classList instead of className"
> and frameworks like MDL that are based only on classList , and all jsperfs
> (that although are not reflecting our concrete use case and use of
> classList, I think are completely valid on essence) makes me think about
> how we have such different visions.
>
> So I must to say that as much as I want to see the advantages the
> approaches do not convince me...
>
> for me is more simple that all of that.
>
> 1) I think people have the APIs (className and classList) and can/will do
> what they want, although we say "use className only at init time".
>
> 2) I think we should have the most easy way to modify since browsers are
> takin care of internal apis performance (or at least I'm confident with
> that, like I was confident on flash player performance)
>
> 3) I don't like to introduce lots of code when maybe the basic usage of
> classList can be even more efficient. I give various jsperf studies out
> there but both Harbs and you didn't show me anyone that shows className as
> a better option.
>
> 4) If we are introducing such complexity, wouldn't be better to remove
> completely classList and end that code with the new array property and
> array operations? I think it will be more performant and will remove
> complexity.
>
> 5) If I use that solution for jewel, I should introduce some intermediate
> class between UIBase and a Jewel Component where I can proxy all that
> methods that are now in button to avoid replicate in all jewel components.
> And by doing that, as I said before, I'll prefer to remove that complexity
> and go for simple classList manipulation since is the same that MDL (to
> name a concrete and successful project that renders and performs
> magnificent) does [1] (I put button example just as an example since
> there's lots more)
>
> Sincerily, I'm not convinced with the results exposed here, and I was
> always thinking that I was not seeing something evident, but now I'm even
> more convinced that we should use classList without any rejection. Even for
> the use of className in MXML, is ok since I proved you can transform it
> without problem getting the string, splitting and introducing in the
> classList, and then opertating with is when needed without any performance
> significant problem. For me is more problematic all the code we want to
> introduce to avoid possible performance problems that I and many others
> don't see and that main web projects actually don't see and are used all
> over the web. We should not be different in something that other has
> already adopted, and if people is using it, is because the browsers, the
> standards and all the web wants all people using it, and for me is what
> happen with classList.
>
> in resume. I still don't want to make this discussion longer. I think we
> have different opinions on this particular subject and the greatness of
> royale is that it doesn't mind since if you and Harbs are betting for
> className, we can remain Basic with the initial use (or the current one).
> For Jewel, I can bet for the same method MDL uses with classList and as I
> must to refactor half of the Jewel components to extend from UIBase
> directly instead of Basic components counterparts, I can put a JewelUIBase
> piece between that uses classList in the way Jewel need. In fact Jewel, and
> any of the modern UI sets (Semantic, MDL, Bootstrap, ...) depends heavily
> in class selector assignation, hence the use of classList as a general
> rule. So I think is natural to have this marked differentiation, while in
> Basic we should not expect people wants to deal with class selectors in a
> heavy use.
>
> Maybe I can wrong, but sincerely, if so I can't see where, but I firmly
> believe in that, and for me is a clear definition of Jewel needs.
>
> Thoughts?
>
> [1] https://github.com/google/material-design-lite/blob/mdl-
> 1.x/src/button/button.js
>
>
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message