FlexJS Frequently Asked Questions (FAQ)

What is FlexJS

FlexJS is the next-generation Flex SDK that allows an application written in MXML and ActionScript

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.