Adobe have done a great job with Flex (and in the years to come it will hopefully improve)! But Flex comes with a certain weight that makes it nearly impossible to use when we have to develop the class of applications that I want to stress on. The overhead of the framework is too big to be ignored. Our main concern is that this will eventually result in poorer user experiences, because of initial download times and performance overhead. But even if we circumvent this issue in some way (check Vladimir’s article on Totally Custom Preloaders), the SWF will still include code dependencies that are used nowhere in the application. Not to mention that the whole component model is too heavy and complicated and will eventually stand in our way when we have to implement a totally custom experience. This complicated model also requires too much processing power to handle the advanced aspects of the business applications that results in poor performance when you are focusing on the user experience.

Introducing FLit

But on the other hand Flex comes with a set of tools and concept that we really love and still want to be able to use. So what we end up doing in our free time in Obecto is a framework that would enable us to use Flex for really custom Flash apps with a minimal overhead from the framework. And we called this framework FLit – a light-weight Flex for Flash apps. We’ve been developing it as open source from line 1 – so feel free to check out the source from Google Code. There you’ll find some samples too!

Why we call it FLit?

First, FL stands for Flash. We want to build plain AS3 projects without the need to use <mx:Application> as a root object for our apps, and we want it to be as fast and as small as a plain AS3 project could be.

How do we use Flex in FLit?

As you might guess FL also stands for Flex, but we only use a small subset of the Flex Framework, like Data Binding and MXML, and nothing else – no UIComponent, no Flex Application. How do we succeed in using MXML inside of a plain AS3 project? Well, this is a topic for another post.

We are also using a concept pretty close to the view contract in Spark, thus enabling the separation of concerns between the designer and the developer.

What do we mean by lite?

We understand liteness as to have minimum dependencies between components, thus there are no components in the framework that will induce as dependencies a substantial part of the framework itself.

We understand liteness as the ability to include only those concern that interest you and not having behavior “hard-coded” in the framework. This should be beneficial both as download size as well as performance increase.

We also understand liteness as having a lite build process. Previously when building custom Flash apps we needed to use the designers’ machines and the designers’ productivity tools for the build. With FLit this is not the case – the designer is responsible only in preparing assets that must contain the parts specified in the view contract, so the productivity tools are not used for the build. So, this is also a pretty lite skinning process.

The current state of FLit

FLit is in early experimentation phase. Maybe this sample somewhat summarizes what’s inside the framework now? You can also check out the sample’s code!
A summary of features:

● light-weight base component
● light-weight base container
● view contract specification through metadata tags
● skin asset
● several layout strategies
● transition manager that supports declarative transitions between states
● tasks (an idea which originated from the GuggaFF) – Sequence and Parallel are also tasks
● declarative input validators
● skin-able button component
● tweening engine