Hi Frank,
I will try to take a look, but right now my priorities are post-graduation
tasks, the 4.9 release and getting the current FalconJS code to spit out
the
Base.js format for both MXML and AS. Also, I'm theoretically off duty next
week, so I won't be poking at this stuff full-time.
Hopefully we can pick this up again in the new year.
-Alex
On 12/20/12 9:30 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
Hi folks,
as mentioned in another thread, I have been working on a new JavaScript
"runtime", which is what I call the way the generated JavaScript code
looks
and works like. While this thread's title has [FalconJx] in it, there is
no
reason the proposal could not be used for FalconJS, too, but I understood
that for now, using Google Closure is a given.
I had the following design goals:
- Support ActionScript 3's "differentiator" features: private members,
interfaces + is/as, lazy class initialization, method binding,
getter/setter functions
- work in IE < 9 (except for getter/setter functions)
- Produce debuggable JavaScript code that can also be optimized for
deployment. The debuggable code should be very similar to the original
ActionScript source code for every line containing executable code
- Dependency management: load/bundle only the needed classes. Every
compilation unit to debug should load as a separate request
- Minimal to no runtime overhead, even in debug mode
- Support trace()
I took the following design decisions:
- For private members, a mix of JavaScript lexical scope and field
renaming like in Jangaroo is used
- To implement an efficient "is" operator, all interfaces a class
implements are determined once for the class. I use a prototype chain
to
inherit the interfaces implemented by the super class
- Lazy class initialization uses a very efficient technique refined by
Olaf Kummer: Wherever a constructor or non-private static member is
called,
the "self-destructing" class initialization function is checked for
existence and, if still existing, called ("guarded" call)
- Method binding is again borrowed from the Jangaroo Runtime: the
bound
function is "cached" at the object under a different but unique name
so
that it keeps its identity. This is important e.g. to be able to
remove
event listeners
- Getter/setter functions map to Object.defineProperty("...", { get:
..., set: ...}), thus no support in IE < 9
- To make everything else work in IE < 9, I use polyfills for
ECMAScript
5 Object, Array and Function API
- For keeping generated code in separate JS files, expressing
dependencies between these files, loading them separately at runtime
and
linking them statically into a single JavaScript file, I chose to use
Asynchronous Module Definitions (AMD) and RequireJS (version 2.1.2)
as the
concrete implementation of AMD. AMD is preferred over CommonJS
because it
better fits web applications, as e.g. argued here:
http://blog.millermedeiros.com/amd-is-better-for-the-web-than-commonjs-modules
/To
link and optimize the application, RequireJS provides an optimizer
tool
simply called "r.js".
- To conditionally load polyfills (for IE < 9), I use the "shim"
RequireJS plugin
- To achieve minimal runtime overhead, I only use helper functions to
define the class structure once (defineClass and defineInterface). As
soon
as the complete application structure is set up, all code executed is
inlined
- Since all modern browsers seem to support a "console" object with a
"log" method, trace() is simply implemented to check for the
existence of
console.log() by trial-and-error (try... catch). It then
String-converts
and concatenates all its arguments like its ActionScript sibling
*About the Example*
To specify how I think FalconJx-generated JavaScript output should look
like, I created an ActionScript example, consisting of two classes and
three interfaces. Every language feature supported by the new runtime
format gives an appearance in the code (well, I didn't add a private
static
method, because it works like a private method, only simpler).
The whole thing is a public GitHub project at
https://github.com/fwienber/as-js-runtime-prototype.
To download all files in one go as a zip or tar.gz, please use the tag
page: https://github.com/fwienber/as-js-runtime-prototype/tags.
A live demo is available on the corresponding GitHub pages at
http://fwienber.github.com/as-js-runtime-prototype/index.html
From there, you can reach all ActionScript example sources and the
proposed
JavaScript equivalent (so far, hand-coded :-)).
To see the example in action, use the three bottom links which start the
same application in three flavors:
- debug: Each JS file corresponding to an AS class or interface and
the
main bootstrap file is loaded with a single request. This gives you a
nice
1:1 mapping of source to output in the JavaScript debugger.
Additionally,
there are some "infrastructure" files: require.js itself, the
RequireJS
plugin "shim" (shim.js, shims.js), my AS3 runtime helpers
defineClass.js
and defineInterface.js, and a couple of built-in AS3 functions (bind,
as,
is, trace). If loading in IE < 9, the shim plugin loads several ES5
polyfills.
- linked: The whole application is merged into one JS file using the
RequireJS optimizer "r.js" without optimizations. Thus you only have
two
requests: require.js and hello-worls-all.js are loaded. In IE < 9, the
polyfills are still loaded one-by-one (I didn't bother to optimize
this
case, but of course, it can be done).
- minified: Same as "linked", only that require.js and
hellow-world-all.js are minified by Uglify2. This can easily be
achieved
using "r.js" with the parameter optimize=uglify2.
For the demo, I redirected trace() from the JavaScript console (backed-up
in trace-console.js) to the DOM, so that you can see the log messages
directly.
Just look into the code and observe how it works in Firebug or any other
JavaScript debugger of your choice, and let me know if anything is
unclear,
missing or if you need more reasoning for the design decisions taken.
I know there are still several issues to be fleshed out (e.g. interaction
with "native" JavaScript or package-scope variables, just to name two),
but
I think the current state is a solid core of how a modern, efficient,
self-contained, extensive and still concise JavaScript runtime format for
Apache Flex could look like.
Please tell me what you think!
Have fun,
-Frank-
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
