Just to play devil's advocate for moment, ReactJS duplicates the DOM for its own purposes and seems to do quite well. I know it has code in it to do optimization for what to redraw, making it more complex than just a duplicate tree structure.
That said, reducing our overhead is a worthy goal and if it can be done without duplication that would be great. I guess a duplicate event system that really brings nothing else to the table would not be worth it if there were alternatives. ‹peter On 8/18/16, 2:38 PM, "Alex Harui" <aha...@adobe.com> wrote: > > >On 8/18/16, 10:42 AM, "Peter Ent" <p...@adobe.com> wrote: > >>I think I'm leaning more toward agreeing with you, Harbs, about a Flex >>event bus. I remember changing MouseEvent because of some issue (have to >>look at the logs) with it being a subclass of Event. If we make it a rule >>that every FlexJS component only work with org.apache.flex.events.Event >>(or a subclass), and have a set of interactive event (mouse, touch, >>keyboard) classes (which derive from our own Event class), something deep >>down should be able to translate platform events to our events and put >>them onto our bus. It is a shame not to take advantage of the platform's >>own dispatching system, but when trying to put things together from >>different systems, sometimes you need to go outside the box. > >Duplicating the event system is definitely a possibility, but I would like >to explore other solutions first. > >Stepping back, IIRC, the reason we tried wrapping Sprite was to deal with >code-hinting in the IDEs and issues with property and method names with >low-level Flash APIs. It occurred to me that the wrapping solution might >be attacking this problem incorrectly: it is adding runtime overhead for >an author-time problem. That isn't PAYG. Further adding a duplicate >event system will only add more runtime overhead. The Google event system >we use on the JS side added 6K to every download. Not sure how big a >Flash version will be, but it will double the number of event listener >arrays and worse, the duplicates will be in ActionScript instead of C >code. And when you add overhead, you invite others to undercut you with >lower-overhead alternatives and fracture the community. > >In addition, IMO, it was a goal to try to abstract away the internal >implementations of the components. I'm concerned that we will get used to >wrapping everything. The CreateJS code and another Canvas framework that >doesn't have to wrap HTMLElements shouldn't have to wrap elements. Same >will be true for any Flash 3D/Starling/Feathers sort of thing for the SWF. > >So maybe the answer is to upgrade the tools to solve the original set of >problems. Then the runtime is as efficient as it can be for each >platform. > >The separate problem of event classes and their inheritance is, IMO a >separate problem and the solution is dependent on whether we keep wrapping >DisplayObjects in the SWF implementation. I will say, though, that it is >important to remember that we want the lowest overhead on the JS side, so >having some additional overhead on the SWF side is ok, but double the >number of objects may be too much. Further, 100% compatibility with Flex >is not a requirement. So, some old Flex coding patterns and expectation >may have to change, including whether you have to get the type of your >events correct because MouseEvent doesn't subclass Event. That might still >be better fixed with better tooling and debugging. I can imagine some >hybrid apps where the app uses more than one library which are dispatching >different kinds of events. > >I am going to go dig up the original thread and respond there with a >discussion on alternative solutions. > >My 2 cents, >-Alex >
