...

And then, if you want, you can install Cordova/PhoneGap, set up a simple project, and swap out the default index.html and .js files for the ones in the example folder and watch the same UI show up in one of the targets for Cordova. I got it to work on Android. I haven't tried IOS yet.

The key is that existing user code for an application can be cross-compiled into JS and run on browsers and mobile devices without Flash/AIR, assuming that the existing code does not directly call Flash APIs. This is hopefully true for existing business logic, but unlikely for views which would have to be re-written. Still, it means that much more existing code can be saved and re-used when migrating off of Flash/AIR than porting whole applications to other languages.

Building the example

• Create a Flex Library project in FlashBuilder for the src/FlexJSUI folder. It should output a FlexJSUI.swc
• Create an Actionscript-Only project in FlashBuilder for the src/FlexJSTest/FlexJSTest.as folder and file. Don't use the .mxml file as the application as the compilers don't know how to codegen in the "new way". FlexJSTest.as should compile into a runnable SWF. A click on the button should change the text. Note that the SWF is only about 11K!
• Now copy all of the .as files to a folder somewhere.
• Copy the FlexJSUI.swc as well.
• Run FalconJS on the FlexJSTest.as file. You should get a set of .JS files.
• Make a subfolder called js
• Copy the adobe.js from the FalconJS source tree to the js folder
• Copy the framework.js from the FlexJS/js folder to the js folder
• Copy the index.html from the example/FlexJSTest folder
• Run the index.html in a browser (I've seen it run in FireFox on Mac for me).

...

Also, since Dictionary and weak references don't really exist on HTML/JS, the new framework will not use them on AS and you may have to explictly explicitly call release() or some other API on some objects to make them available for garbage collection.

Pay as You Go

Everything should be "pay as you go" or "just in time" or "on demand".

Plan

The initial versions will be relatively feature-poor compared to Flex, but the hope is that the architecture is small enough and modular enough to allow Apache Flex community members, many who are participating in their spare time, to participate without having to be immersed in the internals of the framework.

Implementation Details

PlugIns

In the subfolders of FlexJSUI, you will see a pattern for the framework. The pattern is that components are composited from smaller pieces. I call them "beads". There are placed on a "strand". This is also an extensibility pattern as new beads can be placed on the strand and modify the behavior of the component. Example beads would be accessibility beads or test automation beads. There also a potential for an IDE to place beads on component instances only the equivalent of the Adobe Flash Builder design view in order to get the components to cooperate in a visual designer tool.

MVC in components

Skinnable components should have a model bead, a controller bead and a view bead which is effectively the skin. In theory, the model and controller beads should not use any Flash APIs and can be easily ported or cross compiled to JS. The View bead is where the platform dependent code lives.

Note that this is a bit different from Spark Skinning. In Spark, the model is baked into the component. This resulted in some undesirable consequences such as, if you wanted to an another visual entity to the skin, you couldn't just swap in the skin, you had to subclass the host component and extend the model there. With a separate model, you can swap in an extended model to match your swapped in skin.

Pay as You Go

Everything should be "pay as you go" or "just in time" or "on demand". The current Flex framework is slow because it runs a lot of code "just-in-case". For example most mobile apps initialize a PopupManager. And other code sets up a layer for custom cursors. No need to do that unless you are really going to use it.

Pull, Don't Push

A UI is generally a tree of components. In general it is created from the top down. Also, in MVC, the Model shouldn't know about the View. Further in Flash, components can be loaded late via other SWFs. And finally, child objects shouldn't always need to be created until just before they are used.

Because of all of the above it is better for a child to pull information it needs on-demand from the parent. This should make things faster but also forces other departures from the way Spark works in Flex today. The SkinPart concept is a push-down from the component/model to its child skin.

Most Dependency Injection implementations seem to also push dependencies to the child. I claim it will be more efficient for a child to get its dependency on-demand.

ValuesImpl

Another feature of this framework is a central "ValuesImpl". Flex today has several ways of getting a configurable default value for certain properties and styles like StyleManager and ResourceManager. I want to create a single place you get your default values whether it is some dependency you need or some default value for a property or style. And the implementation behind the values can be swapped out for things really simple like a flat list for really small apps, or full CSS and locale order support for more sophisticated apps.

Pros and Cons

Pros

• SWFs will be smaller (the example SWF is 11K) and should run faster mainly because there is less code running just-in-case.
• Beads make it easier to unit test pieces
• Beads encapsulate platform-specific code from platform-independent code
• Composition encourages more code re-use for smaller and faster apps

Cons

• Subclassing is no longer the way to customize components. This is because the the behavior you may want to change is in a bead that doesn't proxy its APIs to the component hosting it. This will curtail the use of MXML components.
• Interstitial costs. Everything is now one more level of indirection away. Will performance suffer?
  Number of choices