incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Labriola" <labri...@digitalprimates.net>
Subject RE: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Date Sat, 03 Mar 2012 02:17:05 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.

If they hit their sweet spot at any point, they might have made enough money to fulfill both
of our wishes. Further, whether or not something was commercially viable is not an indicator
of its strengths from an architectural perspective. While there may be more small teams, those
enterprises that were employing hundreds of developers were also the ones churning through
people and effectively paying to train new developers which enter the market. This is good
for everyone involved. They were also the ones that, marketed to effectively, could have paid
for the features every product could use. Incidentally, I did not say I was happy with Spark.
I said that parts of it were a step in the right direction.

Flex 'died' because it took 2+ years to develop the next, and still incomplete, version of
a component set.

>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.

I am a consultant. I worked on projects large and small and you are in the vast minority of
people who believe that mx covered 95% of most user's needs. Incidentally, I never argued
that we needed a complete component rewrite and I am not pushing for that now. I would have
much preferred an iterative improvement model to mx over the years. I don't think our ideas
on this are very far apart in truth. I was just pointing out that the spark architecture does
give us several things mx never did. We can build on both of these to make something that
is 'pay as you go'. That means we cover the small projects needs but don't handicap the bigger
projects. That is all I am after. I don't want to change the model, I want to remove the barriers
that prevent us from doing more.

>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.

We don't disagree on any of your major points.

Mime
View raw message