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