Page History

FlexJS is the name for a next-generation Flex SDK that has the goal of allowing applications developed in MXML and ActionScript to not only run in the Flash/AIR runtimes, but also to run natively in the browser without Flash, on mobile devices as a PhoneGap/Cordova application, and in embedded JS environments such as Chromium Embedded Framework used in the [Adobe Common Extensibility Platform | http://www.adobe.com/devnet/creativesuite/articles/introducing-html5-extensions.html ].  FlexJS has the potential to allow your MXML and ActionScript code to run in even more places than Flash currently does.

The primary motivation for FlexJS is the leveraging of existing Flex code bases.  While Flash is expected to run in browsers that run on computers with traditional keyboards for years to come, existing Flex customers are finding that they want their applications to run in places that Flash/AIR will not run because some of their end users are now allowed to use devices like tablets as their only computer.  The cost of migrating an application is high, and the risks around quality control are significant, especially when migrating to a less-strict language like JavaScript.

h3. Overview
FlexJS is based on the concept of parallel frameworks.  The framework components will have both an AS and JS version, and a next-generation compiler knowns as Falcon will translate MXML and AS to JS and link in JS "classes" instead of AS classes to create the JS output.

{gliffy:name=FlexJS Workflow|align=left|size=L|version=3}

Because ActionScript and JavaScript are based on ECMAScript, most code written in AS translates well to JavaScript.  This is because, in most applications, the vast majority of code a Flex customer has written is not actually dependent on Flash. The underlying components like Button and DataGrid probably have dependencies on Flash, but there are equivalents in HTML and other JS frameworks. Thus to the extent a code base consists of assembling a bunch of UI controls into a view and integrating the view with ActionScript to business logic also written in ActionScript, it should be possible to have that code base leverage Flash-dependent controls in a SWF and leverage HTML-dependent controls without Flash in the browser.

h3. Status
FlexJS is currently a prototype.  A simple POC example that allows you to choose a stock and get its price is [here | http://people.apache.org/~aharui/FlexJS/DataBindingTest/bin-release/DataBindingTest.html].  Right-click and choose View Source to see the MXML and ActionScript used in the example.  The MyInitialView.mxml contains the UI and uses view states, databinding and custom CSS just like a regular Flex-based Application.  Then go [here | http://people.apache.org/~aharui/FlexJS/DataBindingTest/bin/js-release/] to view the app running in the browser without Flash.  It is cross-compiled from the exact same source that created the Flash SWF version.  If you right-click on this version, you will see that there is no entry about the Flash Player in the context menu which is proof that it does not use Flash, and you can choose View Source to see the minified JS output from the FlexJS compiler known as Falcon.  Also note that both the SWF and non-SWF versions are much smaller than any version you could create with the current Flex SDK and start up much faster.

You can try the developing code with the prototype by following [these instructions | https://cwiki.apache.org/confluence/display/FLEX/Using+FlexJS+with+Adobe+Flash+Builder]. 

h3. Schedule and Resources
Apache projects, including Apache Flex, are primarily staffed by volunteers working in their spare time.  As such, a schedule of milestone dates is not practical.  The next major goal is to create an alpha-level release, hopefully by the end of 2013, but how soon that happens depends entirely on the number of folks who have time to contribute.  There is still a fair amount of work to convert the prototype to alpha stage.  Anyone with the time and energy is welcome to join in this effort.

To get to an alpha-level release, the following tasks need to be completed.
# Compiler integration with Flash Builder project options
# Launch Configurations for creating new Applications and Views.
# Custom CSS property support
# Minimal Implementation of DataGrid
# Minimal Implementations of Charts

We also could use resources to help build out an automated testing suite, documentation, and examples.  A prototype of a Selenium-based automated testing engine for testing the JS side has been contributed but more tests need to be written and it would be interesting to find a way to leverage existing tests from the Flex SDK that are written in MXML and not Java.

Participation in any form is encouraged and welcomed.  To follow the development of FlexJS, please subscribe to the Apache Flex mailing list dev@flex.apache.org.  This is a high traffic list, but we try to mark all FlexJS discussion with the subject "[[FlexJS]]".

h3. Summary
FlexJS should provide the lowest-cost and quickest path to future-proofing existing Flex code bases, and provide similar developer-productivity and quality control advantages that the current Flex SDK provided.

For details and information here:
[FlexJS FAQ]
 
Development Strategy
The current Flex SDK represents many years of development.  There is no way a volunteer-based effort can quickly reproduce a next-generation of all of that code.  Not all of it will be re-created in FlexJS as some APIs, especially XML/E4X APIs, will probably not translate well to JS.  But under the hood, the new framework is designed to leverage incremental development.  The most common APIs of the most popular UI controls will be developed first, then additional functionality will be added over time.

Backward Compatibility
The FlexJS framework will not be 100% compatible with the current Flex SDK.  Many implementation decisions will be decided by what will result in optimal JS output as well as what can be implemented in the short term in JS.

However, the goal is definitely to try to utilize as much existing MXML and ActionScript in existing applications as possible, and leverage the knowledge base and skill sets of experienced Flex developers and even leverage the tools such as Adobe Flash Builder.  If you have an application consisting of 10,000 lines of MXML and 100,000 lines of ActionScript, instead of having to rewrite each and every line directly to JS or to some other JS framework, you should be able to use FlexJS and rewrite significantly fewer lines to get this code to run without Flash.  FlexJS will support "states", databinding, and CSS just like the current Flex SDK (with some limitations).


Ease of Conversion
A quick assessment of the how much work it will be to switch to FlexJS can be done by searching existing code for "import flash".  Files that import classes from Flash packages are generally using APIs that will not be in early versions of FlexJS.  Note that importing flash classes in MXML files is not required so finding use of low-level Flash APIs in MXML files is not practical.  Some Flash classes are events which may be supported by FlexJS.

One way to think about the migration to FlexJS is to ask whether you would have had to rewrite it anyway.  For example, the FlexJS compiler does not support E4X expressions.  JS has no E4X equivalent, so you would have had to re-code E4X expressions whether you switched to FlexJS or some other JS framework.  If possible switching to JSON is recommended as it is supported in both AS and JS.

Performance
One unanswered concern at this time is about performance of the JS output.  We won't know for sure until we get enough infrastructure working to run a large app, but the goal is for the JS framework to be as low overhead as possible.  If you were to migrate your app to JS either directly or via some other JS framework, you would most likely use some sort of object-oriented concepts in this app.  When creating components for FlexJS we look at what those constructs might be and then translate them to AS classes thus keeping overhead lower than writing code that leverages Flash and then trying to translate it to JS. Thus, if there is a performance problem with the FlexJS output, it would likely have been the case even if you had used some other JS framework.

Browser Support
The plan is to support IE8 and later, and relatively recent versions of FireFox and Chrome and probably even Safari.  Thus an HTML5-capable browser is not a requirement to use FlexJS.  There may be different versions of the JS components that are HTML5-dependent that provide faster or smaller output if you can require HTML5 browsers for your target customers.

JS Frameworks
There can be more than one JS version of a FlexJS component.  There is already a prototype of a JS version of an Application class that includes the startup code for a JQuery app and then the Button component wraps the JQuery Button.  Thus it is possible to use MXML and AS to construct a JQuery application.

One-time Migration
It is probably possible to create a tool that translates your MXML to HTML in some way so that you can run your application through the compiler, get HTML and JS and never go back to MXML and AS again.  There will likely be some way to dump out the HTML from the app at runtime.  But many UIs are too dynamic to be easily represented in HTML.  Thus the goal of FlexJS is to provide for the use of MXML and ActionScript as the ongoing development language.

This is an advantage to using a more strict language like ActionScript in your development and why Flex was so successful at developing enterprise-grade applications.  There are fewer ways to make small but highly-impactful mistakes in AS.  Hopefully your large applications are written with some level of modularity. The language and compiler force you to be more careful at the integration points between those modules.  And while some JS frameworks can do much of that as well, the fact that you can produce a version of your application that runs as a SWF in Flash gives you one more level of checking because the Flash ActionScript VM will perform runtime checking of your code.  This is especially important in highly dynamic applications where modules are loaded on the fly and may be provided by third parties.  There is not always a practical way to compile-time check that the integration points are fulfilling the contracts in other JS frameworks if you don't have all of the code in one place.


{pagetree2:@self}