Frank,
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! :)
Mike
Quoting Frank Wienberg <fr...@jangaroo.net>:
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-
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
