Prototype source and example checked into http://svn.apache.org/viewvc/flex/whiteboard/aharui/flexjs
Active development branch is: http://svn.apache.org/viewvc/flex/asjs/branches/develop

Breaking News

• Minimal MXML handling now supported. See https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Status

Overview

With the donation of FalconJS, the Apache Flex community has an important tool in the pursuit of getting Flex to run without Flash/AIR. There are multiple possible approaches to achieving this goal. I have chosen one approach. The basic premise is that Apache Flex can provide parallel frameworks, one written in AS and another written in JS (and potentially others written in other languages) that abstract the differences between the platform into components in the framework. MXML is used to declaratively assemble components, and AS is used as the glue code and business logic. FalconJS converts the MXML and AS code to JS and the JS framework is swapped in instead of the AS framework and suddenly your Flex app runs in the browser.

...

It might be that if we implement really good CSS Media Query support that folks will be able to tune their UIs via Media Query, but right now, the prototype doesn't produce HTML, the MXML generates a data structure and the components create the DOM elements dynamically. We might want to add a capability to dump out a screen as HTML and make the components smart enough to try to find themselves in the DOM at some point in their lifecycle. That way, folks who specialize in browser-specific UI tuning can tune the HTML and CSS in the language they know best.

To Do Items/Next Steps

• Pick a place to work in SVN. I think I will leave the code untouched, branch it and start working in the branch so the demo continues to stay in working order. Not sure where to put that branch, but will decide soon.
• Improve Falcon MXML handling. We need to get Falcon to handle more and more MXML scenarios
• Get Falcon to generate data structures instead of code. Probably via some flag that leaves the old generated code around so we can double check if a bug is in the compiler or somewhere else.
• Figure out how to generate the right JS from MXML. I'm not clear that Falcon goes through the AST reducer phase for MXML so we might need to add some hooks for FalconJS to get in there.
• More components. Feel free to try to write new versions of existing Spark and MX components via beads. Remember, start simple and build up from there.
• More CSS and Media Query support. We will need to have better CSS support than we do now, especially for media query so folks can try to tune their apps without needing to see the HTML. I've been wondering for some time whether the current Flex CSS implementation which uses the prototype chain continues to be the right approach. Several years back, there was an article by someone who wrote the CSS implementation for one of the browsers and he said he wasn't building up chains, he would just walk the HTML and see how the CSS applied.
  Several tests have shown that in Flash, the ability to use the prototype chain is about 10 times faster than equivalent AS code that tests of the object has a property then checks some other object higher in the chain. However, it isn't clear that in a full CSS implementation, especially one that honors the "inherit" value, that the overhead of creating and maintaining the chains as the UI morphs through various view states overwhelms the advantages of the prototype lookup. So some experimenting needs to be done in this area.