Rather amazing work. Good job. However, what can be done about the massive difference in cpu utilization? The flash version used so little cpu that it wasn't noticeable, whereas the html5 version pegs a cpu at 40% minimum continuously, and on some charts 100% continuously - even when nothing is happening (non debug version too). Is that an artifact of this particular demo, an artifact of html5, or the way things would be for all applications using this approach?
-----Original Message----- From: Frank Wienberg [mailto:fr...@jangaroo.net] Sent: Saturday, January 19, 2013 9:08 PM To: flex-...@incubator.apache.org Subject: [FalconJx] AMD-based JavaScript code implemented in Jangaroo Hi folks, I have been rather quiet for a while, but that's because I have been busy implementing JavaScript code generation according to the Runtime prototype I posted some weeks ago. However, I started off implementing this in the Jangaroo compiler, not in Falcon. I am far quicker implementing this in the context I know, it would have taken me much longer getting started with Falcon first. So of course now I hope that you guys help me porting this solution to FalconJx... 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-
