Dreaming up a Flex JavaScript SDK

We finally made it through the long list of language features and those odd three features (Weak References, Proxy, and Dictionary) that are langage and runtime features at the same time. We are now with both feet in runtime feature land! A few days ago I thought that perhaps the best way to introduce cross-compiling ActionScript runtime features to JavaScript is probably by describing a fictional Flex JavaScript SDK.


Science Fiction?

This may sound a little bit like science fiction to you, but what if you launched Flash Builder, hit File/New/Flex Project and checked “Use a specific SDK” under Flex SDK Version. From the pop-up menu you would then select “Flex x.x for JavaScript” (x.x being the version number) and that would be everything needed to get you started on writing your first JavaScript application in ActionScript. Or even better: You open an old Flex Project, navigate to File/Properties/Flex Compiler/Flex SDK Version, change the SDK to “Flex x.x for JavaScript” and recompile your project to an HTML app.

That’s how easy creating HTML apps in Flash Builder should be in my opinion. Everything should be transparent, even Flash Builder’s source-level debugging of ActionScript running as JavaScript in the browser should just work. JavaScript and HTML would just be features delivered through a specialized Flex SDK.


Flex SDK’s Blue Print

Let’s have a look at the current structure of Flex SDKs. Flex SDKs are usually located in the Flash Builder’s …/sdks/x.x.x version folders. For example you would find Flex SDK 4.6 in …/sdks/4.6.0. To me it would make sense to do the same with our Flex JavaScript SDK and use a folder like …/sdks/4.6.0-js .

Every Flex SDK has pretty much the same structure:

  • ant – support for ant (flex tasks).
  • asdoc – support for generating documentation from ActionScript source files.
  • bin – platform dependent launcher
  • frameworks – runtime libraries and skins
  • lib – Java JAR files used by the launchers in bin and by the Flash Builder IDE.
  • runtimes – native AIR framework for OSX.
  • samples
  • templates

Our Flex JavaScript SDK would probably use the same structure where it made sense. Only a few files and folders under lib and frameworks would need to be replaced.


What’s in the lib folder?

As mentioned earlier SDK’s lib folder contains Java JAR  files that are used by the platform dependent launch utilities in the bin folder and by the Flash Builder IDE. There are three JARs that I would like to focus on for now:

  • asc.jar – ActionScript compiler
  • mxmlc.jar – MXML and ActionScript compiler for creating applications (SWFs).
  • compc.jar – MXML and ActionScript compiler for creating libraries (SWCs).

Those are the main three JARs we would need to replace with our cross-compiler versions:

  • asc.jar (a.k.a. jsc.jar) – ActionScript to JavaScript cross-compiler.
  • mxmlc.jar (a.k.a. mxmljsc.jar) – MXML and ActionScript to JavaScript cross-compiler for creating HTML applications (JS).
  • compc.jar (a.k.a. compjsc.jar) – MXML and ActionScript to JavaScript cross-compiler for creating libraries (SWCs).

Those three JARs form FalconJS. Our Flex JavaScript SDK should probably use the original names asc.jar, mxmlc.jar, and compc.jar. Instead of lib/optimizer.jar FalconJS currently uses Google’s Closure compiler, which is copied into the SDK to …/lib/google/closure-compiler/closure.jar.


What’s under frameworks?

There is a lot of stuff under Flex SDK’s frameworks folder. In order to keep things simple I will only look at two sub-folders, which I think are the most important ones.

  • frameworks/javascript currently only contains one folder called “fabridge”, which contains glue code for DOM/SWF interactions.
  • frameworks/libs is the folder where you can find almost all of the SDK’s SWCs.

The frameworks/javascript folder seems like a good place to put JavaScript libraries like jQuery and Google Closure Library. The fabridge folder does not make any sense in the browser and should be removed.

In the “regular” Flex SDK  you’ll find within the frameworks/libs folder a SWC called player/x.x/playerglobal.swc, which contains the implementation of ActionScript core classes (Object, Array etc) as well as the complete Flash Runtime API (flash.display.* etc).

For our Flex JavaScript SDK I recommend splitting up what traditionally goes into playerglobal.swc into two pieces: browserglobal.swc (for the ActionScript core classes) and flash.swc (for the Flash Runtime API). Those two SWCs form FlashRT (or a.k.a “runtime-js” in earlier versions). The following list probably describes the bare minimum set of files you need in order to cross-compile ActionScript that uses the Flash Runtime API to JavaScript:

  • frameworks/javascript/jquery-1.5.1.js
  • frameworks/javascript/goog/base.js
  • frameworks/javascript/…
  • frameworks/libs/browser/browserglobal.swc
  • frameworks/libs/browser/browserglobal.abc
  • frameworks/libs/flash.swc
The Flex specific SWCs (Peter Flynn’s FlexJS) are:
  • frameworks/libs/framework.swc
  • frameworks/libs/mobilecomponents.swc
  • frameworks/libs/mobiletheme.swc
  • frameworks/libs/mx.swc
  • frameworks/libs/spark.swc
  • frameworks/libs/sparkskin.swc
Please note that those SWCs are very special SWCs created by FalconJS’s compc.jar. You can use them in “regular” Flash Builder projects and even compile SWCs and SWFs. But the resulting SWCs and SWFs created by “regular” Flex SDKs will never run in the Flash Player. Only the FalconJS versions of asc.jar, mxmlc.jar, and compc.jar are able to extract JavaScript from those SWCs listed above and create JavaScript applications.
In the following posts I will explain FlashRT and its two main components browserglobal.swc and flash.swc




8 Responses to Dreaming up a Flex JavaScript SDK

  1. Bayani Portier says:

    To me, the ideal would be to have a piece of harnes code sitting at the front of your deploy package that sniffs out which browser version you have, whether you have a valid version of flash or not, and then pass you on to the relevant compile.

    The business case for this is very strong in corporate environments. There are so many places that have IE7 still deployed in one department, but in the next, they have IE10, or want their employees to be able to browse on their tablets or other devices to get what they want.

    What if Flex would compile a specific version from your codebase for IE 7-9 using a SWF file, a version for IE 10, the flash version again for Firefox 3.5, the relevant HTML5/JS version for the relevant point version of Mozilla, Chrome etc?

    Code maintenance is no longer anywhere near as strong an issue, as you are using the same codebase, and everything else gets translated across to the native runtime. Done correctly, your core classes already do this with Flex for mobile and desktop, requiring you to only write the relevant interfaces for mobile, vs desktop/laptop screen.

    If Adobe can pull this one off, in my humble opinion, there would be nothing to match it, as your development costs would not exponentially increase with the various browsers in HTML5, and Flex would remain the industry standard as the way to develop enterprise Flex apps.

    11 points out of 10 for what you guys are doing with FalconJS. It warms the cockels of my heart to see that Adobe has superstars like yourselves on the payroll.

    • Bernd Paradies says:

      Hello Bayani,

      thanks for your encouraging words.
      I agree with you that it would be nice to emit glue code that offers SWF as the fallback for JS, or vice versa.
      But in a weird way, browsers have not been the biggest problem so far. It seems that using jQuery, Google’s base.js, and SVG 1.0 provide a good set of tools that can protect you from most of those browser incompatibilities. I have been successfully testing my cross-compiled JavaScript in Safari, Chrome, Firefox, and IE9. The only version that I can’t (and don’t want to) support is IE6. In addition, Safari on iPad 1 shows massive performance problems, which cannot be solved by using SWF as a fallback technology.

      In regards to corporate environments I am a little bit worried whether FlashRT and Peter Flynn’s FlexJS will cover all the important APIs that typical Flex solutions for enterprises use. FalconJS works astonishingly well for games. It will be up to the Apache Flex developer community to fill the holes…

      Best wishes,

      – Bernd

  2. Bayani Portier says:

    Hi Bernd,

    I personally think moving the Flex codebase to a true opensource strategy is the smartest move Adobe has made, and I believe everyone will be quite pleasantly surprised at the level of support that the Flex community will provide back to Adobe.

    As a developer myself, it takes less time and effort usually to fix root cause in the framework rather than to provide an inferior workaround, so there will be a lot of smart minds to leverage out there. Duck punching is rarely the ideal approach.

    It is wise to be worried, but nothing is ever eaten as hot as it’s cooked, and until the supporters of Javascript come out with a true OOP compliant and expressive language like AS3, I feel there is significant space for the language to be used.

    Best regards,

    – Bayani

  3. Zdenko says:

    Great Post, this is all I need. Flex is best IDE and adding support for JS would be revolution in RIA programing.

  4. Ryan Graff says:

    FalconJS is the logical evolution for UI development. Flex is the most intuitive, powerful and straight forward framework ever developed. AS3 is far more mature in structure than JS and therefore easier to leverage when reasonable complexity ensues. Browsers should just run AS3 natively, but not everyone can be as smashingly intelligent as us Flex/AIR/AS3 guys. 😉 (What the hell does Google think they’re looking for with DART, a.k.a. DASH, NATIVE AS3… DUH!!!!!)

    • Diego Marin says:

      Ryan, I agree with you. Maybe Adobe could develop a browser that runs AS3 natively, with support for HTML5 and CSS3″ and all new web stuff, of course.

  5. Raju Bitter says:

    Adobe already tried for ActionScript 3 to become the next web standard, as the new JavaScript. The problem is there’s not only Adobe interested in influencing the future of JavaScript, but companies like Microsoft, Apple, Google, Mozilla, and others.

    The disadvantage of ActionScript and the compiler approach is, that it creates a barrier between code changes and the ability to test the result. It effectively means that you always have to reload your app to test even small changes. Future versions of the Flash compiler (Falcon?) might enable some of that functionality.

    Check what ClojureScript does with the “browser-connected REPL” feature, and you’ll get what I mean (evaluate pieces of code in your editor/IDE and inject the new code base into the browser – without reloading the page/app). http://clojurescriptone.com/

    • Bernd Paradies says:

      Hello Raju,

      I didn’t know about ClojureScript’s REPL feature and I followed the link you provided. It seems I still have to install ClojureScript and a bunch of other stuff. Has anybody done some sort of “clojureFiddle” like http://jsfiddle.net did for JavaScript?

      – Bernd