I'd say that this depends on workflow. If you have a photoshop composite that you know you are going to stick to like glue then you want to use the minimaly weighted set of components necessary to make it look that way and get the potential performance gains.
But if you expect a lot of design changes based on client feedback and multiple iterations, it's much nicer to have the fully skinable and customizable ones like the mx components where there is a lot of built in flexibility to quickly modify things based on client feedback. Space is a perfect example. Space is seldom just space. It often can have a color or texture and a very elegant ui may have subtle animated transitions in the spaces to lead the viewers eye. Unless you really know that that space is really just blank space the argument could be made that having a visual characteristic that you can't easily style or change is premature optimization. I'd say that flex has two really good niches, even in the browser world for years to come. Data heavy apps that utilize remoting performance and Visually heavy apps that pay the utmost attention to every 10 pixels of space. I think that a good goal would be to use the spark architecture to focus on super performant minimally heavy components for data heavy apps and for mobile apps with minimal skins, then to have a layer of optional skins that emulate the mx functionality for the visually rich applications. This kind of setup would also allow a company with a current mx based app to first move to the spark architecture more easily and then strip out the mx simulator skins and replace them with mobile skins to repurpose their apps for tablets. On Thu, Mar 1, 2012 at 10:47 AM, Michael A. Labriola < labri...@digitalprimates.net> wrote: > > >I agree the name could be misleading, could benamed SkiinnableSeparator > but this is another component and could be contributed by interested > developers. > > Or, in the Flex 4 model, you can but an empty rectangle in the 'space' > that you need. It doesn't carry the weight of a whole component and is much > more performant. I wouldn’t object if you wanted to have a graphical > element which just was used for spacing. It's not ideal in my opinion but I > get the reason. Having a whole component with all of that overhead and a > lifecycle just to space something out though is really wasteful > > >
