incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Date Sat, 03 Mar 2012 02:02:10 GMT
>
> So if paying for the flex Ide is their only revenue point, to say that the
> mx components were badly written is false. They hit exactly the crowd that
> they needed to hit with them. You may be happy with the spark components,
> but that's when flex died, after they were introduced. When the little guy
> was pushed out.
>

This.  I love the spark architecture, but that's because I have used mx
exhaustively (pushing its limits) and I know all the pain points.  So,
moving to the Spark architecture was a logical progression for me.

But, this also means that new folks that start using Flex 4+ for the first
time, dont have an easy entry point.  Changing the look and feel of an app
- which was extremely easy in mx is now a chore.  I know and have worked
with design firms that created new application styles using the 'Flex 3
Style Explorer' - which was an online flex application.  Thats it.  Thats
how easy it was to work with mx components.

I dont know if the answer is better tooling (Catalyst, Design view, etc.)
or if it is a question of more exhaustive documentation, working examples,
tutorials, etc.  Or even a change to the way Spark approaches skinning and
customizations.

This kind of developer outreach (especially for newbies) should also be a
goal for the Apache Flex project, IMHO.

Thanks,
Om


On Fri, Mar 2, 2012 at 5:10 PM, Cortlandt Winters <cort@cortwinters.net>wrote:

> Thank you, Micheal for a great response.
>
> I think what we have here are two radically different use cases.
>
> On the one hand flex needs to be a good enough framework that a team of
> three can create something of real value on a 10-30 thousand dollar budget
> in a few months. Without rock stars.
>
> On the other hand how can a  team of 100 which  was probably 10 times the
> number of core flex developers, do world class stuff if the sweet spot is
> for a team of 3-5?
>
> But frankly from Macromedia/Allaire and Adobe's standpoint, there are
> probably a thousand times more users
> in the first scenario than the second, maybe ten thousand more.
>
> So if paying for the flex Ide is their only revenue point, to say that the
> mx components were badly written is false. They hit exactly the crowd that
> they needed to hit with them. You may be happy with the spark components,
> but that's when flex died, after they were introduced. When the little guy
> was pushed out.
>
> I reiterate that there is not a single complete commercial spark component
> skin on any marketplace after two years. Mx skins weren't in the 100's but
> there were 30 or 40 attempts.
>
> Frankly, If you have a hundred developers, you had more than enough
> resources to take the core as3 language and build your own framework that
> covers this larger set of world class issues with a less feature rich end
> point.
>
> I have no doubt that given this experience you are well suited to guide the
> core framework internals in the future, but not if you can't recognize that
> it's a niche case and that mx covered 95% of most user's needs.
>
> Most projects can't create components for the project. Most projects use
> components to build the project. That's why they are called components.
> They are reusable. Most projects are focused on the content and use the
> components to display the content.
>
>
> On Fri, Mar 2, 2012 at 9:36 AM, Michael A. Labriola <
> labriola@digitalprimates.net> wrote:
>
> > >Ok. I'm totally willing to believe you and to think that I'm missing
> > something here but I think you have to explain that a little bit more.
> What
> > kind of apps were these? Were they super detailed subcomponents? Or was a
> > >combobox something that needed an item renderer? What other UI set are
> you
> > comparing them with?
> >
> > The need to build and extend these components for large enterprises
> >
> > >Or to put a hard number on it how big were these projects? Two people?
> > ten? or more?
> > Dozens sometimes hundreds.
> >
> > >But point me to a better set of standard ui components and make the case
> > for them, because then we can emulate them.
> > Its not that there is a better set. The point is that there are major
> > improvements that can be made
> >
> > >How did you like awt or swing or the microsoft native component sets?
> Did
> > you use the silverlight components at all?  Tcl did the job?
> > Although I didn't always like their internals, the quantity and general
> > extensibility of many of the Silverlight components was quite nice
> >
> > >Did spark solve your problems? Please tell me how removing the ability
> to
> > change simple things like label positioning and styles, base colors,
> > enabled something to solve your problems?
> > It solves many of the problems simply by delegating the instantiation of
> > the visual components to a separate, swappable class
> >
> > >Things can always be better, but what then, in your mind is the gold
> > standard that we should strive for? Because in my experience, the mx
> > components were the best out of the box stuff that I've been able to work
> > with.
> > The mx components were the multi-tool of the world. When you buy a
> kitchen
> > appliance that does -everything- you often find that it doesn't do
> > -anything- with expertise. We spent millions of dollars doing nothing but
> > changing the SDK so we could begin to extend it. Components being created
> > inside of 500 line methods which access private variables so you can
> never
> > change the implementations via subclass. Hardcoded dependencies, hell,
> even
> > the methodology by which createChildren checks for the existence of a
> child
> > before creating a new one so that you have this primitive sort of
> override
> > mechanism. All code smells.
> >
> > >You had to recompile the whole sdk to add minimal functionality?
> > We maintain nearly 15 copies of the sdk each modified in different ways
> to
> > suit client needs. Try to fix the i18n issues of the framework when
> > internally every object is bound to a hard date instance or uses a set of
> > string utilities which don't work 100% with 3/5ths of the world's
> languages
> > and you will quickly find that, to change one of those pieces (due to
> > coupling and hard dependencies) you have to override an entire branch of
> > the framework class by class, not just a node.
> >
> >
>

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