I'm about 80% finished implementing all the AS3 language features I started
documenting in the Flex Wiki and already have a demo of a large
application, namely the Open Flash Charts demo, recompiled with the new AMD
approach.
Background on the demo:
Open Flash Chart 2 <http://teethgrinder.co.uk/open-flash-chart-2/> is a pure
ActionScript 3
project<http://sourceforge.net/projects/openflashchart/files/open-flash-chart/Version%202%20Lug%20Wyrm%20Charmer/>,
and I only had to make very few changes to the original AS3 code to make
the JavaScript version generated by the Jangaroo compiler work in the
browser, without a Flash plugin. This has been working with Jangaroo 1 and
2, and now I got it to run with the new runtime format proposed for
FalconJx.
The demo comes in two flavors:
The "production" version <http://jangaron.net/ofc5/data-files/joo.html>,
where the whole application is a minified single JS file of about 380 kb
(unzipped, the original SWF has 320 kb, and that is zipped and of course
does not contain the Flash classes, because they come with the
FlashPlayer!):
*http://jangaron.net/ofc5/data-files/joo.html*
Or load the "debug"
version<http://jangaron.net/ofc5/data-files/joo.html#joo.debug>,
where the JS equivalent of every AS class is loaded as a single request,
simply by adding hash joo.debug to the URL:
*http://jangaron.net/ofc5/data-files/joo.html#joo.debug*
This demonstrates the real benefit of the AMD approach: RequireJS is
capable of loading all needed scripts one by one (debug mode) as well as
optimize them into a single JS file for production. It can use Uglify,
Uglify2 or Google Closure for minification.
Loading every AS class as a single request is still astonishingly fast,
especially when using local deployment, which is what you usually do for
debugging. Note that the demo uses over 200 classes.
Have a look at the generated JavaScript, and you'll see that Jangaroo keeps
the original ActionScript code either as comment (if there is no JavaScript
counterpart, like for "package", "class", type annotations), or as
executable code in the exact line where the original AS code was. That
means if you want to debug say line 20 of AS class "Foo", you open script
"Foo.js" in the JavaScript debugger and find the code and set the
breakpoint in that same line: 20. This is a special Jangaroo feature which
we do not necessarily need to implement for FalconJx. However, I still
think it is a good feature, and since it does not slow down the optimized
version, why not implement it for FalconJx, too?
What I think we do need in any case is the ability to load AS classes by
single requests, as otherwise they are really hard to find when debugging
in the browser. And this is what you get for free when using RequireJS. In
Alex' prototype, the only way to achieve this behavior was to list all
needed single class scripts in the HTML (see FlexJS Wiki page). Of course,
such HTML could be generated, but I think RequireJS' approach is more
elegant.
Another thing you can see in the Open Flash Chart demo is how I implemented
static code execution. ActionScript executes all static code of the whole
"compilation unit" the first time its "primary declaration" (usually a
class) is accessed.
Consequently, not (only) an ActionScript class, but an ActionScript
"compilation unit" is put into a JavaScript AMD module definition. Thus,
the module's value is not the class itself, but a compilation unit
containing the class. I use the property "_" for the class or any other
primary declaration, which in AS3 can also be a function, variable or
constant. The static code of the compilation unit is *not* executed when it
is *loaded*, but when the "_" property is *accessed* for the first time.
(Because code has to be loaded asynchronously in the browser, we cannot
load the module when it is accessed synchronously, but have to load all
static dependencies in advance.) This is equivalent to the original AS3
behavior, and only introduces the minimal overhead of accessing Foo._
instead of just Foo.
If you want to play with the new Jangaroo compiler to see what JavaScript
output is generated for your ActionScript input, the simplest way is as
follows.
You need to have Java, Git and Maven installed and properly set up.
Clone the jangaroo-tools repository and switch to branch jangaroo-3:
git clone git://github.com/CoreMedia/jangaroo-tools.git
git checkout jangaroo-3
Then run the integration tests via Maven:
cd jangaroo-tools
mvn install -pl :jangaroo-compiler-itests -am
This should result in a BUILD SUCCESS.
The jangaroo-compiler-itests module is under
jangaroo/jangaroo-compiler-itests:
cd jangaroo/jangaroo-compiler-itests
For the intergration tests, all *.as files under src/test/joo/ are compiled
to target/temp/joo/classes/, respecting their package sub-directory. So if
you add an *.as file under the src/test/joo/ directory, the corresponding
*.js file will appear under the target/temp/joo/classes/ directory after
the following Maven command:
mvn test-compile
Note that you cannot use Flash API here (will result in compile error, as
classes are not found), only basic classes like String, Array, and built-in
functions like trace().
Another good news is that my employer signed the CCLA, and it has been
confirmed by Craig, so now I am all set to contribute Jangaroo code to
Apache Flex!
The code that generates the new JavaScript runtime format is in
jangaroo-tools
on the "jangaroo-3"
branch<https://github.com/CoreMedia/jangaroo-tools/commits/jangaroo-3>
(see
above), especially class
JSCodeGenerator<https://github.com/CoreMedia/jangaroo-tools/blob/jangaroo-3/jangaroo/jangaroo-compiler/src/main/java/net/jangaroo/jooc/backend/JsCodeGenerator.java>(Michael
Sch. knows this already!) is interesting for porting code to
FalconJx and has changed substantially for Jangaroo 3 / AMD runtime format.
I am also working on another demo, which is written in AS3 and MXML (!),
but instead of Flex components, uses "native" Ext JS JavaScript components
through an AS API. It does not use the Jangaroo Flash library
re-implementation (JooFlash), so this sounds similar to Alex' approach to
not use the display list to render MXML components. More update on this to
follow.
Would really be great if we could consolidate our solutions!
Can't wait for your feedback,
-Frank-
