I believe Adobe needed to support a backwards compatible product. My own preference is to take the same approach as certain software companies, and leave it to clients and companies to migrate to a faster, better, leaner platform (because we're not supporting backwards compatibility).
On Thu, Mar 1, 2012 at 6:25 PM, Om <bigosma...@gmail.com> wrote: > On Thu, Mar 1, 2012 at 3:12 PM, Omar Gonzalez <omarg.develo...@gmail.com > >wrote: > > > > > > > Maybe, I am completely off base here, but exactly what is the > motivation > > of > > > the spark component set? Is it the new skinning paradigm, or is it > > better > > > performing versions of existing components or is it a completely > > different > > > set of components that happen to have similar names? If this is a > > separate > > > conversation, please reply in a new thread. > > > > > > Thanks, > > > Om > > > > > > > Personally for me the motivation to create Spark equivalents of some of > > these components is the better skinning model. At least, in my opinion, I > > much prefer the Spark skinning over MX. This is why I haven't done any MX > > apps since Spark came out. > > > > > Right, but why are mx components shipping when equivalent spark versions > are available? This to me is the biggest sticking point. Can we nix mx > components from future releases if that is the 'old' way of doing things? > > Was the original plan (by Adobe's Flex team) to get to 100% mx <=> spark > parity before nixing mx in a future release? If yes, can someone explain > the motivations for such a decision? > > (Non-rhetorical question) Is everyone okay with different components with > completely different architectures and supporting different sets of > features with the same names shipping alongside in the same SDK? If yes, > what are the benefits? > > Or was the original plan was to support two different sets of components > that support two different skinning architectures? It does not appear so > from the code hints (Use s:XYZ instead) that appear when we attempt to use > an mx component. > > IMHO, we need to pick one plan and make sure that EVERY component we ship > with the SDK follows the same set of rules. > > Thanks, > Om >
