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