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 . FlexJS has the potential to allow your MXML and ActionScript code to run in even more places than Flash currently does.
Overview
The original motivation for FlexJS was 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. A Connect presentation on FlexJS is available here .
However, as we've been working on FlexJS, it has become apparent that FlexJS should provide significant developer productivity gains for new projects as well. Flex was popular because it made it easy and efficient to create robust applications. Part of what made it easy and efficient was the Flash Player and AIR runtimes. They had consistent behavior across browsers and desktop platforms. But there were other things as well. Flex provided:
- Declarative Language (MXML)
- Semi-Structured Language (ActionScript)
- Runtime Verifier
- Choice of IDEs.
The combination of theses things made it possible to make fewer mistakes when writing code, thus saving time and improving productivity. Declarative Languages provide a schematic, or diagram of the pieces of the application, and are more terse than the equivalent in ActionScript or JavaScript. ActionScript understands classes and interfaces so it can do a better job of enforcing correct usage of APIs. The verifier catches errors at runtime. The IDEs can provide better code assistance because the language is more structured.
Developing an application by using one or more frameworks really amounts to attaching framework components to each other via code you write. With JavaScript, you can literally attach anything to anything. You can assign a String to an variable that was expecting an int. JavaScript has some 'compilers' that try to catch things like that, but once you start using Object or other low-level base classes like EventDispatcher, you can easily cause the compiler to lose track of the actual API parameters involved and not find out until too late. Sure you can go around and annotate the JavaScript so the 'compilers' can try to help you, but often you may accept code in library form from somebody, and even load that code at runtime. The verifier tries to catch those kinds of problems.
One analogy is "assemble-it-yourself" furniture from IKEA and other places. If those kits only had nails or screws to attach the pieces together, and only provided instructions without diagrams or other illustrations, folks would make a lot of mistakes assembling the furniture. Instead, those furniture kits come with custom connectors that only fit into certain holes and in the instructions have diagrams. Semi-Structured languages like ActionScript allow you to establish custom connectors so that the components can only go together in certain ways. Declarative languages like MXML provide the diagrams to help you see that pieces that you are attaching. The verifier acts like an inspector, checking your work at runtime.
In theory, any JavaScript that can be encapsulated and presented with a more strongly-typed API is a candidate for use by FlexJS. FlexJS will in turn make sure you use that API correctly, catching your mistakes sooner. We have prototypes of applications that work with JQuery components. FlexJS will have its own default set of UI widgets, but folks should be able to use just about any JavaScript UI framework if it can be wrapped in an ActionScript API. FlexJS is less about the UI widgets and more about the productivity gains in using those widgets.
How It Works
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.
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.
Status
FlexJS has some pre-releases, roughy of 'alpha' quality, available here. A simple POC example that allows you to choose a stock and get its price is here. 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 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 .
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 beta-level release, hopefully by the end of 2015, 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 beta stage. Anyone with the time and energy is welcome to join in this effort.
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]".
Summary
FlexJS should provide the lowest-cost and quickest path to developing applications for the web and mobile devices, while also future-proofing existing Flex code bases, and providing similar developer-productivity and quality control advantages that the current Flex SDK provided.
For more details and information see FlexJS FAQ.