incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <>
Subject Re: [ASJS] Some information on "templates"
Date Thu, 06 Dec 2012 23:01:04 GMT

I'm working on the compiler but I am far from anybody that knows about  
how to code javascript or get is from as to js right.

I am very good at the getting it done part when I know what needs to be done.

I can do fine when people are telling me what they need, I can make  
that happen. (in respect to cross compiling javascript)

How do you propose helping "design" the output and possibly  
integrating code you have already written?

Keep in mind you are talking to a relative child here in relation to  
your knowledge and understanding of how your framework works and how  
it could be applied.

I guess I'm asking for a little "hand holding" from you so we can get  
off on the right start and get things implemented.

Remember, your already part of the team with what you have given us so  
far regarding information and javascript, not to mention years of  
experience with all of this! :)


Quoting Frank Wienberg <>:

> On Thu, Dec 6, 2012 at 9:27 PM, Erik de Bruin <> 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<>
> .
> 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<> (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-

Michael Schmalle - Teoti Graphix, LLC

View raw message