Adobe TV: Open Discussion about Falcon and FalconJS

As you might already know Adobe hosted a Flex Community Summit in San Francisco early December this year. The recordings are now available at Adobe TV:

Flex Community Summit: December 2011
http://tv.adobe.com/show/flex-community-summit-december-2011

There is also a segment about Falcon and FalconJS that I recommend watching if you are interested in FalconJS:

Open Discussion about Falcon and FalconJS
http://tv.adobe.com/watch/flex-community-summit-december-2011/open-discussion-about-falcon-and-falconjs

Peter Flynn did a great job explaining FalconJS’s architecture and its current limitations in regards to cross-compiling Flex applications. I found interesting that the developers in the audience were eager to get the source code for FalconJS as soon as possible even though Adobe’s Flex team considers FalconJS for Flex an early research project.

If you watch the recording of the open discussion about FalconJS and Falcon you might walk away with the impression that FalconJS is extremely limited and barely working. I hope that’s not the case, because FalconJS, the cross-compiler, is working well and ready for integration into Adobe products and services. The parts that need a lot of work are FlashRT (the Flash Runtime implemented in ActionScript) and FlexJS (Peter’s work on cross-compiling the Flex framework classes to JavaScript) as well as support for MXML. In my opinion the discussion might have accidentally mixed the FalconJS cross-compiler together with other less refined parts.

 

 

 

 

 

 

5 Responses to Adobe TV: Open Discussion about Falcon and FalconJS

  1. Dimitri K. says:

    Hi Bernd,
    Thank you for your enlightening inputs. They’ve sure helped to clear some of the confusion about the current state of FalconJS.

    I really hope Adobe will be letting the community have a go to push this project forward as soon as possible, because I know a lot of people who are really looking forward to try to offer Flex a way to go beyond the Flash runtimes.

    On a side note, I also know that for lots of people, the reading of your posts was a great reminder concerning how far and mature AS3 is versus JS, even if JS as a few advantages (F5 = compiling being the real one).

    PS: Maybe there is a small type concerning FlashRT “the Flash Runtime implemented in ActionScript”, don’t you mean to say “implemented in JavaScript?”

    Happy holidays…

    • Bernd Paradies says:

      Hello Dimitri,

      thanks for your feedback! There are a lot of wonderful features and details in the Flex IDE that could make your life easier when developing JavaScript apps in ActionScript. In my opinion, the most useful Flex feature is actually being able to create libraries (SWCs). FalconJS solved the problem of embedding JavaScript into SWCs, which you can then link with your client code into one JavaScript app. Using SWCs reduces compile times from minutes to seconds.

      You pointed out that I might have inserted a typo in my description of FlashRT when I said that FlashRT was the Flash Runtime implemented in ActionScript (and not as you suggested in JavaScript). But that was not a typo. FlashRT is indeed written in ActionScript and then cross-compiled to JavaScript into flash.swc. Jangaroo does the same. Here is there ActionScript implementation of Sprite:

      https://github.com/CoreMedia/jangaroo-libs/blob/master/jooflash/src/main/joo/flash/display/Sprite.as

      I will blog about FlashRT soon. First I have to get the ActionScript language features covered…

      Happy Hollidays to you too!

      • Bernd Paradies says:

        (Not sure whether Jangaroo can compile to SWC… I think with Jangaroo you always have to compile the runtime source with your client code.)

        • Jangaroo’s Maven build process creates a JAR (essentially a ZIP) for each module, which contains the actual compilation result (JS files) as well as API “stubs”, i.e. AS3 source code of interfaces and classes without the implementation (using the “native” keyword). When building another module, the API stubs are parsed for reference, but the referenced module is *not* compiled again. Thus, you do *not* need the source code of the runtime or any other library, only the “binaries” (JS files) and API stubs.