On 10/21/16, 3:26 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>Let’s see if I can do a better job at explaining myself. > >> Seems like that would just stomp on the current basic set. > >Yes. And I think that’s appropriate for now. > >When I say default, I mean that we should have one set of components that >we’re all working on for now. We all have limited time, and splitting our >time over two component sets is going to add significant overhead. >Migrating the port to a new component set seem like a big job and will >take time I do not have. Also, telling new users which component set to >use is going to add extra friction to adapting the framework. Carlos is working on an MDL set. We want to make sure FlexJS can handle more than one set. We don't have to all work on one set. > >AFAIK, the only performance overhead in wrapping Flash components is an >extra getter/setter call. I don’t see how there would be any extra memory >overhead. Instead of creating a new Sprite, you are creating a new Sprite and another object to wrap it. This is worrisome in the sense that, for every person who is struggling to get a certain update rate in their app, wrapping essentially means there are twice as many objects to be updated in the same amount of time, although the update time of the wrapper may not be the same as the update time of the inner widget. Twice as many objects is twice as much work for the Garbage Collector. It is more lines to step through when debugging. If we told potential FlexJS customers to wrap all of their code in another layer in order to use FlexJS I think we would have fewer customers. > >Now, back to the problem of not wrapping Sprite: > >Yes. The case I mentioned is a much bigger problem in migrated code than >new code (and in new code there’s still the issue of undocumented >reserved properties when targeting Flash), but it’s not the only issue. >It’s been a while, and I don’t remember all the nuances of the issues we >encountered. Maybe Yishay remembers more. > >We encountered numerous issues related to events. Some of the problems >were related to the fact that event bubbling is different in Flash than >it is in JS. Some of the problems were due to the fact that the events >were dispatched by the Flash objects — those issues were at least >partially due to the fact that Flex MouseEvent does not subclass the Flex >Event. I don’t see any way of fixing that other than wrapping Sprite. I >think we need to make events identical across platforms. > >There are possibly issues I’m not remembering now, and there’s possibly >other issues we did not run into. > >Again: My objection is that I believe the idea of having >platform-specific implementation details leaking through is fundamentally >wrong and should be avoided if at all possible. I guess I don't understand why it is wrong. IMO, you were the first pioneer and I'm really thankful that you took the risk to do so. In US history, the pioneers had a covered wagon pulled by an ox. There were no paved roads. Some days, they were only able to go one mile!. You found that by taking an extra mattress and sitting on it, it made the ride more bearable. However, the tool chain is slowly coming behind you paving those roads. I think I will be able to fill in every bump in the road you went over. If there is something I can't fill in, I would like to identify what that is, because that would definitely make me change my opinion. IMO, folks just aren't going to need an extra mattress. You can argue that the ox is so strong that it doesn't matter, but if you do try to drive off-road and get stuck in the mud or there are other things you would much rather pack into your wagon, you will want to leave that mattress behind. Just this week there is a thread about mobile performance. Now from my experience with Flex, I saw some things happen. Flex's job was to put a layer over Flash and essentially hide all the Flash-isms, especially frames, and make an API that was more "programmer-oriented". You were supposed to use SystemManager instead of Stage, for example. But when I peek at other people's apps, I see a lot of use of Flash APIs anyway. Why? Because they needed to get down to the lower-level for optimization. And then, folks started creating other lightweight frameworks as alternatives to Flex. I also saw the argument that my change only causes 10ms delay. I after seeing it 100 times, we had a full second delay and nobody could point to what to remove to try to get it back to something ignorable. Also note: the reason MouseEvent doesn't extend Event doesn't have anything to do with wrapping Sprite or not. And any inconsistencies between the JS and SWF event model simply need to be resolved. I think resolving it so the unwrapped set matches the JS side will lots easier than writing a whole new event model for wrapped Sprites. > >We have a conflict between ideals here. You want a the highest possible >performance under all circumstances, and I want the highest level of >compatibility across platforms under all circumstances. I think the tool chain can get you that compatibility so there is no conflict. I'm still wondering what the killer scenario is that the tool chain cannot solve. I am open to the idea that there is one. >These two ideals are at head with each other here, and we’re going to >have to decide which one is more important. I think I’ve made opinion >clear on that question. The performance issue is a theoretical one which >I don’t believe will have practical implications, while the compatibility >one is a practical one which already bit me. Trying to maintain two >complete component sets at this point I believe to be counterproductive >and I don’t believe it will resolve performance issues that might arise >anyway. If we identify use cases where performance is an issue, I would >suggest specific components designed for those use cases (and not a whole >new set). I would like to work on one Basic set too, but your set doesn't sound like it is Basic. It sounds like it is aggregating APIs into the component surface to simplify migration. And that's fine with me. I would love to have a component set tuned towards migration. I just would caution about using your experience with a new tool chain to make decisions that we will carry around for a long time. Maybe the answer is that I copy the current unwrapped Basic set to new SWCs, then you can drop the wrapped set on top. Then I will work on the tool chain to see if we can resolve all of your issues without wrapping. -Alex
