The Need for AS3 (non-Flex) UI Components

Aug 09 2009 Published by under ActionScript, Flash

Am I the only one to notice a gigantic gap in the Flash Platform? I’m talking about the lack of AS3-only UI components.

Currently there are three main ways to create a Flash application.

1. Use Flex and MXML in Flex/FlashBuilder (or mxmlc and your favorite editor/ide).

2. Use the Flash IDE.

3. Use AS3 in Flex/FlashBuilder (or mxmlc and your favorite editor/ide).

In option 1, you have the vast and awesome set of Flex components.

In option 2, you have the less vast and less awesome set of Flash components.

In option 3, you have… nothing.

OK, smarties, I know what you are saying. “You can use the CS3/CS4 Flash components in Flex/FlashBuilder!” Yes, just follow these 20 simple steps: http://www.moock.org/blog/archives/000253.html and you’ll be up and running! Even Mr. Moock says, “the process isn’t pretty”. Oh, not to mention the fact that this requires purchasing both Flash and FlashBuilder. If you don’t actually use the Flash IDE, that’s a lot to pay for those components. Additionally, those components were designed for the IDE. They are jammed full of stuff for live previews and component parameters in the IDE and their whole skinning system relies on you being able to double click on the symbol on stage or in the library and change the skins. I know that none of that makes them NOT usable in Flash Builder, and I know there are ways to skin the programatically. But you are essentially retrofitting something built specifically for one IDE to work in another. This means you are missing features that are in the original IDE, and they are missing features that should be tailor made for the IDE you are using.

But overall, it’s just wrong that you should even have to go through such a process. I feel like there should be a set of UI components built for AS3 that you can use without jumping through hoops or spending hundreds of dollars on another whole program, and don’t depend on the Flex Framework.

This is why I started making my Minimal Components in the first place. I often just wanted a button or slider or something else for an experiment. So I made a few basic components, and they just kept growing.

Contrary to how it may sound though, I am not pushing for my components to be included in Flash Builder. They aren’t right for that purpose. Not by a long shot.

Actually, after writing this post, I think maybe the best solution would be for Adobe to simply include the Flash components in Flash Builder. Although there is some extra baggage along with them, It occurs to me that the wrong move would be to create another whole set of components. That would just cause more confusion than it’s worth. Perhaps a slimmed down set, without any of the Flash IDE (live preview, parameters, skinning stuff) included, but with the same class names, etc. so that a class using them could compile in either environment. Thoughts?

22 responses so far. Comments will be closed after post is one year old.

  • Abdul Qabiz says:

    Yup! There is huge gap, Adobe would not fill it because it doesn’t make sense to them. There are third-party component sets, like yours, but not all of them are cool and opensource.

    I like Minimal Components and planning to use in some of my projects. I would love to see some smart ways to skin the components, a way where code is not bloated but allows us to hook.

    Right now, I can always extend the individual classes and override the routines/methods to do things.

    -abdul

  • Jacob says:

    My experience is that most people i know doing as3 dev in flash builder have their own set of minimal comps. I have really always disliked the adobe components that come with flash and I am not a fan of mxml. the flex components are good, but they aren’t great, and flash components are good, but not great. I use that stuff for prototypes occassionally, but i use my own set of components for development, easy to override, expand, add features too, etc.

    The reason the adobe components are so bloated is because they are trying to be all things to all people. It really can’t work for everyone.

  • Pradeek says:

    Don’t forget the fact that Flex 4 brings up 2 sets of components – The already existing Halo branch and the new Spark branch…

  • Najier says:

    Good work Keith Peters.

    Speed. Speed. Becomes terribly important when developing a 100-screen application. The UI Framework gotta be lightweight, yet powerful. As starters, Minimal comps is compact and it would be nice to see it being extended to be used in commerical applications. How about extending it for bi-directional data-binding and some basic data validation?

    The Adobe components (Flex included) is too fat and the whole event engine makes the rendering of the UI components slow…which turns Users off.

  • Phil Peron says:

    Let me start by stating the obvious: You _can_ simply instantiate Flex components directing in ActionScript but that doesn’t make the awful performance issues go away as Najier mentioned. I’ve learned the hard way. I know improvements are being made in Flex 4 but it’s not fully baked yet.

    I agree that ideally, you’d have easy access to Flash Components but there’s something satisfyingly pure about the work you’ve done with MinComps. It also caters to my desire to avoid import flex.whatever.* in all my personal projects. (if I tried that at work, they’d hang me. ;))

    Not that I’m sitting on a boat-load of changes but are you accepting submissions?

  • Marcus Geduld says:

    Re skinning: I’d like to see a set of light-weight components that decouple their controllers and views into separate classes.

    That way, if I want to use a slider with a customized look, I just make my own view class with different drawing methods. I then register it with the controller class and it works.

    Ideally, the set would come with factory classes that bind the controllers with their default skin classes. So, if you just wanted to use a slider with its out-of-the-box skin, you could do so easily via just its factory class.

    Or you could combine the factory with the controller, allowing the controller to accept customized view classes but giving _viewClass a default property of DefaultSliderSkin.

    Extra points if, optionally, multiple components can use the same skin class. So I could make a skin class, define a drawSquare() method, and all the controllers that need a little square would use that method.

  • JesterXL says:

    Yes Keith, and like Jacob said, a lot of Flash devs who know what they are doing have their own components. I created a Flash Lite component set (Shuriken) over 2 years ago… and eventually coverted it to AS3 and started using it on all of my projects that weren’t Flex based because I wanted to code in Flex Builder and have small file sizes. I tried a few times using the Flash components via the SWC route, but it was painful.

  • Tom Carden says:

    I’ve been watching OpenPyro closely hoping that it’s the answer to this problem. Skinning didn’t quite work how I expected, but it was close and the developers are saying and doing the right things http://openpyro.org/

    There’s also ASwing, but coming from a Java background I don’t think it has the lightweightness you’re looking for http://www.aswing.org/

  • Tink says:

    Is there a good argument for not using Flex if you need components? Banners etc i guess, but then would you need components?

    I’d argue that any time spent on developing a decent component set would be better spent familiarizing yourself with Flex so you understand how to make it do some of the stuff it doesn’t easily do straight out of the box.

    A 100 screen application as Najier mention should initially be faster in Flex as it has built in deferred instantiation, only creating the screens that the user actually requested.

  • sv says:

    Check out AsWing.org if you’re looking for a complete open-source UI solution. However I agree that having a lightweight set of components would be nice too.

  • kp says:

    One reason not to use Flex: A Flex app with a label compiles to 152k. You carry the whole framework along with any app. If I’m making some game or experiment or demo or something, it might come in at a few k. Do I really want to 10x the size of it just to add a button or slider?

  • Tink says:

    “One reason not to use Flex: A Flex app with a label compiles to 152k.”

    The framework is cached though, so the user only gets that the first time they view any Flex app.

    I guess this doesn’t really apply to demo’s experiments, this comes into play once the app is released to end users in the wild (in my opinion when the size is important).

  • Matt Wright says:

    I would love to see more AS3 only components out there. As JesterXL said, most Flash devs, at least that I know, that need something like this have often come up with their own solution or use one of the available libraries/frameworks out there. In your case, Keith, what I think will be tough is keeping a good balance between lightweight and ease of use. In my experience, keeping something lightweight…like REALLY lightweight…often comes at the expense of something else. In most cases that expense seems to be the steepness of the learning curve and the time it takes to implement the component. By the way, I really like your component set.

    What I’ve done is created a set of my own abstracted component classes which let me, relatively easily, create my own custom controls, such as buttons, combo boxes, radio buttons, sliders, etc. I like this approach because the abstracted class simply has the functionality built into it, but does not render anything to the stage. This approach works for me because I strictly use the Flash IDE and the projects I work on all have a different look and feel.

    With this approach, I simply have to extend the abstract class, tell it what the visual parts are, override a few methods depending on the control and I’m off and running. For example, my AbstractSlider class has the class property thumb:DisplayObject. The abstract class doesn’t render the thumb at all, but has methods in it that handle the dragging of it and updating of the position property to a value between 0 and 1. I can then just override the getPositionFromThumb() method to set the value of the position as the thumb is being dragged. The draw back to this approach is that I have to have a pretty good knowledge of how the abstracted code works in order to get my component working. The advantage is that it keeps it nice and lightweight and doesn’t include unnecessary rendering/drawing code.

    I like this approach because I can draw my components either in the IDE and attach a class to it that extends my abstract, or I can just extend the abstract and draw the component using the drawing API. So what I’ve also done is created a generic set of components that extend the abstracted set and only use the drawing API so that they can easily be ported from project to project and used for easy prototyping.

    Jeez…I didn’t mean to write that much…at any rate, maybe its just something to consider as you work on miniml.

  • Kevin Hoyt says:

    For those complaining about the size of Flex applications, don’t forget that you can use framework caching (mentioned) such that you 152k becomes more like 55k. There’s also module support in Flex that allows you to load portions of the application on demand. Overall though, I’d have to say that 152k is pretty minimal. Most web sites these days close in on 1 Mb – CNN, Amazon. Bring up a story, or search for a product and you’ll get all that over again. A data-centric application, like Google Mail (with just 50 messages in my Inbox) comes in around 2 Mb.

    But! I personally really like the idea of a non-Flex framework. What would it have in it though?

    Well, I use layout management a lot, so some constraints would be good. Then, I’m certainly going to be customizing how the components look, so some fashion of graphic or drawing-based skinning (preferably with 9-slice support). I’m going to do animation, so it should probably have that, or allow me to easily incorporate one of my own choosing. Of course, if I’m going to animate, I want to embed fonts for easy rotation, etc. Probably some fashion of focus management as well so my users know where they are at in the application.

    Now we’re probably getting a bit heavier as a framework, so I’d like to have an extensible pre-loader as well. It should probably go without saying that the components should support virtual lists so I can scroll through larger data sets as well. And I should probably be able to at least sort on those data lists. So long as we’re talking lists, don’t force me into your idea of how a component should operate. If I want a combo box thats opens in a spiral, then that should be my choice. Or maybe I want to have one row in a list taller than another row. My call, not yours.

    I could probably live without MXML, CSS and modules. Inline editing for lists is really nice to have, but for the complexity of item renderers, I’d make due with other UI patterns (i.e. classic master-detail). I can probably manage drag and drop myself as well, thanks startDrag(). I’ve never used the Flex forms or validation architecture, and rather prefer to leverage regular expressions. I’m an American, so naturally, localization is just overhead (wink).

    For what it’s worth though, but the time a framework has most of what I’ve asked for above, it’s probably getting pretty close in size to just using the Flex framework itself. For me, it seems that I’d like 75% of what Flex offers. But that’s me – and I think that’s the hard part of the question.

    How do you make a UI component framework as diverse as its possible uses, yet still keep size down? Aren’t size and function kind of inversely related? And when we finally build our new lightweight component set, does that create a fork in the community? One that might hurt the overall growth rate of the community? Certainly the number of Flash developers out there has grown in large part thanks to Flex. Also, are we eschewing team productivity? Does a hiring manager now need to look for a Flash developer with experience in yet another framework? How is tooling supported around this new framework without MXML?

    FWIW,
    Kevin Hoyt
    Adobe Systems, Inc.

  • Keith Peters says:

    Kevin, well, IMHO, I don’t think a component set has to be a COMPONENT FRAMEWORK and doesn’t have to be “as diverse as its possible uses”. We need some basic controls that we can throw into an ActionScript 3 based SWF. I’m building a game or a simple site or some kind of ad. Whatever. I need some labels and maybe a couple of text input fields and a button. Now, framework caching or not, I don’t think it’s right to integrate the entire Flex framework into your app just for a button and a couple of text fields. For a larger application, sure, bring it on.

    Well, we have buttons and text fields as built in objects in the player. So you say new TextField, size it, make it input text, give it a background and a border, no wrap, no multiline, default text format, alignment, color, embedded fonts or not, etc. It’s about a dozen lines of code. We’ve all done it. You get sick of doing the same thing over and over, so you make a factory method that creates these things for you. Then you say, ok, make it a class all by itself. Bam, you’re building components. Do the same thing for a button. They share some of the same resizing code, etc. so you make a base class. Bam, you have a component set. Throw in a label next week, and bit by bit it builds up.

    Tink has some compelling arguments about just using Flex for everything, but we haven’t all drunk that KoolAid. 😉 The point is, as several have mentioned here, just about every dev team is making their own component sets. So, there’s already a huge, multi-tined fork in the community. Of course, lots of devs are still going to want to use their own component sets even if there was another available.

  • Good Article Keith.

    I have looked in depth into Flash IDE Component Code for flash CS3, Flash CS2, Flex Halo, and until Spark it was all very poorly done. So for the most part, even if it was light weight, the presentation being tightly coupled with the control logic and layout logic made components hard to use, and the fact that many properties are private and not protected made them impossible to extend. So if I need a quick scroll bar I write my own. If I need a video player that works, I definitely write my own, and if I need a highly programmable component set I use aswing, and if I need a highly skin able component I take the existing Flash IDE component and rewrite it so its open and clean and optimized.

    When I was at Adobe for the last Flash camp I talked to the flex team about this issue. Particularly I asked while layout management was tightly coupled with the component set, which tightly coupled with MXML in this monolith closed library called the flex framework which you have to use when using catalyst to design a project. Why not separate everything, and open it up as separate open libraries full of well coded Actionscript 3.0 . Then we devs could pick and choose and understand whats going on under the hood. I don’t think its ever good to add libraries you don’t need whether its 152K or 55K because you are adding unnecessary complexity.

    The flex team responded with attempts at Jedi mind tricks while all chanting in unison “Just use the Flex Framework, it will handle everything”. That was the response to each of my questions and points. There was no dialog, there was one way chanting. I know all the people at adobe are nice people, there technology is great, but for some reason or another, they are not responsive to the very obvious feedback – break up the flex framework into its functional parts, make each part open to extension, and well separated, and open to use regardless of development environment because us developers should not forget our duty to only use what we need, and understand what we use, we should not “Just use the Flex Framework”.

  • Kevin, everything Keith said above, plus: you clearly (and not very surprisingly) want Flex. Your comment almost reads like a short summary of Flex 4 features. 🙂

    The point was that many people have use cases where Flex simply doesn’t fit well, for various reasons.

    Also, 1mb websites and 2mb web applications shouldn’t be benchmarks imho.

  • Tink says:

    “The point was that many people have use cases where Flex simply doesn’t fit well, for various reasons.”

    Why doesn’t it fit well. I’d be interested to see some specific cases, and see if its down to the dev’s not having the in depth knowledge required of Flex to get it to do everything you might need it to. This requires some investment in time, but that time is better invested than us all creating different component sets. Instead we could be working to improve Flex.

    “Also, 1mb websites and 2mb web applications shouldn’t be benchmarks imho.”

    As Kevin said once the framework is cached you looking at about 55k, so the fact that 1mb/2mb websites was mentioned doesn’t really bear any difference to the discussion. In fact surely at 55k we can just remove the size of the framework from the discussion totally?

  • Pickle says:

    How can we use Framework caching as a reason not to worry about Flex framework size when it’s an option that not all browsers support? Framework caching only works well if your browser is set up properly. By choice, my browser does not cache the framework between sessions. I wonder how many people actually have full framework caching enabled?

  • Kevin Hoyt says:

    In all fairness, I rather resent the implication that because I work for Adobe, that all I want to do is to promote Flex. In looking at my blog history, you’ll find three posts (of 23) dedicated to Flex in the last year. Otherwise you’ll see a comparison of non-Flex Flash mapping libraries. TweenMax experimentation. Non-Flex image encoding and manipulations. Non-Flex Player 10 file IO. Go back far enough and you’ll find complete Flash Lite applications. Heck, I even blog more about JavaScript than I blog about Flex. Further, the reason AFCS now has a non-Flex library is because I championed the cause with the engineering team.

    My comments read like a Flex feature list because when I start thinking about what I’d want in non-Flex components, I look to Flex as a reference of what’s possible.

    By automatically inferring that because somebody works for Adobe that they must want to convince you to use the Flex framework, you really do your cause injustice. That means that before anybody from Adobe can openly participate in the conversation, that they must first defend themselves out of wanting to force feed you Flex. Nobody wants to have to start a conversation by defending their interests in it, and most would simply walk away. Personally, I’m a stubborn SOB.

    I am very fond of the idea of a non-Flex component set (thanks for the clarification, Keith). I even more like the idea that there might be a way to split up the Flex functionality into smaller, non-interdependent libraries (e.g. layout, skinning, components). Before certain component sets or feature libraries could be successful however (at least on a scale that becomes interesting to a company the size of Adobe), there’s certain things that they’re going to need, and I think every developers perspective of what that is will be different.

    In the end then, I think this type of project is probably best left to the community (or a smaller company). Flex is open source. Eclipse is extensible. Have at it! And indeed, from the resources posted, it looks like that’s happening. I applaud those efforts, and would encourage others having the non-Flex conversation, to get involved with one of those projects before reinventing the wheel yet again.

    Finally, because it was brought up by another commenter, and in the interest of clarification, note that caching of the Flex framework is not dependent on the browser cache. Flash Player itself has a cache on disk, where the Flex framework is placed. You can clear you browser cache all day and not impact the Flash Player cache. The only way to dump the Flash Player cache is in the global settings manager for Flash Player. Flex, as a signed library from Adobe, gets special privileges in this respect, and is not treated like other libraries.

  • arpit says:

    @Tom Carden
    Thanks for the kind words on OpenPyro. The state of skinning is as is because it has not really been implemented in any way close to maturity. I am still working on the core components functionality, implementing each in the most efficient way I can think of and I can happily say, getting pretty close to where I want to be on that front. Skinning is the next thing we tackle after we can make sure the core components work well with one given skin 🙂

  • […] Peters was right, when he said, that Flash has a lack of UI component frameworks. The Flex components has a quasi monopoly on that. Besides his minimal components there is another […]