flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Constantinides <constantinnovations...@gmail.com>
Subject Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Date Mon, 05 Mar 2012 04:21:43 GMT
My issue with this whole issue is choice.
Even if I select "Spark only" its loads the MX library core and  Spark
components which are based on mx.core.UIComponent.
I love the desire for backward compatibility but GIVE ME A CHOICE to cut
the mx framework loose. Its still loads 6 RSL
with its loading time which people use as the excuse to dump Flex. Unless
this is FIXED, this framework does not have a
snowball chance of Hell of every be successful.
Suggestion: Based Spark classes on a SPARK base framework class and not
mx.core.UIComponent with its 14 thousand
lines of code.
Over engineered much?
I already building up my own Spark custom framework rather than the one
from Flex 4.6.
I basically getting components only as 1/3 as big and running nice and
fast. Although I like the Flex framework
I like to use less functionality and get smaller components than the option
of loading two frameworks

On Sun, Mar 4, 2012 at 7:19 PM, Michael A. Labriola <
labriola@digitalprimates.net> wrote:

> > In Conclusion in my opinion:
> > Spark should be the base for all components from now on.
> > MX should die mainly because we cant use it for Mobile and it is not
> > based on Spark (that makes the SDK more hard to maintain).
> MX can't die. It is still used by many more projects than Spark. It will
> need to be maintained for the foreseeable future
> > A new components list based on Spark should replace MX for easy and
> > simple skinning use cases.
> I think it's fine to have a rich set of skins that you can use if you want
> all of those styling attributes. I would hate to penalize every project
> though. It still seems to me that, like HGroup and VGroup, we can extend
> all of these classes and put them in a library... perhaps SparkSimple. It's
> nothing but composed versions of the other classes with a more full
> featured skin and additional style declarations. To me that would be the
> way to solve both issue.

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