On Thu, Dec 6, 2012 at 9:27 PM, Erik de Bruin <e...@ixsoftware.nl> wrote:
> No framework classes are cross compiled. Only project AS files are run
> through FalconJS before they are combined with the JS framework through the
> Closure Builder.
>
In Jangaroo, we even wrote most of the runtime classes in ActionScript and
cross-compiled them. Only very basic bootstrap code is written in "native"
JavaScript (on the history of this approach, see below).
> The AS framework is there to allow for project development in Flash
> Builder. Our job as developers is to provide both sides of the fence (AS
> and JS framework) with matching functionality so the compiled project JS
> files will behave the same in a browser as their AS equivalent does in the
> Flash Player.
>
Exactly. And it seems the Jangaroo Runtime already got quite close to that
goal. See the examples on our home page ("Applications"), which were all
realized using the original ActionScript code.
Some proposed solutions here remind me of our first approach when we
started with Jangaroo (or more precisely its predecessor "JSC" back in
2004). We tried to let the compiler generate all needed code and only put
some global helper functions in a JS file.
When simulating more and more ActionScript language features, this approach
resulted in quite unreadable, repetitive and inefficient code being
generated. So our second iteration was to let the compiler generate
JavaScript code that can be seen as a domain specific language (DSL) to
declare ActionScript classes, which is then "interpreted" by a JavaScript
"Runtime". Later, we even ported this Runtime to ActionScript, with only a
very basic DSL-interpreter remaining in JavaScript for bootstrapping the
fully-featured version. For Jangaroo Runtime source code, see below this
github
directory<https://github.com/CoreMedia/jangaroo-tools/tree/master/jangaroo/jangaroo-runtime/src/main>
.
You may think now that this approach is inefficient ("interpreted? Oh no!")
or overly complex.
Regarding efficiency: Only the class structure is "interpreted" at runtime,
the JavaScript code that runs after the initial "preparation"
(joo.classLoader.prepare(...)) of a class contains almost no overhead and
thus is very efficient. Regarding minifying the code: Currently, GCC can
only be used with SIMPLE_OPTIMIZATIONS with Jangaroo-generated code, since
the needed annotations are missing for ADVANCED_OPTIMIZATIONS, but it
should be possible to add them to the current code layout.
Regarding complexity: Yes, you can use a very straight-forward approach,
but you'll run into trouble when trying to implement some of the more
advanced ActionScript language features, which *are* complex, and which are
all supported by Jangaroo:
* executing static code of classes at the right time (lazy class
initialization)
* private members
* efficient super calls
* properties with get/set functions that also work in older browsers (save
IE)
* method binding (correct "this")
* "is" and "as" (interfaces at runtime)
* annotations
* reflection
For more details, I'd again like to point you at my blog about ActionScript
language features simulated in
JavaScript<http://blog.jangaroo.net/search/label/ActionScript> (layout
glitch in blog style when showing posts for a certain tag, please scroll
down!).
I think there is only one aspect implemented in the Jangaroo Runtime that I
wouldn't add today, and that is dynamic class loading based on
runtime-dependencies for debugging purposes. In the meantime, there are
libraries like RequireJS and obviously also Google Closure that take care
of that and that should be reused. I prototyped using RequireJS for
Jangaroo but did not finish that breaking change for Jangaroo 2.
Also, the Runtime can be simplified quite a lot if we rely on ECMAScript 5
and polyfills (and maybe ditch IE8 support, see other thread).
As said before, I am willing to help designing Apache Flex' JS output based
on my experience with the Jangaroo Runtime. Of course, reusing some of the
code is also possible (it has a friendly Apache 2 license).
-Frank-
