Hi Alex,
Migration is still an important factor, but backward compatibility isn't > being guaranteed. What that means to me is that I'm not promising that > every API in current Flex will be there in FlexJS, and we are going to try > to find the best API for the future, but if given a choice of similar > options, I would choose the old API names as that will reduce the amount > of editing of existing source in your applications. The more lines you > have to change, the more you will consider other options like a full > rewrite to some other framework. > Ok, I think the same. If you can preserve as much old API as possible the better. But if you must break at some point for further benefits this is the exception that breaks the rule. > That's interesting. Can you describe your scenario in more detail? In my > experience folks creating display object trees in AS3 were doing it less > efficiently than MXML. Top-down has been faster than bottom-up in my > measurements, mainly because being assigned a parent is the last good > place to run initialization code without an additional API call so styles > get fixed up in addChild/addToParent. IOW, > > var button = new Button(); > var container = new Container(); > container.addElement(button); > application.addElement(container); > > is not as efficient as: > > var container = new Container(); > application.addElement(container); > var button = new Button(); > container.addElement(button); > > because the Button's inheriting styles have to be recalculated at each > addElement() in the first case. > > And what I'm talking about here is that if you had code that looked like > the second case, and there are no other benefits, maybe we shouldn't make > folks re-write it like this: > > var container = new Container(); > container.addToParent(application); > var button = new Button(); > button.addToParent(container); > > Ok, I was thinking about a similar example you posted some time ago comenting how mxml was creating AS3 code and the problem with the inneficency, and the plan to change that strategy to get a better performance, but as you posted in your example, I see the problem with CSS beign check lots of times...maybe this could be a good scenario to implement invalidation of CSS (invalidateStyles() ?) to proxy all evaluations, so only happen one time for all added viasual objects to the view? About folks rewriting code...well, I certainly does not see people migrating old applications from Flex 4.x to FlexJS, Since there will be huge diferences that will make the task utopic. I expect flex developers start working in FlexJS right from the first day for new projects due to lots of similarities. But a global app rewrite...that's another story...at least for huge codebases (maye tiny apps could be reach this scenary in time, money and developer effort). -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 94 80 80 http://www.codeoscopic.com http://www.directwriter.es http://www.avant2.es
