[FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

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-

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

Hi Mike,

On Thu, Dec 20, 2012 at 7:23 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:

> I'm probably in the position of, "Show me what you want to generate based
> on the semantics involved and I will generate it" mode.


that was exactly what my proposal was aiming at! It sounded like once you
are done with generating ActionScript from ActionScript ;-), you'll need a
target JavaScript format to generate.
One source for that is the AS->JS map in the Wiki that Erik created and I
commented.
But the source for the overall class structure must be something else. Like
in Erik's proposal for using "goog", I now came up with a concrete example
of what the JavaScript output for a certain (prototypical) ActionScript
input should look like. I just thought that example help more than a
"format spec". So by looking at
http://fwienber.github.com/as-js-runtime-prototype/index.html, you can
directly compare ActionScript source showcasing all relevant language
feature and the corresponding JavaScript output. You can safely ignore all
the require.js, shim.js, defineClass/Interface.js stuff. Just concentrate
on A.as versus A.js, B.as versus B.js, I.as versus I.js etc.

That said, it would be great if you could make the FalconJx prototype spit
out JS code like the one on my example!

Concerning using "goog" or not, please stand by for my response to Erik's
post.

Greetings
-Frank-

RE: [FalconJx] New JavaScript runtime format prototype

[Kessler CTR Mark J <ma...@usmc.mil>]

Awesome lol

-----Original Message-----
From: omuppi1@gmail.com [mailto:omuppi1@gmail.com] On Behalf Of Om
Sent: Friday, December 21, 2012 3:30
To: flex-dev@incubator.apache.org
Subject: Re: [FalconJx] New JavaScript runtime format prototype

Obligatory xkcd reference ;-)

http://xkcd.com/386/

Re: [FalconJx] New JavaScript runtime format prototype

[Erik de Bruin <er...@ixsoftware.nl>]

:-)

Om, Frank and I are on GMT +1, so it wasn't really that bad... you, on
the other hand are missing out on some well deserved sleep time; make
sure to catch some, but only after you've fixed the internet, of
course ;-)

EdB


On Fri, Dec 21, 2012 at 9:33 AM, Frank Wienberg <fr...@jangaroo.net> wrote:
> lol, yes, that's how it was like yesterday (or rather: today), but now it's
> 9:30 am here.
>
>
> On Fri, Dec 21, 2012 at 9:30 AM, Om <bi...@gmail.com> wrote:
>
>> Obligatory xkcd reference ;-)
>>
>> http://xkcd.com/386/
>> On Dec 21, 2012 12:26 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>> > Frank,
>> >
>> > I was writing a very long and detailed reply to your very long and
>> > detailed reply to my ... (ad infinitum, it seems), debunking or
>> > countering most of your claims, when I realised that I don't want to
>> > spend my time that way. I call for a truce while we investigate the
>> > merits and pitfalls of both approaches in real life examples and
>> > against a realistic work flow.
>> >
>> > I'm going to help Mike with FalconJx so we have something to work
>> > with. I'm going to continue to investigate the best way forward after
>> > we have the language-translation-thing done and need to figure out
>> > which approach is best for creating the AS and JS UI frameworks. That
>> > might be Alex's FlexJS, but it also might be something completely
>> > different.
>> >
>> > For now, it's Xmas time! Happy partying :-)
>> >
>> > EdB
>> >
>> >
>> >
>> > --
>> > Ix Multimedia Software
>> >
>> > Jan Luykenstraat 27
>> > 3521 VB Utrecht
>> >
>> > T. 06-51952295
>> > I. www.ixsoftware.nl
>> >
>>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

lol, yes, that's how it was like yesterday (or rather: today), but now it's
9:30 am here.


On Fri, Dec 21, 2012 at 9:30 AM, Om <bi...@gmail.com> wrote:

> Obligatory xkcd reference ;-)
>
> http://xkcd.com/386/
> On Dec 21, 2012 12:26 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
> > Frank,
> >
> > I was writing a very long and detailed reply to your very long and
> > detailed reply to my ... (ad infinitum, it seems), debunking or
> > countering most of your claims, when I realised that I don't want to
> > spend my time that way. I call for a truce while we investigate the
> > merits and pitfalls of both approaches in real life examples and
> > against a realistic work flow.
> >
> > I'm going to help Mike with FalconJx so we have something to work
> > with. I'm going to continue to investigate the best way forward after
> > we have the language-translation-thing done and need to figure out
> > which approach is best for creating the AS and JS UI frameworks. That
> > might be Alex's FlexJS, but it also might be something completely
> > different.
> >
> > For now, it's Xmas time! Happy partying :-)
> >
> > EdB
> >
> >
> >
> > --
> > Ix Multimedia Software
> >
> > Jan Luykenstraat 27
> > 3521 VB Utrecht
> >
> > T. 06-51952295
> > I. www.ixsoftware.nl
> >
>

Re: [FalconJx] New JavaScript runtime format prototype

[Om <bi...@gmail.com>]

Obligatory xkcd reference ;-)

http://xkcd.com/386/
On Dec 21, 2012 12:26 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:

> Frank,
>
> I was writing a very long and detailed reply to your very long and
> detailed reply to my ... (ad infinitum, it seems), debunking or
> countering most of your claims, when I realised that I don't want to
> spend my time that way. I call for a truce while we investigate the
> merits and pitfalls of both approaches in real life examples and
> against a realistic work flow.
>
> I'm going to help Mike with FalconJx so we have something to work
> with. I'm going to continue to investigate the best way forward after
> we have the language-translation-thing done and need to figure out
> which approach is best for creating the AS and JS UI frameworks. That
> might be Alex's FlexJS, but it also might be something completely
> different.
>
> For now, it's Xmas time! Happy partying :-)
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

Re: [FalconJx] New JavaScript runtime format prototype

[Erik de Bruin <er...@ixsoftware.nl>]

Frank,

I was writing a very long and detailed reply to your very long and
detailed reply to my ... (ad infinitum, it seems), debunking or
countering most of your claims, when I realised that I don't want to
spend my time that way. I call for a truce while we investigate the
merits and pitfalls of both approaches in real life examples and
against a realistic work flow.

I'm going to help Mike with FalconJx so we have something to work
with. I'm going to continue to investigate the best way forward after
we have the language-translation-thing done and need to figure out
which approach is best for creating the AS and JS UI frameworks. That
might be Alex's FlexJS, but it also might be something completely
different.

For now, it's Xmas time! Happy partying :-)

EdB



--
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

On Fri, Dec 21, 2012 at 12:20 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:

> > This the overall impression I have with the GCC approach: it introduced
> > complexity only to optimize it later on.
> > I think we better avoid complexity in the first place!
>
> Well, it introduces "complexity" in order to facilitate BETTER
> optimisation later on. So, by avoiding that "complexity" - simply
> because we like "simplicity" - we'd end up with an inferior product.
>

That's not what I was saying. I said if we can avoid complexity in the
first place, we should do so instead of introducing overhead and then
optimizing it away.
E.g. for a super call, what could be more simple *and* efficient than a
direct method invocation to the super method? How can GCC possibly optimize
that call (other than by inlining the super function, which is another
story)? The only thing it can optimize is its own bloated implementation of
goog.base().
Don't get me wrong, GCC is doing a great job in optimizing JavaScript code,
but at the same time it provides a domain-specific language for some
constructs where we don't need it, as we talk about generated, not
hand-written JS code. All the advantages of goog.base() mentioned in this
essay <http://bolinfest.com/essays/googbase.html> do not apply for us.
Quoting from that essay:

Although at first this may seem like a small victory, consider the
> advantages:




   - Fully qualified class names in the Closure Library are often long, so
   it is considerably easier to type goog.base(this, 'disposeInternal') than
   it is to type goog.ui.Component.superClass_.disposeInternal.call(this).
   - When renaming a class, superclass method invocations do not need to be
   updated if goog.base()is used.
   - When changing the superclass, the call to the superclass constructor
   function does not need to be updated if goog.base() is used (unless the
   arguments to the new constructor function are different).

Using AMD, you never have fully qualified names in your code, but class
references are assigned to local variables (define-callback-parameters).
Having generated code, any changes in the AS3 source code are reflected in
the generated JS code automatically.

The other argument is that GCC's idea of a concept does not necessarily
match ActionScript idea of the same concept. For example, the way GCC
implements class inheritance with JavaScript does not take into account
that classes may need to be initialized so that their static (initializer)
code is executed. If we really want to resemble ActionScript semantics, we
have to add such features, anyway, so we end up with a mix of Closure
concepts and our own.


> > For goog.provide and goog.require, RequireJS provides alternatives that
> > better fit our needs: asynchronous module loading much better reflects
> the
> > nature of script loading in the browser. Synchronous require calls were
> > made for Node.js or other environments that allow to load scripts
> > synchronously. RequireJS concentrates exactly on that task and does
> nothing
> > else.
>
> The point of the Closure Builder is that there are no modules. It's
> all one file (and a small one at that). There is no need to manage the
> loading of any modules (with the added overhead required to make it
> work) at all.
>

If you don't want any dynamic module loading, James Burke also provides a
minimal AMD implementation for that use case:
https://github.com/jrburke/requirejs/wiki/AMD-API-Shims
But I see separate module loading as a feature, not a problem. I never
liked the monolithic approach of GWT (Flash is not much better, but at
least it supports SWCs).
Why do you think it is most efficient to load all code at once? What about
all the code that is not always needed, e.g. browser-specific code (like
the polyfills in my prototype), or code that is only needed if the users
invokes a rare expert feature? What about loading common libraries from a
CDN, so that chances are that the users already have them in their browser
cache? For example, if we implemented the core Flash API which is usually
part of FlashPlayer, it would not make sense to statically link it into
each and every FlashJS application.
Another similar example are large modular applications of which only some
modules are updated. If you concat all modules to one big JS file, every
user has to download the new version of the big file (= the whole
application) instead of the updated code only.
Last argument is that modern browsers are quite good at loading static
resources in parallel requests, which is effectively prevented by serving
only one big file.
Ah, one more: the runtime overhead added by RequireJS to make module
loading happen is 15k (minimized, not even gzipped). C'mon, 15k.


>
> > goog.inherits and goog.base are IMHO not needed at all. In JS code
> > generated from ActionScript, what goog.base does can be expressed by a
> > direct function call (see my prototype). goog.inherits is replaced by my
> > defineClass() utility, which consists of just 60 lines of code and
> supports
> > many more AS3 language features than just inheritance. I also had an
> > alternative "VanillaJS" version that did not even use a helper method for
> > inheritance (since it is so easy using ES5 API), but adding the other
> > language feature, I found that this introduced too much repetitive,
> boiler
> > plate code.
>
> Again: personal preference, but I prefer the readability and
> consistency that comes from using "goog" for this. And I don't see
> (other than stepping into, instead of over the lines with "goog") any
> real difference in using one utility method over another. Let's
> revisit this when I have had the chance to mock up some more code so
> we can compare "intermediate" JS formats.
>

My take is to use no utility method at all for super calls (VanillaJS).


>
> > One thing I'd like to know: can you use the Closure Tools *completely
> > without* using the goog library in your JS code and still achieve
> > ADVANCED_OPTIMIZATIONS? If not, I think that is exactly where the
> > vendor-lock-in comes into play.
>
> Yes.
>

Then I'd like to create a variant of my prototype using Closure instead of
RequireJS to directly compare the two approaches. Would you help out
because of my lacking GCC / goog knowledge?



>
> > See above. When talking about 1500 lines of code, I don't worry about
> code
> > size, but about complexity that shines through during debugging.
>
> Step over?
>

Yes, but what if you want to step into the super call? goog.base() hides
the actual call to the super method deep in its implementation code (inside
a for-loop!).
And don't forget the second argument, stack trace. Unlike built-in
functions like Function#call() and #apply(), goog.base() is visible in a
stack trace, so multi-level super calls look like so:

  A.foo()
  goog.base()
  B.foo()
  goog.base()
  C.foo()
...

Again, unnecessary bloat.


>
> >> *tool/vendor dependency:* The Google Closure Tools are Open Source,
> >> available under the Apache License 2.0.
> >>
> >
> > I know that. Still, it is Google's own interpretation of modules,
> > inheritance, ... for which there are at least partially standards in
> > JavaScript (ECMAScript 5, AMD).
>
> Well, all code is someones interpretation of a requirement. And I
> think that for suppliers of frameworks (like Google and ourselves),
> that "partially" that you so casually throw in there really makes a
> difference. I'm sure no-one with a corporate client is willing to
> ditch IE 8 support "just yet". As long as Windows XP still holds at
> least a third of the total OS market share, that browser isn't going
> anywhere soon.
>

That's why I only used ES5 features in the prototype that can be
"polyfilled" in IE < 9, except for getter/setter functions. And if Falcon
can distinguish a getter access from a property access (someone asked that
around here, just can't remember who), we could even rewrite these to
become ES3 compatible (goog also cannot magically implement getters/setters
in IE < 9).
I hope you agree that using Object.create() is more future-prove and less
vendor-specific than goog.inherit().
I guess you are right that AMD is more of a standard than goog.require() is
not such a strong point. The more important argument is that asynchronous
require calls better fit the Web (in contrast to a server environment like
Node.js where you can load scripts synchronously) and thus enables dynamic
module loading, see discussion above.


>
> > To make the UI framework run cross-browser, I have no objections against
> > using an existing JavaScript framework. But this is my point when talking
> > about "separations of concerns". I wouldn't hard-wire the pure language
> > translation to "goog" just because it is a good base for a cross browser
> UI
> > framework. And any UI framework should be compatible with VanillaJS!
>
> A difference in approach, I guess. You focus on a single requirement
> and select the best tool for that, ending up with lots of tools when
> the number of requirements increase. I tend to look at the larger
> picture and select a tool that is best for the overall job... And
> knowing the kind of products Google has produced and maintained -
> using large teams, many different coders on one project - with that
> tool, I'm pretty confident it will serve this project very well
> indeed.
>

Yes, that's right, different approach. I rather get a bad feeling when one
tool want to do too many things, as I think there will always be some
strong parts and some weaker parts, and having a "swiss army knife"
solution, you probably can't mix-and-match in another tool so easily. And I
like making decisions when I feel ready for them, so already deciding which
UI framework to use when trying to simulate a language feels awkward for me.
I am not familiar with the goog library and haven't (knowingly) seen a web
UI built with it. At CoreMedia, we have been using Ext JS for quite a while
and I'm still impressed by the results of using their framework. With
Sencha Touch, they are also strong in the mobile market.



>
> > What makes a difference to me is that to link with RequireJS, you do not
> > have use a RequireJS-specific syntax, but an AMD-specific one. They
> > separate syntax and implementation, which GCC apparently doesn't.
>
> GCC does not need specific syntax. It offers you the ability to add
> annotation (but doesn't require it!) in order to help it do a better
> job, but it will do an excellent job on vanilla JS as well.
>

But how do you specify module dependencies then? Unfortunately, this is one
of the (few) things that is not possible in VanillaJS, and I think that AMD
is the "most vanilla" JavaScript syntax for modules one can imagine.
When we implemented the Jangaroo Runtime, there was no AMD / CommonJS etc.
back then, so we created our own dependency manager and script loader. I
estimate this to be 50% of the whole runtime code, and I'm glad the new
runtime will no longer have to care about this problem. The only question
for me to discuss is whether to use synchronous require() (like the goog
one) or asynchronous (like AMD / RequireJS), and I guess you know my
opinion on that by now.
The problem I have with synchronous require() is that for a Web
application, it is rather a compiler/linker instruction than a function
call. That's why I think AMD is closer to VanillaJS. To really load a
script synchronously in the browser, you'd have to do a synchronous XHR
(evil!) and then eval() the result (more evil!). Btw. this is what Ext JS
4's require mechanism actually does if you do not specify a dependency in
an AMD fashion in advance, so it supports both synchronous and asynchronous
dependencies during development.



>
> > Yes, that's my point. I argue that it does *too much* in one tool, so we
> > don't have fine-grained control over the code generation process.
>
> Actually, I'm talking about the complete set of Closure Tools: JSDoc
> annotations, Library, Compiler and Builder. That's 4 tools tailored to
> work together, but at least the Library and the Compiler are
> separately and independently usable. However, used together they
> complement each other in a way no other combination of tools I know of
> does.
>

So what concretely is missing in the tool combination (RequireJS +
shim-plugin) that I propose?



>
> > Yes, but the code is still generated (even if only in-memory) and parsed,
> > which is an unnecessary overhead in any case.
>
> So you suggest we build our own optimiser/minifier (not an easy task,
> it seems to me) and loose the ability to output "intermediate" code
> just because we want to shave of (maybe, at most) a couple of seconds
> from the compile time?
>
>
No. I suggest that eventually, the Falcon compiler has compiler switches
that influence whether debuggable or optimized JavaScript code is generated
(these may even be fine-grained to enable/disable certain optimizations).
Using your favorite build tool, you could then set up the compiler to run
twice, producing both types of output, if you like.
And concerning the complexity, I think that actually, our starting point is
much better for optimization than Closure's, as we already have a complete
model of all relevant code during compilation, and will for example need to
have means to map ActionScript identifiers to different
JavaScript identifiers, anyway. Without any need for annotations, we also
know things about the code like "this is a static ActionScript method, so
it will never disappear, be re-assigned or overwritten -- we can just
inline the code!".


> > I'm talking about a new feature available so far in Chrome only to let
> the
> > browser debugger map the JavaScript code to the original source code, see
> > for example
> > http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
> > If this feature was present in all major browsers, there would no longer
> be
> > a need for a debuggable JavaScript code format if we generated source
> maps.
> > Firefox has published an implementation plan, but it may take a while. IE
> > 10 will probably follow, now that Microsoft pushes TypeScript.
>
> Waiting for a non-standard feature to be implemented across browser
> and JS VMs might take "a while" :-P
>

I know, that's why I keep on evangelizing that we have to have a mode in
which we generate debuggable JavaScript code!

Thanks, Erik, it is really illuminating discussing these things with you!

Greetings,
-Frank-


>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

On Fri, Dec 21, 2012 at 12:29 AM, Chema Balsas <jb...@gmail.com> wrote:

> One thing I'm not sure has been mentioned here is localization support.
> It's not a requirement for the pure AS->JS translation, but I have the
> sense it's quite important for Flex.
>
> I think the Closure Compiler offers Templates and some kind of
> internationalization automation, which could come in handy. Otherwise,
> we'll probably need to use another templating engine or develop our own.
>

My take is that localization should be compatible to how it is done in
"real" Flex<http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf6119c-7ffd.html>
rather
than how Closure does it.
Closure seems to me like the swiss army knife that can be used for
everything but may not fit into your pocket.
For implementing the actual resource bundle loading, RequireJS also offers
a mechanism <http://requirejs.org/docs/api.html#i18n>.

-Frank-

Re: [FalconJx] New JavaScript runtime format prototype

[Chema Balsas <jb...@gmail.com>]

One thing I'm not sure has been mentioned here is localization support.
It's not a requirement for the pure AS->JS translation, but I have the
sense it's quite important for Flex.

I think the Closure Compiler offers Templates and some kind of
internationalization automation, which could come in handy. Otherwise,
we'll probably need to use another templating engine or develop our own.

Not rooting for anyone here, by the way, just throwing some more concerns
into the mix ;)

Cheers,
Chema

2012/12/21 Erik de Bruin <er...@ixsoftware.nl>

> > This the overall impression I have with the GCC approach: it introduced
> > complexity only to optimize it later on.
> > I think we better avoid complexity in the first place!
>
> Well, it introduces "complexity" in order to facilitate BETTER
> optimisation later on. So, by avoiding that "complexity" - simply
> because we like "simplicity" - we'd end up with an inferior product.
>
> > For goog.provide and goog.require, RequireJS provides alternatives that
> > better fit our needs: asynchronous module loading much better reflects
> the
> > nature of script loading in the browser. Synchronous require calls were
> > made for Node.js or other environments that allow to load scripts
> > synchronously. RequireJS concentrates exactly on that task and does
> nothing
> > else.
>
> The point of the Closure Builder is that there are no modules. It's
> all one file (and a small one at that). There is no need to manage the
> loading of any modules (with the added overhead required to make it
> work) at all.
>
> > goog.inherits and goog.base are IMHO not needed at all. In JS code
> > generated from ActionScript, what goog.base does can be expressed by a
> > direct function call (see my prototype). goog.inherits is replaced by my
> > defineClass() utility, which consists of just 60 lines of code and
> supports
> > many more AS3 language features than just inheritance. I also had an
> > alternative "VanillaJS" version that did not even use a helper method for
> > inheritance (since it is so easy using ES5 API), but adding the other
> > language feature, I found that this introduced too much repetitive,
> boiler
> > plate code.
>
> Again: personal preference, but I prefer the readability and
> consistency that comes from using "goog" for this. And I don't see
> (other than stepping into, instead of over the lines with "goog") any
> real difference in using one utility method over another. Let's
> revisit this when I have had the chance to mock up some more code so
> we can compare "intermediate" JS formats.
>
> > One thing I'd like to know: can you use the Closure Tools *completely
> > without* using the goog library in your JS code and still achieve
> > ADVANCED_OPTIMIZATIONS? If not, I think that is exactly where the
> > vendor-lock-in comes into play.
>
> Yes.
>
> > See above. When talking about 1500 lines of code, I don't worry about
> code
> > size, but about complexity that shines through during debugging.
>
> Step over?
>
> >> *tool/vendor dependency:* The Google Closure Tools are Open Source,
> >> available under the Apache License 2.0.
> >>
> >
> > I know that. Still, it is Google's own interpretation of modules,
> > inheritance, ... for which there are at least partially standards in
> > JavaScript (ECMAScript 5, AMD).
>
> Well, all code is someones interpretation of a requirement. And I
> think that for suppliers of frameworks (like Google and ourselves),
> that "partially" that you so casually throw in there really makes a
> difference. I'm sure no-one with a corporate client is willing to
> ditch IE 8 support "just yet". As long as Windows XP still holds at
> least a third of the total OS market share, that browser isn't going
> anywhere soon.
>
> > To make the UI framework run cross-browser, I have no objections against
> > using an existing JavaScript framework. But this is my point when talking
> > about "separations of concerns". I wouldn't hard-wire the pure language
> > translation to "goog" just because it is a good base for a cross browser
> UI
> > framework. And any UI framework should be compatible with VanillaJS!
>
> A difference in approach, I guess. You focus on a single requirement
> and select the best tool for that, ending up with lots of tools when
> the number of requirements increase. I tend to look at the larger
> picture and select a tool that is best for the overall job... And
> knowing the kind of products Google has produced and maintained -
> using large teams, many different coders on one project - with that
> tool, I'm pretty confident it will serve this project very well
> indeed.
>
> > What makes a difference to me is that to link with RequireJS, you do not
> > have use a RequireJS-specific syntax, but an AMD-specific one. They
> > separate syntax and implementation, which GCC apparently doesn't.
>
> GCC does not need specific syntax. It offers you the ability to add
> annotation (but doesn't require it!) in order to help it do a better
> job, but it will do an excellent job on vanilla JS as well.
>
> > Yes, that's my point. I argue that it does *too much* in one tool, so we
> > don't have fine-grained control over the code generation process.
>
> Actually, I'm talking about the complete set of Closure Tools: JSDoc
> annotations, Library, Compiler and Builder. That's 4 tools tailored to
> work together, but at least the Library and the Compiler are
> separately and independently usable. However, used together they
> complement each other in a way no other combination of tools I know of
> does.
>
> > Yes, but the code is still generated (even if only in-memory) and parsed,
> > which is an unnecessary overhead in any case.
>
> So you suggest we build our own optimiser/minifier (not an easy task,
> it seems to me) and loose the ability to output "intermediate" code
> just because we want to shave of (maybe, at most) a couple of seconds
> from the compile time?
>
> > I'm talking about a new feature available so far in Chrome only to let
> the
> > browser debugger map the JavaScript code to the original source code, see
> > for example
> > http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
> > If this feature was present in all major browsers, there would no longer
> be
> > a need for a debuggable JavaScript code format if we generated source
> maps.
> > Firefox has published an implementation plan, but it may take a while. IE
> > 10 will probably follow, now that Microsoft pushes TypeScript.
>
> Waiting for a non-standard feature to be implemented across browser
> and JS VMs might take "a while" :-P
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

Re: [FalconJx] New JavaScript runtime format prototype

[Erik de Bruin <er...@ixsoftware.nl>]

> This the overall impression I have with the GCC approach: it introduced
> complexity only to optimize it later on.
> I think we better avoid complexity in the first place!

Well, it introduces "complexity" in order to facilitate BETTER
optimisation later on. So, by avoiding that "complexity" - simply
because we like "simplicity" - we'd end up with an inferior product.

> For goog.provide and goog.require, RequireJS provides alternatives that
> better fit our needs: asynchronous module loading much better reflects the
> nature of script loading in the browser. Synchronous require calls were
> made for Node.js or other environments that allow to load scripts
> synchronously. RequireJS concentrates exactly on that task and does nothing
> else.

The point of the Closure Builder is that there are no modules. It's
all one file (and a small one at that). There is no need to manage the
loading of any modules (with the added overhead required to make it
work) at all.

> goog.inherits and goog.base are IMHO not needed at all. In JS code
> generated from ActionScript, what goog.base does can be expressed by a
> direct function call (see my prototype). goog.inherits is replaced by my
> defineClass() utility, which consists of just 60 lines of code and supports
> many more AS3 language features than just inheritance. I also had an
> alternative "VanillaJS" version that did not even use a helper method for
> inheritance (since it is so easy using ES5 API), but adding the other
> language feature, I found that this introduced too much repetitive, boiler
> plate code.

Again: personal preference, but I prefer the readability and
consistency that comes from using "goog" for this. And I don't see
(other than stepping into, instead of over the lines with "goog") any
real difference in using one utility method over another. Let's
revisit this when I have had the chance to mock up some more code so
we can compare "intermediate" JS formats.

> One thing I'd like to know: can you use the Closure Tools *completely
> without* using the goog library in your JS code and still achieve
> ADVANCED_OPTIMIZATIONS? If not, I think that is exactly where the
> vendor-lock-in comes into play.

Yes.

> See above. When talking about 1500 lines of code, I don't worry about code
> size, but about complexity that shines through during debugging.

Step over?

>> *tool/vendor dependency:* The Google Closure Tools are Open Source,
>> available under the Apache License 2.0.
>>
>
> I know that. Still, it is Google's own interpretation of modules,
> inheritance, ... for which there are at least partially standards in
> JavaScript (ECMAScript 5, AMD).

Well, all code is someones interpretation of a requirement. And I
think that for suppliers of frameworks (like Google and ourselves),
that "partially" that you so casually throw in there really makes a
difference. I'm sure no-one with a corporate client is willing to
ditch IE 8 support "just yet". As long as Windows XP still holds at
least a third of the total OS market share, that browser isn't going
anywhere soon.

> To make the UI framework run cross-browser, I have no objections against
> using an existing JavaScript framework. But this is my point when talking
> about "separations of concerns". I wouldn't hard-wire the pure language
> translation to "goog" just because it is a good base for a cross browser UI
> framework. And any UI framework should be compatible with VanillaJS!

A difference in approach, I guess. You focus on a single requirement
and select the best tool for that, ending up with lots of tools when
the number of requirements increase. I tend to look at the larger
picture and select a tool that is best for the overall job... And
knowing the kind of products Google has produced and maintained -
using large teams, many different coders on one project - with that
tool, I'm pretty confident it will serve this project very well
indeed.

> What makes a difference to me is that to link with RequireJS, you do not
> have use a RequireJS-specific syntax, but an AMD-specific one. They
> separate syntax and implementation, which GCC apparently doesn't.

GCC does not need specific syntax. It offers you the ability to add
annotation (but doesn't require it!) in order to help it do a better
job, but it will do an excellent job on vanilla JS as well.

> Yes, that's my point. I argue that it does *too much* in one tool, so we
> don't have fine-grained control over the code generation process.

Actually, I'm talking about the complete set of Closure Tools: JSDoc
annotations, Library, Compiler and Builder. That's 4 tools tailored to
work together, but at least the Library and the Compiler are
separately and independently usable. However, used together they
complement each other in a way no other combination of tools I know of
does.

> Yes, but the code is still generated (even if only in-memory) and parsed,
> which is an unnecessary overhead in any case.

So you suggest we build our own optimiser/minifier (not an easy task,
it seems to me) and loose the ability to output "intermediate" code
just because we want to shave of (maybe, at most) a couple of seconds
from the compile time?

> I'm talking about a new feature available so far in Chrome only to let the
> browser debugger map the JavaScript code to the original source code, see
> for example
> http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
> If this feature was present in all major browsers, there would no longer be
> a need for a debuggable JavaScript code format if we generated source maps.
> Firefox has published an implementation plan, but it may take a while. IE
> 10 will probably follow, now that Microsoft pushes TypeScript.

Waiting for a non-standard feature to be implemented across browser
and JS VMs might take "a while" :-P

EdB



--
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

On Thu, Dec 20, 2012 at 10:54 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:

> Excellent points! I see that we are closer in our goals and methods,
> but there is still 'some' misunderstanding about the tools we are
> proposing. I'll address your points and add my opinion/understanding
> where I think some clarification is needed.
>

Great, I agree we are "converging" and it is now just a matter of choosing
the "right" tools...


> - *waste:* In one short scentence: the Closure Builder part of the
> Tools takes care of this. Any (really!) code that is not actually used
> is NOT included in the output. So, if we use 'goog.base()' from
> 'base.js', ONLY the code needed to execute that method in the context
> we're using it in is included. All the rest is discarded. I'm not sure
> about the optimiser(s) you suggest offer the same functionality?
>

I think I understand the way the Closure Builder works. I was talking about
the non-optimized code, which I guess we would use for debugging.
When debugging an application, performance is not such an issue, but
runtime complexity that you see during debugging is!
So for example goog.base() -- during debugging -- executes a whole bunch of
code to find and call the super function, which you would have to step
through or which you would see in stack traces.
My approach prevents this overhead right from the beginning, so there is
even no need for such optimization!
This the overall impression I have with the GCC approach: it introduced
complexity only to optimize it later on.
I think we better avoid complexity in the first place!


>
> - *JavaScript readiness:* there's nothing to compare here, I'm afraid.
> I'm still fleshing out (in the Wiki) what language features are and
> aren't easily translated. I haven't started filling the gaps yet, and
> I love to cooperate with you on that. What you call "goog" and what I
> call "goog" are apparently different things. I don't advocate using
> the Closure Library (which I think is what you refer to as "goog")
> exclusively. What I refer to as the "goog" approach is to use the
> Closure Tools (annotation, compiler and builder) to our advantage. As
> it plays well with those tools, I say let's use what the Closure
> Library has to offer and we miss (so far: goog.provide, goog.require,
> goog.inherits and goog.base).


I don't miss those.
For goog.provide and goog.require, RequireJS provides alternatives that
better fit our needs: asynchronous module loading much better reflects the
nature of script loading in the browser. Synchronous require calls were
made for Node.js or other environments that allow to load scripts
synchronously. RequireJS concentrates exactly on that task and does nothing
else.
goog.inherits and goog.base are IMHO not needed at all. In JS code
generated from ActionScript, what goog.base does can be expressed by a
direct function call (see my prototype). goog.inherits is replaced by my
defineClass() utility, which consists of just 60 lines of code and supports
many more AS3 language features than just inheritance. I also had an
alternative "VanillaJS" version that did not even use a helper method for
inheritance (since it is so easy using ES5 API), but adding the other
language feature, I found that this introduced too much repetitive, boiler
plate code.

One thing I'd like to know: can you use the Closure Tools *completely
without* using the goog library in your JS code and still achieve
ADVANCED_OPTIMIZATIONS? If not, I think that is exactly where the
vendor-lock-in comes into play.


> But I'm all for, as I often comment on
> in the Wiki, creating a small utility class or whatever, if and where
> needed. And again: see my point in *waste:* with regard to the 1500
> lines of code in "base.js". Your point there is missing the point, as
> it where :-)
>

See above. When talking about 1500 lines of code, I don't worry about code
size, but about complexity that shines through during debugging.


>
> *tool/vendor dependency:* The Google Closure Tools are Open Source,
> available under the Apache License 2.0.
>

I know that. Still, it is Google's own interpretation of modules,
inheritance, ... for which there are at least partially standards in
JavaScript (ECMAScript 5, AMD).


>
> *separation of concerns:*
> 1) a matter of choice and convenience, I'm not married to "goog" here,
> but I haven't seen a good reason NOT to use it, so far.
>

See above: too complex, too monolithic, tailored to another use case.


> 2) you are probably correct from a purely language translation point
> of view. But the "ultimate" goal here is not only a language
> translation, but also a framework translation. And I'm sure "some
> polyfills" are not enough to create a cross browser UI framework.
>

To make the UI framework run cross-browser, I have no objections against
using an existing JavaScript framework. But this is my point when talking
about "separations of concerns". I wouldn't hard-wire the pure language
translation to "goog" just because it is a good base for a cross browser UI
framework. And any UI framework should be compatible with VanillaJS!


> 3) I'm hearing "different", I'm not sure I hear "better". Why wouldn't
> we use the Closure Builder for this? I explain the virtue of this tool
> in an earlier email and you can see it in action in the Publisher tool
> I set up in the 'develop' branch of the "asjs" section of the SVN
> repo.
>

What makes a difference to me is that to link with RequireJS, you do not
have use a RequireJS-specific syntax, but an AMD-specific one. They
separate syntax and implementation, which GCC apparently doesn't.


> 4) the Closure Builder does a bit more than linking. Please see my
> previous remark and email, as well as the documentation available
> online.
>

Yes, that's my point. I argue that it does *too much* in one tool, so we
don't have fine-grained control over the code generation process.


> 5) GCC is also more than just an minifier. And we can run it straight
> from the cross compiler, as Mike suggested. That leaves us with the
> option of keeping the intermediate JS code as an supplement output.
>

Yes, but the code is still generated (even if only in-memory) and parsed,
which is an unnecessary overhead in any case.


>
> *testing:* never implied that GCC or anything would free us from
> testing any part of the code. And creating optimised/minified code
> straight from the cross compiler - without using an external tool as
> you seem to imply - would mean that we'd have to write our own
> optimiser/minifier into it. I'm not familiar with creating such a
> tool, but that sounds like a lot of work.
>
> *source maps:* I don't know what you mean by this, so I can't argue
> either direction :-)
>

I'm talking about a new feature available so far in Chrome only to let the
browser debugger map the JavaScript code to the original source code, see
for example
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
If this feature was present in all major browsers, there would no longer be
a need for a debuggable JavaScript code format if we generated source maps.
Firefox has published an implementation plan, but it may take a while. IE
10 will probably follow, now that Microsoft pushes TypeScript.



>
> Like I emphasised before, and I'll repeat it every time it comes up:
> there is, at least not at this point in the development, an absolutely
> right nor absolutely wrong approach. I think we should look for the
> best of both approaches. Our approaches are essentially similar (only
> the tools differ) and I think both have strengths and weaknesses.
> Let's work on this a bit and than revisit this discussion and decide
> on the merits which one fullfils which requirements best.
>

Fully agreed!


>
> Have a great holiday, and keep having fun!
>

Ditto! :-)

-Frank-


>
> EdB
>
>
> On Thu, Dec 20, 2012 at 9:59 PM, Frank Wienberg <fr...@jangaroo.net>
> wrote:
> > Hi Erik,
> >
> > my proposal is not at all about UI frameworks, so I'll try to answer the
> > part about (not) using "goog" / Google Closure Compiler.
> >
> > I agree on the strengths of GCC as being "not only a JS optimiser, it's
> an
> > actual compiler" when you want to write class-oriented JavaScript code
> > manually and maybe use other parts of the "goog" library, and then
> optimize
> > your code for deployment.
> > But I see its strengths turned to weaknesses in our setting. Let me
> explain
> > why.
> >
> >    - *waste:* no need to parse and reverse-engineer JavaScript when we
> >    already have a detailed class-oriented model of what we want to
> generate.
> >    Optimizing JavaScript code directly from the ActionScript source
> gives us
> >    much more knowledge about context (thus we don't need any proprietary
> >    annotations!) and thus at least the same potential to optimize, and
> even
> >    faster because we save the time to generate and parse the intermediate
> >    format.
> >    - *JavaScript readiness:* I think my prototype shows how easy it is to
> >    simulate ActionScript language features in modern JavaScript. The
> central
> >    utility function that implements a small domain-specific language to
> >    declare a class (defineClass.js) has about 60 lines, and it
> implements more
> >    AS3 language features than your "goog"-approach currently does
> (interfaces
> >    with is/as, lazy class initialization for static code, real private
> >    members). A few polyfills are only required to support IE < 9. Goog's
> >    base.js file alone has over 1500 lines, and even if you leave out
> comments,
> >    it is still factor 10 larger. The minified complete application is
> only 5k.
> >    Isn't that small enough?
> >    - *tool/vendor dependency:* we add a dependency on a complex tool that
> >    will also have bugs which we cannot fix. I do not replace "goog" / GCC
> >    by "multiple libraries", but only use one other tool, namely
> RequireJS, as
> >    an AMD implementation that can invoke an optimizer (comes with Uglify
> 2,
> >    but can also use GCC or any other JS optimizer you want) after
> linking.
> >    Using AMD, we rely on an open standard and not something Google
> invented
> >    and maintains.
> >    - *separation of concerns:* "goog"/GCC does at least five things for
> >    FalconJS: 1. simulate classes / inheritance / super calls, 2. solve
> >    cross-browser issues, 3. manage dependencies (require / provide), 4.
> link
> >    all code needed for an application and 5. minimize/optimize JavaScript
> >    code. Instead of relying on one tool "to rule them all", I chose a
> "best of
> >    breed" approach, allowing a "make or buy", and if "buy", choose the
> best
> >    tool, *for each concern*. Currently, my answers are 1. too easy in
> >    generated ECMAScript 5 to bother, 2. use ES5 polyfills for IE < 9, 3.
> use
> >    AMD module layout (implemented by RequireJS), 4. use the RequireJS
> >    "optimizer" tool (rather a "linker"), 5. use any JavaScript minifier
> you
> >    like. The last answer will probably later change to 5. optimize JS
> code
> >    directly during generation (quick win examples: shortening variable
> names,
> >    simple function inlining).
> >    - *testing:* using GCC does not free us from testing optimized code,
> so
> >    this is no argument against generating optimized code directly in the
> >    cross-compiler. But testing both versions is no big deal, as once set
> up,
> >    we expect the exact same results/behavior when running the production
> code
> >    as when running the debug code, so we can run the same integration
> tests
> >    twice.
> >    - *source maps:* letting GCC generate a source map does not help, as
> it
> >    can only produce a source map from production JavaScript code back to
> the
> >    "human readable" JS code we fed in. In contrast, we want a direct (!)
> >    mapping from production JavaScript code back to ActionScript source
> code.
> >    While I wouldn't recommend using the "goog" library, I *do* recommend
> >    GCC as a JavaScript optimizer and as a Java library to generate
> source maps
> >    (I already used it successfully in the Jangaroo compiler to generate
> >    generated-JS->AS3 source maps!).
> >
> > I think we can only really compare runtime performance and generated code
> > size of the two approaches when FalconJx has made some progress and we
> can
> > cross-compile a larger code base for testing.
> > Independent from concrete performance results, my feeling is that in the
> > long term, we are better off relying only on AMD for dependencies /
> linking
> > and on polyfills to make old IE as ECMAScript-5-compatible as possible.
> > Like in Mikes argumentation about the JBurg / BURM approach, I think that
> > learning the goog API, GCC's annotations and how to generate JS code so
> > that GCC can really optimize it and chaining our compiler with GCC
> > introduces unnecessary complexity. Please have a look at my JS prototype
> > and convince yourself how simple it is and that such magic is not
> > necessary! The few things you have to know / learn to understand that
> > format are JavaScript with some ECMAScript 5 extensions and AMD in its
> > purest form (something.js: define([dep1, dep2], function(dep1, dep2) {
> code
> > using dep1, dep2; return something; })). If we could agree to drop IE < 9
> > support, that would even make all the shim.js and polyfill stuff
> > (Object.js, Array...js, Function.bind.js) go away. The few files to
> > simulate is, as, type casts, method binding and trace would also be
> needed
> > when using "goog".
> > This is also a call to Mike and everybody else who thinks that digging
> into
> > the prototype would take 2 weeks or more. There's really only a few lines
> > of code, and some even have comments! ;-) And everything's there to test
> > and debug live in the browser, without even downloading, installing or
> > anything...
> > Here are the links again: live
> > demo<http://fwienber.github.com/as-js-runtime-prototype/> (if
> > you had a look at it before, please clean cache for latest version),
> > source<https://github.com/fwienber/as-js-runtime-prototype>,
> > download <https://github.com/fwienber/as-js-runtime-prototype/tags>
> >
> > Greetings
> > -Frank-
> >
> >
> > On Thu, Dec 20, 2012 at 8:22 PM, Erik de Bruin <er...@ixsoftware.nl>
> wrote:
> >
> >> Hi,
> >>
> >> To complete the party, a few brief comments:
> >>
> >> - at the moment, I'm not sure what approach to the eventual UI
> >> frameworks (AS and JS side) will take. FlexJS is one but it doesn't
> >> (yet) have the feel of something that meets the standards that Flex
> >> users have come to expect.
> >>
> >> - I'm sure that Google's Closure Tools provide us with a lot of the
> >> language features that native JS is missing. The ones it doesn't
> >> (easily) provide, we can have the compiler "replace" as that's what
> >> compilers do, I understand ;-) After we've finished the unit tests for
> >> FalconJx, we can focus on "goog" compatible JS output and create an -
> >> I expect very small - utility class to make up for the difference.
> >>
> >> - As we are using "goog" and Closure annotations to match AS language
> >> features, using the rest of Google's Closure Tools is really low
> >> hanging fruit. The Closure Compiler is not only a JS optimiser, it's
> >> an actual compiler which provides much of the features usually only,
> >> if at all, available if you use multiple libraries. The final piece is
> >> the Closure Builder, which takes an entire "intermediate" (i.e. human
> >> readable) JavaScript project and, combining all the tools in the
> >> Closure set, outputs one JS file, culling out dead code and optimising
> >> the remaining code. I've done a lot of studying on the Closure Tools
> >> the last few weeks and have become convinced they will provide us with
> >> a solid language base to start building the UI frameworks on.
> >>
> >> Having said all that, I really welcome Frank's POC and I think that we
> >> will soon be at a point where we can converge all our efforts and
> >> figure out a common way forward, accepting input from all previous
> >> trails.
> >>
> >> Mike, a question: can the FalconJx compiler tell when a 'regular'
> >> public variable is being accessed and when a public property (with
> >> "get" and "set" methods) is being accessed? I'm asking this because if
> >> it can, it would make it a whole lot easier and would require a whole
> >> lot less workarounds to get that part of the language translation
> >> done...
> >>
> >> TL;DR: for now I'm moving ahead with "goog" as the basis for the
> >> language translation, but I look forward to combining the various
> >> efforts and starting the build of a suitable replacement for the Flex
> >> SDK :-)
> >>
> >> EdB
> >>
> >>
> >>
> >> On Thu, Dec 20, 2012 at 7:23 PM, Michael Schmalle
> >> <ap...@teotigraphix.com> wrote:
> >> >
> >> > Quoting Frank Wienberg <fr...@jangaroo.net>:
> >> >
> >> >> 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.
> >> >
> >> >
> >> > Hi Frank,
> >> >
> >> > Just so you know I read this, I wanted to write a couple things.
> >> >
> >> > FalconJS uses the JBurg BURM which was donated by Adobe. I choose the
> >> route
> >> > of an AST visitor framework that is handcoded for the sake of
> development
> >> > ease and allowing myself to try something with the time I can a lot
> for
> >> this
> >> > development. As far as I see, FalconJS is not being developed by
> anybody
> >> > beyond the fact I read everywhere that it produces "js code". I guess
> if
> >> > FlaconJS is going to be considered an alternative, there has to be
> >> > developers that can work on it, I'm not one of them. I spent 1+ years
> >> > learning antlr grammar and not about to figure out all the other
> >> > prerequisites of the FalconJS code.
> >> >
> >> >
> >> > That being said, I have to be honest that I am in no position to
> either
> >> > agree or argue with what you have produced. Besides the years of
> hands on
> >> > experience you have with JavaScript and ActionScript issues. I would
> say
> >> you
> >> > have a thing or to to add here. :)
> >> >
> >> >
> >> > It seems that right now, there are a handful of developers/community
> >> members
> >> > involved in this topic of AS -> JS. I don't know what will change that
> >> but,
> >> > it seems like we will need to decide on something that works sooner
> than
> >> > later.
> >> >
> >> >
> >> > The truth is, for me to understand what you have done and have an
> >> opinion I
> >> > would probably need 2 or more weeks to understand what you have done.
> :)
> >> >
> >> > I'm probably in the position of, "Show me what you want to generate
> >> based on
> >> > the semantics involved and I will generate it" mode.
> >> >
> >> > For me, my goal as it stands is to use what I have written to generate
> >> fully
> >> > compilable ActionScript source code from Falcon's AST model. Once I
> have
> >> > unit tested this, I can focus on the JavaScript side without thinking
> >> about
> >> > what I have to implement to cover all the AS conversions.
> >> >
> >> > I wonder what Erik has to say... I would be interested since he has
> put
> >> time
> >> > into investigation as well.
> >> >
> >> > So in closing, I really have not developed javascript applications.
> I'm
> >> > interested in this project because having an HTML/JS target for Flex
> >> would
> >> > allow me to do some of my audio experiments with an HTML Flex
> framework
> >> in
> >> > the future for mobile applications.
> >> >
> >> > This allows me the excuse for myself to put as much time into it as I
> >> am. :)
> >> >
> >> > Mike
> >> >
> >> >
> >> >> 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-
> >> >>
> >> >
> >> > --
> >> > Michael Schmalle - Teoti Graphix, LLC
> >> > http://www.teotigraphix.com
> >> > http://blog.teotigraphix.com
> >> >
> >>
> >>
> >>
> >> --
> >> Ix Multimedia Software
> >>
> >> Jan Luykenstraat 27
> >> 3521 VB Utrecht
> >>
> >> T. 06-51952295
> >> I. www.ixsoftware.nl
> >>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

Re: [FalconJx] New JavaScript runtime format prototype

[Daniel Wasilewski <de...@gmail.com>]

On 12/20/2012 9:54 PM, Erik de Bruin wrote:
> *tool/vendor dependency:* The Google Closure Tools are Open Source,
> available under the Apache License 2.0.
>
> *separation of concerns:*
> 1) a matter of choice and convenience, I'm not married to "goog" here,
> but I haven't seen a good reason NOT to use it, so far.
> 2) you are probably correct from a purely language translation point
> of view. But the "ultimate" goal here is not only a language
> translation, but also a framework translation. And I'm sure "some
> polyfills" are not enough to create a cross browser UI framework.
> 3) I'm hearing "different", I'm not sure I hear "better". Why wouldn't
> we use the Closure Builder for this? I explain the virtue of this tool
> in an earlier email and you can see it in action in the Publisher tool
> I set up in the 'develop' branch of the "asjs" section of the SVN
> repo.
> 4) the Closure Builder does a bit more than linking. Please see my
> previous remark and email, as well as the documentation available
> online.
> 5) GCC is also more than just an minifier. And we can run it straight
> from the cross compiler, as Mike suggested. That leaves us with the
> option of keeping the intermediate JS code as an supplement output.
>
> *testing:* never implied that GCC or anything would free us from
> testing any part of the code. And creating optimised/minified code
> straight from the cross compiler - without using an external tool as
> you seem to imply - would mean that we'd have to write our own
> optimiser/minifier into it. I'm not familiar with creating such a
> tool, but that sounds like a lot of work.
>
> *source maps:* I don't know what you mean by this, so I can't argue
> either direction :-)
>
> Like I emphasised before, and I'll repeat it every time it comes up:
> there is, at least not at this point in the development, an absolutely
> right nor absolutely wrong approach. I think we should look for the
> best of both approaches. Our approaches are essentially similar (only
> the tools differ) and I think both have strengths and weaknesses.
> Let's work on this a bit and than revisit this discussion and decide
> on the merits which one fullfils which requirements best.
>
> Have a great holiday, and keep having fun!
>
> EdB
>

I am signing off under Erik post and his thoughts

Re: [FalconJx] New JavaScript runtime format prototype

[Erik de Bruin <er...@ixsoftware.nl>]

Frank,

Excellent points! I see that we are closer in our goals and methods,
but there is still 'some' misunderstanding about the tools we are
proposing. I'll address your points and add my opinion/understanding
where I think some clarification is needed.

- *waste:* In one short scentence: the Closure Builder part of the
Tools takes care of this. Any (really!) code that is not actually used
is NOT included in the output. So, if we use 'goog.base()' from
'base.js', ONLY the code needed to execute that method in the context
we're using it in is included. All the rest is discarded. I'm not sure
about the optimiser(s) you suggest offer the same functionality?

- *JavaScript readiness:* there's nothing to compare here, I'm afraid.
I'm still fleshing out (in the Wiki) what language features are and
aren't easily translated. I haven't started filling the gaps yet, and
I love to cooperate with you on that. What you call "goog" and what I
call "goog" are apparently different things. I don't advocate using
the Closure Library (which I think is what you refer to as "goog")
exclusively. What I refer to as the "goog" approach is to use the
Closure Tools (annotation, compiler and builder) to our advantage. As
it plays well with those tools, I say let's use what the Closure
Library has to offer and we miss (so far: goog.provide, goog.require,
goog.inherits and goog.base). But I'm all for, as I often comment on
in the Wiki, creating a small utility class or whatever, if and where
needed. And again: see my point in *waste:* with regard to the 1500
lines of code in "base.js". Your point there is missing the point, as
it where :-)

*tool/vendor dependency:* The Google Closure Tools are Open Source,
available under the Apache License 2.0.

*separation of concerns:*
1) a matter of choice and convenience, I'm not married to "goog" here,
but I haven't seen a good reason NOT to use it, so far.
2) you are probably correct from a purely language translation point
of view. But the "ultimate" goal here is not only a language
translation, but also a framework translation. And I'm sure "some
polyfills" are not enough to create a cross browser UI framework.
3) I'm hearing "different", I'm not sure I hear "better". Why wouldn't
we use the Closure Builder for this? I explain the virtue of this tool
in an earlier email and you can see it in action in the Publisher tool
I set up in the 'develop' branch of the "asjs" section of the SVN
repo.
4) the Closure Builder does a bit more than linking. Please see my
previous remark and email, as well as the documentation available
online.
5) GCC is also more than just an minifier. And we can run it straight
from the cross compiler, as Mike suggested. That leaves us with the
option of keeping the intermediate JS code as an supplement output.

*testing:* never implied that GCC or anything would free us from
testing any part of the code. And creating optimised/minified code
straight from the cross compiler - without using an external tool as
you seem to imply - would mean that we'd have to write our own
optimiser/minifier into it. I'm not familiar with creating such a
tool, but that sounds like a lot of work.

*source maps:* I don't know what you mean by this, so I can't argue
either direction :-)

Like I emphasised before, and I'll repeat it every time it comes up:
there is, at least not at this point in the development, an absolutely
right nor absolutely wrong approach. I think we should look for the
best of both approaches. Our approaches are essentially similar (only
the tools differ) and I think both have strengths and weaknesses.
Let's work on this a bit and than revisit this discussion and decide
on the merits which one fullfils which requirements best.

Have a great holiday, and keep having fun!

EdB


On Thu, Dec 20, 2012 at 9:59 PM, Frank Wienberg <fr...@jangaroo.net> wrote:
> Hi Erik,
>
> my proposal is not at all about UI frameworks, so I'll try to answer the
> part about (not) using "goog" / Google Closure Compiler.
>
> I agree on the strengths of GCC as being "not only a JS optimiser, it's an
> actual compiler" when you want to write class-oriented JavaScript code
> manually and maybe use other parts of the "goog" library, and then optimize
> your code for deployment.
> But I see its strengths turned to weaknesses in our setting. Let me explain
> why.
>
>    - *waste:* no need to parse and reverse-engineer JavaScript when we
>    already have a detailed class-oriented model of what we want to generate.
>    Optimizing JavaScript code directly from the ActionScript source gives us
>    much more knowledge about context (thus we don't need any proprietary
>    annotations!) and thus at least the same potential to optimize, and even
>    faster because we save the time to generate and parse the intermediate
>    format.
>    - *JavaScript readiness:* I think my prototype shows how easy it is to
>    simulate ActionScript language features in modern JavaScript. The central
>    utility function that implements a small domain-specific language to
>    declare a class (defineClass.js) has about 60 lines, and it implements more
>    AS3 language features than your "goog"-approach currently does (interfaces
>    with is/as, lazy class initialization for static code, real private
>    members). A few polyfills are only required to support IE < 9. Goog's
>    base.js file alone has over 1500 lines, and even if you leave out comments,
>    it is still factor 10 larger. The minified complete application is only 5k.
>    Isn't that small enough?
>    - *tool/vendor dependency:* we add a dependency on a complex tool that
>    will also have bugs which we cannot fix. I do not replace "goog" / GCC
>    by "multiple libraries", but only use one other tool, namely RequireJS, as
>    an AMD implementation that can invoke an optimizer (comes with Uglify 2,
>    but can also use GCC or any other JS optimizer you want) after linking.
>    Using AMD, we rely on an open standard and not something Google invented
>    and maintains.
>    - *separation of concerns:* "goog"/GCC does at least five things for
>    FalconJS: 1. simulate classes / inheritance / super calls, 2. solve
>    cross-browser issues, 3. manage dependencies (require / provide), 4. link
>    all code needed for an application and 5. minimize/optimize JavaScript
>    code. Instead of relying on one tool "to rule them all", I chose a "best of
>    breed" approach, allowing a "make or buy", and if "buy", choose the best
>    tool, *for each concern*. Currently, my answers are 1. too easy in
>    generated ECMAScript 5 to bother, 2. use ES5 polyfills for IE < 9, 3. use
>    AMD module layout (implemented by RequireJS), 4. use the RequireJS
>    "optimizer" tool (rather a "linker"), 5. use any JavaScript minifier you
>    like. The last answer will probably later change to 5. optimize JS code
>    directly during generation (quick win examples: shortening variable names,
>    simple function inlining).
>    - *testing:* using GCC does not free us from testing optimized code, so
>    this is no argument against generating optimized code directly in the
>    cross-compiler. But testing both versions is no big deal, as once set up,
>    we expect the exact same results/behavior when running the production code
>    as when running the debug code, so we can run the same integration tests
>    twice.
>    - *source maps:* letting GCC generate a source map does not help, as it
>    can only produce a source map from production JavaScript code back to the
>    "human readable" JS code we fed in. In contrast, we want a direct (!)
>    mapping from production JavaScript code back to ActionScript source code.
>    While I wouldn't recommend using the "goog" library, I *do* recommend
>    GCC as a JavaScript optimizer and as a Java library to generate source maps
>    (I already used it successfully in the Jangaroo compiler to generate
>    generated-JS->AS3 source maps!).
>
> I think we can only really compare runtime performance and generated code
> size of the two approaches when FalconJx has made some progress and we can
> cross-compile a larger code base for testing.
> Independent from concrete performance results, my feeling is that in the
> long term, we are better off relying only on AMD for dependencies / linking
> and on polyfills to make old IE as ECMAScript-5-compatible as possible.
> Like in Mikes argumentation about the JBurg / BURM approach, I think that
> learning the goog API, GCC's annotations and how to generate JS code so
> that GCC can really optimize it and chaining our compiler with GCC
> introduces unnecessary complexity. Please have a look at my JS prototype
> and convince yourself how simple it is and that such magic is not
> necessary! The few things you have to know / learn to understand that
> format are JavaScript with some ECMAScript 5 extensions and AMD in its
> purest form (something.js: define([dep1, dep2], function(dep1, dep2) { code
> using dep1, dep2; return something; })). If we could agree to drop IE < 9
> support, that would even make all the shim.js and polyfill stuff
> (Object.js, Array...js, Function.bind.js) go away. The few files to
> simulate is, as, type casts, method binding and trace would also be needed
> when using "goog".
> This is also a call to Mike and everybody else who thinks that digging into
> the prototype would take 2 weeks or more. There's really only a few lines
> of code, and some even have comments! ;-) And everything's there to test
> and debug live in the browser, without even downloading, installing or
> anything...
> Here are the links again: live
> demo<http://fwienber.github.com/as-js-runtime-prototype/> (if
> you had a look at it before, please clean cache for latest version),
> source<https://github.com/fwienber/as-js-runtime-prototype>,
> download <https://github.com/fwienber/as-js-runtime-prototype/tags>
>
> Greetings
> -Frank-
>
>
> On Thu, Dec 20, 2012 at 8:22 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
>> Hi,
>>
>> To complete the party, a few brief comments:
>>
>> - at the moment, I'm not sure what approach to the eventual UI
>> frameworks (AS and JS side) will take. FlexJS is one but it doesn't
>> (yet) have the feel of something that meets the standards that Flex
>> users have come to expect.
>>
>> - I'm sure that Google's Closure Tools provide us with a lot of the
>> language features that native JS is missing. The ones it doesn't
>> (easily) provide, we can have the compiler "replace" as that's what
>> compilers do, I understand ;-) After we've finished the unit tests for
>> FalconJx, we can focus on "goog" compatible JS output and create an -
>> I expect very small - utility class to make up for the difference.
>>
>> - As we are using "goog" and Closure annotations to match AS language
>> features, using the rest of Google's Closure Tools is really low
>> hanging fruit. The Closure Compiler is not only a JS optimiser, it's
>> an actual compiler which provides much of the features usually only,
>> if at all, available if you use multiple libraries. The final piece is
>> the Closure Builder, which takes an entire "intermediate" (i.e. human
>> readable) JavaScript project and, combining all the tools in the
>> Closure set, outputs one JS file, culling out dead code and optimising
>> the remaining code. I've done a lot of studying on the Closure Tools
>> the last few weeks and have become convinced they will provide us with
>> a solid language base to start building the UI frameworks on.
>>
>> Having said all that, I really welcome Frank's POC and I think that we
>> will soon be at a point where we can converge all our efforts and
>> figure out a common way forward, accepting input from all previous
>> trails.
>>
>> Mike, a question: can the FalconJx compiler tell when a 'regular'
>> public variable is being accessed and when a public property (with
>> "get" and "set" methods) is being accessed? I'm asking this because if
>> it can, it would make it a whole lot easier and would require a whole
>> lot less workarounds to get that part of the language translation
>> done...
>>
>> TL;DR: for now I'm moving ahead with "goog" as the basis for the
>> language translation, but I look forward to combining the various
>> efforts and starting the build of a suitable replacement for the Flex
>> SDK :-)
>>
>> EdB
>>
>>
>>
>> On Thu, Dec 20, 2012 at 7:23 PM, Michael Schmalle
>> <ap...@teotigraphix.com> wrote:
>> >
>> > Quoting Frank Wienberg <fr...@jangaroo.net>:
>> >
>> >> 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.
>> >
>> >
>> > Hi Frank,
>> >
>> > Just so you know I read this, I wanted to write a couple things.
>> >
>> > FalconJS uses the JBurg BURM which was donated by Adobe. I choose the
>> route
>> > of an AST visitor framework that is handcoded for the sake of development
>> > ease and allowing myself to try something with the time I can a lot for
>> this
>> > development. As far as I see, FalconJS is not being developed by anybody
>> > beyond the fact I read everywhere that it produces "js code". I guess if
>> > FlaconJS is going to be considered an alternative, there has to be
>> > developers that can work on it, I'm not one of them. I spent 1+ years
>> > learning antlr grammar and not about to figure out all the other
>> > prerequisites of the FalconJS code.
>> >
>> >
>> > That being said, I have to be honest that I am in no position to either
>> > agree or argue with what you have produced. Besides the years of hands on
>> > experience you have with JavaScript and ActionScript issues. I would say
>> you
>> > have a thing or to to add here. :)
>> >
>> >
>> > It seems that right now, there are a handful of developers/community
>> members
>> > involved in this topic of AS -> JS. I don't know what will change that
>> but,
>> > it seems like we will need to decide on something that works sooner than
>> > later.
>> >
>> >
>> > The truth is, for me to understand what you have done and have an
>> opinion I
>> > would probably need 2 or more weeks to understand what you have done. :)
>> >
>> > I'm probably in the position of, "Show me what you want to generate
>> based on
>> > the semantics involved and I will generate it" mode.
>> >
>> > For me, my goal as it stands is to use what I have written to generate
>> fully
>> > compilable ActionScript source code from Falcon's AST model. Once I have
>> > unit tested this, I can focus on the JavaScript side without thinking
>> about
>> > what I have to implement to cover all the AS conversions.
>> >
>> > I wonder what Erik has to say... I would be interested since he has put
>> time
>> > into investigation as well.
>> >
>> > So in closing, I really have not developed javascript applications. I'm
>> > interested in this project because having an HTML/JS target for Flex
>> would
>> > allow me to do some of my audio experiments with an HTML Flex framework
>> in
>> > the future for mobile applications.
>> >
>> > This allows me the excuse for myself to put as much time into it as I
>> am. :)
>> >
>> > Mike
>> >
>> >
>> >> 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-
>> >>
>> >
>> > --
>> > Michael Schmalle - Teoti Graphix, LLC
>> > http://www.teotigraphix.com
>> > http://blog.teotigraphix.com
>> >
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

Ah, one thing I forgot, a short overview of the prototype's directory
structure and files.

The root directory contains

   - the HTML files *index.html* and those that load the three application
   variants (*app-*.html*)
   - the linked (minimized) generated JavaScript application files *
   hello-world-all[.min].js*.
   - The *README.md* tells you how to re-generate these from the faked
   compiler output JS files (see below) after changes.

   - *src *contains the example ActionScript source files, neatly sorted by
   packages, for reference and for comparison with the faked compiler output
   JavaScript files.
   - *requirejs *contains original RequireJS 2.1.2 in a debug (*require.js*)
   and a minified (*require-min.js*) version.
   - *amd* contains all JavaScript files to be loaded/linked by RequireJS.
   It directly contains
   - the original RequireJS-plugin "shim" (*shim.js*, *shims.js*, *
      shim-LICENSE.txt*) that takes care of loading...
      - ...missing ECMAScript 5 functions if the browser does not support
      them (*Array.*.js*, *Function.prototype.js*, *Object.js*)
      - the main JavaScript file *hello-world.js* that loads/links the
      example classes and interfaces and executes some rather random
tests on the
      generated code


   - *as3*: folder containing implementations of ActionScript operators /
      functions missing in JavaScript
      - *as.js* -- the ActionScript "as" operator
         - *bind.js* -- a caching extension of Function#bind() for AS3
         method binding
         - *cast.js* -- a type cast operator for runtime type checks
         (currently unused)
         - *is.js* -- the ActionScript "is" operator (instanceof that also
         works for interfaces)
         - *trace-console.js* -- an ActionScript trace() simulation using
         console.log()
         - *trace.js* -- an ActionScript trace() simulation rendering to
         the DOM for demo purposes
         - *runtime*: folder that contains two small helper functions to
      ease specifying AS3 class structures in JavaScript
      - *defineClass.js* -- the central utility function that is used for
         defining an ActionScript class structure
         - *defineInterface.js* -- a little bit syntactic sugar to define
         ActionScript interfaces (almost not worth the effort, but for
symmetry...)
      - *classes*: folder containing the actual "generated" JavaScript
      code, i.e. the faked FalconJx compiler output. It uses the well-known
      pattern to define a sub-folder for every package "part".
      - *com/acme*: sub-sub-folder for the first example package,
         containing two classes and one interface
         - *A.js* -- a faked compilation result of the ActionScript class *
            src/com/acme/A.as*
            - *B.js* -- a faked compilation result of the ActionScript
            subclass *src/com/acme/B.as*
            - *I.js* -- a faked compilation result of the ActionScript
            interface *src/com/acme/I.as*, implemented by A

            - *sub*: sub-folder for the second example package, containing
            two more interfaces
            - *IOther.js* -- a faked compilation result of the ActionScript
               interface *src/com/acme/sub/IOther.as*, implemented by B
               - *ISub.js* -- a faked compilation result of the
               ActionScript interface *src/com/acme/sub/ISub.as*, also
               implemented by B

The folder *amd/runtime* actually contains a third file *
defineClass-initializing-static-fields.js*, which is not yet used; it is an
alternative to *defineClass.js* that even takes care of initializing
classes when accessing their public static fields, but only works in real
ES5-browsers (not IE < 9). You can safely ignore it for now.

That's it!

-Frank-

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

Dan, did you check out the "linked" version? It just loads require.js for
bootstrap, then hello-world-all.js that contains the whole application.
The list of scripts that you mentioned is only generated dynamically in
RequireJS's debug mode. Until we have JS source map support in all major
browsers, I am convinced we should have such a mode where each compilation
unit to debug loads as a separate request. Otherwise, it is really hard to
find to class where you want to set a break-point in the debugger.


On Thu, Dec 20, 2012 at 10:47 PM, Daniel Wasilewski <de...@gmail.com>wrote:

> Well, some says JS is just JS and I disagree with that statement because
> it is al about how you write JS.
> JQuery is popular this days but limited developers by slowing down runtime
> over 100x times.
>
> Impossible to make mobile web application with acceptable performance
> level when mobile platform is another factor of 10 in slow down.
>
> How do you thing your solution perform vs goog. This is my only concern I
> was trying to rise from begining of Falcon JS thread.
> Looking at your examples they may feel simple indeed, but this very
> structure:
>
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="hello-world"**src="amd/hello-world.js">
>
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="as3/trace"src="**
> amd/as3/trace.js">
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="as3/is"src="**amd/as3/is.js">
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="classes/com/**
> acme/B"src="amd/classes/com/**acme/B.js">
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="classes/com/**
> acme/A"src="amd/classes/com/**acme/A.js">
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="classes/com/**
> acme/I"src="amd/classes/com/**acme/I.js">
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="classes/com/**
> acme/sub/IOther"src="amd/**classes/com/acme/sub/IOther.**js">
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="classes/com/**
> acme/sub/ISub"src="amd/**classes/com/acme/sub/ISub.js">
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="shim"src="amd/**shim.js">
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="runtime/**
> defineClass"src="amd/runtime/**defineClass.js">
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="as3/bind"src="**amd/as3/bind.js">
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="runtime/**
> defineInterface"src="amd/**runtime/defineInterface.js">
> <scripttype="text/javascript"**charset="utf-8"async=""data-**
> requirecontext="_"data-**requiremodule="shims"src="amd/**shims.js">
>
> Is way beyond vanilla JS approach.
>
> Dan
>
>
> On 12/20/2012 8:59 PM, Frank Wienberg wrote:
>
>> Hi Erik,
>>
>> my proposal is not at all about UI frameworks, so I'll try to answer the
>> part about (not) using "goog" / Google Closure Compiler.
>>
>> I agree on the strengths of GCC as being "not only a JS optimiser, it's an
>> actual compiler" when you want to write class-oriented JavaScript code
>> manually and maybe use other parts of the "goog" library, and then
>> optimize
>> your code for deployment.
>> But I see its strengths turned to weaknesses in our setting. Let me
>> explain
>> why.
>>
>>     - *waste:* no need to parse and reverse-engineer JavaScript when we
>>
>>     already have a detailed class-oriented model of what we want to
>> generate.
>>     Optimizing JavaScript code directly from the ActionScript source
>> gives us
>>     much more knowledge about context (thus we don't need any proprietary
>>     annotations!) and thus at least the same potential to optimize, and
>> even
>>     faster because we save the time to generate and parse the intermediate
>>     format.
>>     - *JavaScript readiness:* I think my prototype shows how easy it is to
>>
>>     simulate ActionScript language features in modern JavaScript. The
>> central
>>     utility function that implements a small domain-specific language to
>>     declare a class (defineClass.js) has about 60 lines, and it
>> implements more
>>     AS3 language features than your "goog"-approach currently does
>> (interfaces
>>     with is/as, lazy class initialization for static code, real private
>>     members). A few polyfills are only required to support IE < 9. Goog's
>>     base.js file alone has over 1500 lines, and even if you leave out
>> comments,
>>     it is still factor 10 larger. The minified complete application is
>> only 5k.
>>     Isn't that small enough?
>>     - *tool/vendor dependency:* we add a dependency on a complex tool that
>>
>>     will also have bugs which we cannot fix. I do not replace "goog" / GCC
>>     by "multiple libraries", but only use one other tool, namely
>> RequireJS, as
>>     an AMD implementation that can invoke an optimizer (comes with Uglify
>> 2,
>>     but can also use GCC or any other JS optimizer you want) after
>> linking.
>>     Using AMD, we rely on an open standard and not something Google
>> invented
>>     and maintains.
>>     - *separation of concerns:* "goog"/GCC does at least five things for
>>
>>     FalconJS: 1. simulate classes / inheritance / super calls, 2. solve
>>     cross-browser issues, 3. manage dependencies (require / provide), 4.
>> link
>>     all code needed for an application and 5. minimize/optimize JavaScript
>>     code. Instead of relying on one tool "to rule them all", I chose a
>> "best of
>>     breed" approach, allowing a "make or buy", and if "buy", choose the
>> best
>>     tool, *for each concern*. Currently, my answers are 1. too easy in
>>
>>     generated ECMAScript 5 to bother, 2. use ES5 polyfills for IE < 9, 3.
>> use
>>     AMD module layout (implemented by RequireJS), 4. use the RequireJS
>>     "optimizer" tool (rather a "linker"), 5. use any JavaScript minifier
>> you
>>     like. The last answer will probably later change to 5. optimize JS
>> code
>>     directly during generation (quick win examples: shortening variable
>> names,
>>     simple function inlining).
>>     - *testing:* using GCC does not free us from testing optimized code,
>> so
>>
>>     this is no argument against generating optimized code directly in the
>>     cross-compiler. But testing both versions is no big deal, as once set
>> up,
>>     we expect the exact same results/behavior when running the production
>> code
>>     as when running the debug code, so we can run the same integration
>> tests
>>     twice.
>>     - *source maps:* letting GCC generate a source map does not help, as
>> it
>>
>>     can only produce a source map from production JavaScript code back to
>> the
>>     "human readable" JS code we fed in. In contrast, we want a direct (!)
>>     mapping from production JavaScript code back to ActionScript source
>> code.
>>     While I wouldn't recommend using the "goog" library, I *do* recommend
>>
>>     GCC as a JavaScript optimizer and as a Java library to generate
>> source maps
>>     (I already used it successfully in the Jangaroo compiler to generate
>>     generated-JS->AS3 source maps!).
>>
>> I think we can only really compare runtime performance and generated code
>> size of the two approaches when FalconJx has made some progress and we can
>> cross-compile a larger code base for testing.
>> Independent from concrete performance results, my feeling is that in the
>> long term, we are better off relying only on AMD for dependencies /
>> linking
>> and on polyfills to make old IE as ECMAScript-5-compatible as possible.
>> Like in Mikes argumentation about the JBurg / BURM approach, I think that
>> learning the goog API, GCC's annotations and how to generate JS code so
>> that GCC can really optimize it and chaining our compiler with GCC
>> introduces unnecessary complexity. Please have a look at my JS prototype
>> and convince yourself how simple it is and that such magic is not
>> necessary! The few things you have to know / learn to understand that
>> format are JavaScript with some ECMAScript 5 extensions and AMD in its
>> purest form (something.js: define([dep1, dep2], function(dep1, dep2) {
>> code
>> using dep1, dep2; return something; })). If we could agree to drop IE < 9
>> support, that would even make all the shim.js and polyfill stuff
>> (Object.js, Array...js, Function.bind.js) go away. The few files to
>> simulate is, as, type casts, method binding and trace would also be needed
>> when using "goog".
>> This is also a call to Mike and everybody else who thinks that digging
>> into
>> the prototype would take 2 weeks or more. There's really only a few lines
>> of code, and some even have comments! ;-) And everything's there to test
>> and debug live in the browser, without even downloading, installing or
>> anything...
>> Here are the links again: live
>> demo<http://fwienber.github.**com/as-js-runtime-prototype/<http://fwienber.github.com/as-js-runtime-prototype/>>
>> (if
>>
>> you had a look at it before, please clean cache for latest version),
>> source<https://github.com/**fwienber/as-js-runtime-**prototype<https://github.com/fwienber/as-js-runtime-prototype>
>> >,
>> download <https://github.com/fwienber/**as-js-runtime-prototype/tags<https://github.com/fwienber/as-js-runtime-prototype/tags>
>> >
>>
>>
>> Greetings
>> -Frank-
>>
>>
>> On Thu, Dec 20, 2012 at 8:22 PM, Erik de Bruin <er...@ixsoftware.nl>
>> wrote:
>>
>>  Hi,
>>>
>>> To complete the party, a few brief comments:
>>>
>>> - at the moment, I'm not sure what approach to the eventual UI
>>> frameworks (AS and JS side) will take. FlexJS is one but it doesn't
>>> (yet) have the feel of something that meets the standards that Flex
>>> users have come to expect.
>>>
>>> - I'm sure that Google's Closure Tools provide us with a lot of the
>>> language features that native JS is missing. The ones it doesn't
>>> (easily) provide, we can have the compiler "replace" as that's what
>>> compilers do, I understand ;-) After we've finished the unit tests for
>>> FalconJx, we can focus on "goog" compatible JS output and create an -
>>> I expect very small - utility class to make up for the difference.
>>>
>>> - As we are using "goog" and Closure annotations to match AS language
>>> features, using the rest of Google's Closure Tools is really low
>>> hanging fruit. The Closure Compiler is not only a JS optimiser, it's
>>> an actual compiler which provides much of the features usually only,
>>> if at all, available if you use multiple libraries. The final piece is
>>> the Closure Builder, which takes an entire "intermediate" (i.e. human
>>> readable) JavaScript project and, combining all the tools in the
>>> Closure set, outputs one JS file, culling out dead code and optimising
>>> the remaining code. I've done a lot of studying on the Closure Tools
>>> the last few weeks and have become convinced they will provide us with
>>> a solid language base to start building the UI frameworks on.
>>>
>>> Having said all that, I really welcome Frank's POC and I think that we
>>> will soon be at a point where we can converge all our efforts and
>>> figure out a common way forward, accepting input from all previous
>>> trails.
>>>
>>> Mike, a question: can the FalconJx compiler tell when a 'regular'
>>> public variable is being accessed and when a public property (with
>>> "get" and "set" methods) is being accessed? I'm asking this because if
>>> it can, it would make it a whole lot easier and would require a whole
>>> lot less workarounds to get that part of the language translation
>>> done...
>>>
>>> TL;DR: for now I'm moving ahead with "goog" as the basis for the
>>> language translation, but I look forward to combining the various
>>> efforts and starting the build of a suitable replacement for the Flex
>>> SDK :-)
>>>
>>> EdB
>>>
>>>
>>>
>>> On Thu, Dec 20, 2012 at 7:23 PM, Michael Schmalle
>>> <ap...@teotigraphix.com> wrote:
>>>
>>>> Quoting Frank Wienberg <fr...@jangaroo.net>:
>>>>
>>>>  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.
>>>>>
>>>>
>>>> Hi Frank,
>>>>
>>>> Just so you know I read this, I wanted to write a couple things.
>>>>
>>>> FalconJS uses the JBurg BURM which was donated by Adobe. I choose the
>>>>
>>> route
>>>
>>>> of an AST visitor framework that is handcoded for the sake of
>>>> development
>>>> ease and allowing myself to try something with the time I can a lot for
>>>>
>>> this
>>>
>>>> development. As far as I see, FalconJS is not being developed by anybody
>>>> beyond the fact I read everywhere that it produces "js code". I guess if
>>>> FlaconJS is going to be considered an alternative, there has to be
>>>> developers that can work on it, I'm not one of them. I spent 1+ years
>>>> learning antlr grammar and not about to figure out all the other
>>>> prerequisites of the FalconJS code.
>>>>
>>>>
>>>> That being said, I have to be honest that I am in no position to either
>>>> agree or argue with what you have produced. Besides the years of hands
>>>> on
>>>> experience you have with JavaScript and ActionScript issues. I would say
>>>>
>>> you
>>>
>>>> have a thing or to to add here. :)
>>>>
>>>>
>>>> It seems that right now, there are a handful of developers/community
>>>>
>>> members
>>>
>>>> involved in this topic of AS -> JS. I don't know what will change that
>>>>
>>> but,
>>>
>>>> it seems like we will need to decide on something that works sooner than
>>>> later.
>>>>
>>>>
>>>> The truth is, for me to understand what you have done and have an
>>>>
>>> opinion I
>>>
>>>> would probably need 2 or more weeks to understand what you have done. :)
>>>>
>>>> I'm probably in the position of, "Show me what you want to generate
>>>>
>>> based on
>>>
>>>> the semantics involved and I will generate it" mode.
>>>>
>>>> For me, my goal as it stands is to use what I have written to generate
>>>>
>>> fully
>>>
>>>> compilable ActionScript source code from Falcon's AST model. Once I have
>>>> unit tested this, I can focus on the JavaScript side without thinking
>>>>
>>> about
>>>
>>>> what I have to implement to cover all the AS conversions.
>>>>
>>>> I wonder what Erik has to say... I would be interested since he has put
>>>>
>>> time
>>>
>>>> into investigation as well.
>>>>
>>>> So in closing, I really have not developed javascript applications. I'm
>>>> interested in this project because having an HTML/JS target for Flex
>>>>
>>> would
>>>
>>>> allow me to do some of my audio experiments with an HTML Flex framework
>>>>
>>> in
>>>
>>>> the future for mobile applications.
>>>>
>>>> This allows me the excuse for myself to put as much time into it as I
>>>>
>>> am. :)
>>>
>>>> Mike
>>>>
>>>>
>>>>  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<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<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<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<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-
>>>>>
>>>>>  --
>>>> Michael Schmalle - Teoti Graphix, LLC
>>>> http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>>
>>>
>

Re: [FalconJx] New JavaScript runtime format prototype

[Daniel Wasilewski <de...@gmail.com>]

Well, some says JS is just JS and I disagree with that statement because 
it is al about how you write JS.
JQuery is popular this days but limited developers by slowing down 
runtime over 100x times.

Impossible to make mobile web application with acceptable performance 
level when mobile platform is another factor of 10 in slow down.

How do you thing your solution perform vs goog. This is my only concern 
I was trying to rise from begining of Falcon JS thread.
Looking at your examples they may feel simple indeed, but this very 
structure:

<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="hello-world"src="amd/hello-world.js"> 

<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="as3/trace"src="amd/as3/trace.js">
<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="as3/is"src="amd/as3/is.js">
<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="classes/com/acme/B"src="amd/classes/com/acme/B.js">
<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="classes/com/acme/A"src="amd/classes/com/acme/A.js">
<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="classes/com/acme/I"src="amd/classes/com/acme/I.js">
<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="classes/com/acme/sub/IOther"src="amd/classes/com/acme/sub/IOther.js">
<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="classes/com/acme/sub/ISub"src="amd/classes/com/acme/sub/ISub.js">
<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="shim"src="amd/shim.js">
<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="runtime/defineClass"src="amd/runtime/defineClass.js">
<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="as3/bind"src="amd/as3/bind.js">
<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="runtime/defineInterface"src="amd/runtime/defineInterface.js">
<scripttype="text/javascript"charset="utf-8"async=""data-requirecontext="_"data-requiremodule="shims"src="amd/shims.js">

Is way beyond vanilla JS approach.

Dan

On 12/20/2012 8:59 PM, Frank Wienberg wrote:
> Hi Erik,
>
> my proposal is not at all about UI frameworks, so I'll try to answer the
> part about (not) using "goog" / Google Closure Compiler.
>
> I agree on the strengths of GCC as being "not only a JS optimiser, it's an
> actual compiler" when you want to write class-oriented JavaScript code
> manually and maybe use other parts of the "goog" library, and then optimize
> your code for deployment.
> But I see its strengths turned to weaknesses in our setting. Let me explain
> why.
>
>     - *waste:* no need to parse and reverse-engineer JavaScript when we
>     already have a detailed class-oriented model of what we want to generate.
>     Optimizing JavaScript code directly from the ActionScript source gives us
>     much more knowledge about context (thus we don't need any proprietary
>     annotations!) and thus at least the same potential to optimize, and even
>     faster because we save the time to generate and parse the intermediate
>     format.
>     - *JavaScript readiness:* I think my prototype shows how easy it is to
>     simulate ActionScript language features in modern JavaScript. The central
>     utility function that implements a small domain-specific language to
>     declare a class (defineClass.js) has about 60 lines, and it implements more
>     AS3 language features than your "goog"-approach currently does (interfaces
>     with is/as, lazy class initialization for static code, real private
>     members). A few polyfills are only required to support IE < 9. Goog's
>     base.js file alone has over 1500 lines, and even if you leave out comments,
>     it is still factor 10 larger. The minified complete application is only 5k.
>     Isn't that small enough?
>     - *tool/vendor dependency:* we add a dependency on a complex tool that
>     will also have bugs which we cannot fix. I do not replace "goog" / GCC
>     by "multiple libraries", but only use one other tool, namely RequireJS, as
>     an AMD implementation that can invoke an optimizer (comes with Uglify 2,
>     but can also use GCC or any other JS optimizer you want) after linking.
>     Using AMD, we rely on an open standard and not something Google invented
>     and maintains.
>     - *separation of concerns:* "goog"/GCC does at least five things for
>     FalconJS: 1. simulate classes / inheritance / super calls, 2. solve
>     cross-browser issues, 3. manage dependencies (require / provide), 4. link
>     all code needed for an application and 5. minimize/optimize JavaScript
>     code. Instead of relying on one tool "to rule them all", I chose a "best of
>     breed" approach, allowing a "make or buy", and if "buy", choose the best
>     tool, *for each concern*. Currently, my answers are 1. too easy in
>     generated ECMAScript 5 to bother, 2. use ES5 polyfills for IE < 9, 3. use
>     AMD module layout (implemented by RequireJS), 4. use the RequireJS
>     "optimizer" tool (rather a "linker"), 5. use any JavaScript minifier you
>     like. The last answer will probably later change to 5. optimize JS code
>     directly during generation (quick win examples: shortening variable names,
>     simple function inlining).
>     - *testing:* using GCC does not free us from testing optimized code, so
>     this is no argument against generating optimized code directly in the
>     cross-compiler. But testing both versions is no big deal, as once set up,
>     we expect the exact same results/behavior when running the production code
>     as when running the debug code, so we can run the same integration tests
>     twice.
>     - *source maps:* letting GCC generate a source map does not help, as it
>     can only produce a source map from production JavaScript code back to the
>     "human readable" JS code we fed in. In contrast, we want a direct (!)
>     mapping from production JavaScript code back to ActionScript source code.
>     While I wouldn't recommend using the "goog" library, I *do* recommend
>     GCC as a JavaScript optimizer and as a Java library to generate source maps
>     (I already used it successfully in the Jangaroo compiler to generate
>     generated-JS->AS3 source maps!).
>
> I think we can only really compare runtime performance and generated code
> size of the two approaches when FalconJx has made some progress and we can
> cross-compile a larger code base for testing.
> Independent from concrete performance results, my feeling is that in the
> long term, we are better off relying only on AMD for dependencies / linking
> and on polyfills to make old IE as ECMAScript-5-compatible as possible.
> Like in Mikes argumentation about the JBurg / BURM approach, I think that
> learning the goog API, GCC's annotations and how to generate JS code so
> that GCC can really optimize it and chaining our compiler with GCC
> introduces unnecessary complexity. Please have a look at my JS prototype
> and convince yourself how simple it is and that such magic is not
> necessary! The few things you have to know / learn to understand that
> format are JavaScript with some ECMAScript 5 extensions and AMD in its
> purest form (something.js: define([dep1, dep2], function(dep1, dep2) { code
> using dep1, dep2; return something; })). If we could agree to drop IE < 9
> support, that would even make all the shim.js and polyfill stuff
> (Object.js, Array...js, Function.bind.js) go away. The few files to
> simulate is, as, type casts, method binding and trace would also be needed
> when using "goog".
> This is also a call to Mike and everybody else who thinks that digging into
> the prototype would take 2 weeks or more. There's really only a few lines
> of code, and some even have comments! ;-) And everything's there to test
> and debug live in the browser, without even downloading, installing or
> anything...
> Here are the links again: live
> demo<http://fwienber.github.com/as-js-runtime-prototype/> (if
> you had a look at it before, please clean cache for latest version),
> source<https://github.com/fwienber/as-js-runtime-prototype>,
> download <https://github.com/fwienber/as-js-runtime-prototype/tags>
>
> Greetings
> -Frank-
>
>
> On Thu, Dec 20, 2012 at 8:22 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
>> Hi,
>>
>> To complete the party, a few brief comments:
>>
>> - at the moment, I'm not sure what approach to the eventual UI
>> frameworks (AS and JS side) will take. FlexJS is one but it doesn't
>> (yet) have the feel of something that meets the standards that Flex
>> users have come to expect.
>>
>> - I'm sure that Google's Closure Tools provide us with a lot of the
>> language features that native JS is missing. The ones it doesn't
>> (easily) provide, we can have the compiler "replace" as that's what
>> compilers do, I understand ;-) After we've finished the unit tests for
>> FalconJx, we can focus on "goog" compatible JS output and create an -
>> I expect very small - utility class to make up for the difference.
>>
>> - As we are using "goog" and Closure annotations to match AS language
>> features, using the rest of Google's Closure Tools is really low
>> hanging fruit. The Closure Compiler is not only a JS optimiser, it's
>> an actual compiler which provides much of the features usually only,
>> if at all, available if you use multiple libraries. The final piece is
>> the Closure Builder, which takes an entire "intermediate" (i.e. human
>> readable) JavaScript project and, combining all the tools in the
>> Closure set, outputs one JS file, culling out dead code and optimising
>> the remaining code. I've done a lot of studying on the Closure Tools
>> the last few weeks and have become convinced they will provide us with
>> a solid language base to start building the UI frameworks on.
>>
>> Having said all that, I really welcome Frank's POC and I think that we
>> will soon be at a point where we can converge all our efforts and
>> figure out a common way forward, accepting input from all previous
>> trails.
>>
>> Mike, a question: can the FalconJx compiler tell when a 'regular'
>> public variable is being accessed and when a public property (with
>> "get" and "set" methods) is being accessed? I'm asking this because if
>> it can, it would make it a whole lot easier and would require a whole
>> lot less workarounds to get that part of the language translation
>> done...
>>
>> TL;DR: for now I'm moving ahead with "goog" as the basis for the
>> language translation, but I look forward to combining the various
>> efforts and starting the build of a suitable replacement for the Flex
>> SDK :-)
>>
>> EdB
>>
>>
>>
>> On Thu, Dec 20, 2012 at 7:23 PM, Michael Schmalle
>> <ap...@teotigraphix.com> wrote:
>>> Quoting Frank Wienberg <fr...@jangaroo.net>:
>>>
>>>> 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.
>>>
>>> Hi Frank,
>>>
>>> Just so you know I read this, I wanted to write a couple things.
>>>
>>> FalconJS uses the JBurg BURM which was donated by Adobe. I choose the
>> route
>>> of an AST visitor framework that is handcoded for the sake of development
>>> ease and allowing myself to try something with the time I can a lot for
>> this
>>> development. As far as I see, FalconJS is not being developed by anybody
>>> beyond the fact I read everywhere that it produces "js code". I guess if
>>> FlaconJS is going to be considered an alternative, there has to be
>>> developers that can work on it, I'm not one of them. I spent 1+ years
>>> learning antlr grammar and not about to figure out all the other
>>> prerequisites of the FalconJS code.
>>>
>>>
>>> That being said, I have to be honest that I am in no position to either
>>> agree or argue with what you have produced. Besides the years of hands on
>>> experience you have with JavaScript and ActionScript issues. I would say
>> you
>>> have a thing or to to add here. :)
>>>
>>>
>>> It seems that right now, there are a handful of developers/community
>> members
>>> involved in this topic of AS -> JS. I don't know what will change that
>> but,
>>> it seems like we will need to decide on something that works sooner than
>>> later.
>>>
>>>
>>> The truth is, for me to understand what you have done and have an
>> opinion I
>>> would probably need 2 or more weeks to understand what you have done. :)
>>>
>>> I'm probably in the position of, "Show me what you want to generate
>> based on
>>> the semantics involved and I will generate it" mode.
>>>
>>> For me, my goal as it stands is to use what I have written to generate
>> fully
>>> compilable ActionScript source code from Falcon's AST model. Once I have
>>> unit tested this, I can focus on the JavaScript side without thinking
>> about
>>> what I have to implement to cover all the AS conversions.
>>>
>>> I wonder what Erik has to say... I would be interested since he has put
>> time
>>> into investigation as well.
>>>
>>> So in closing, I really have not developed javascript applications. I'm
>>> interested in this project because having an HTML/JS target for Flex
>> would
>>> allow me to do some of my audio experiments with an HTML Flex framework
>> in
>>> the future for mobile applications.
>>>
>>> This allows me the excuse for myself to put as much time into it as I
>> am. :)
>>> Mike
>>>
>>>
>>>> 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-
>>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

Hi Erik,

my proposal is not at all about UI frameworks, so I'll try to answer the
part about (not) using "goog" / Google Closure Compiler.

I agree on the strengths of GCC as being "not only a JS optimiser, it's an
actual compiler" when you want to write class-oriented JavaScript code
manually and maybe use other parts of the "goog" library, and then optimize
your code for deployment.
But I see its strengths turned to weaknesses in our setting. Let me explain
why.

   - *waste:* no need to parse and reverse-engineer JavaScript when we
   already have a detailed class-oriented model of what we want to generate.
   Optimizing JavaScript code directly from the ActionScript source gives us
   much more knowledge about context (thus we don't need any proprietary
   annotations!) and thus at least the same potential to optimize, and even
   faster because we save the time to generate and parse the intermediate
   format.
   - *JavaScript readiness:* I think my prototype shows how easy it is to
   simulate ActionScript language features in modern JavaScript. The central
   utility function that implements a small domain-specific language to
   declare a class (defineClass.js) has about 60 lines, and it implements more
   AS3 language features than your "goog"-approach currently does (interfaces
   with is/as, lazy class initialization for static code, real private
   members). A few polyfills are only required to support IE < 9. Goog's
   base.js file alone has over 1500 lines, and even if you leave out comments,
   it is still factor 10 larger. The minified complete application is only 5k.
   Isn't that small enough?
   - *tool/vendor dependency:* we add a dependency on a complex tool that
   will also have bugs which we cannot fix. I do not replace "goog" / GCC
   by "multiple libraries", but only use one other tool, namely RequireJS, as
   an AMD implementation that can invoke an optimizer (comes with Uglify 2,
   but can also use GCC or any other JS optimizer you want) after linking.
   Using AMD, we rely on an open standard and not something Google invented
   and maintains.
   - *separation of concerns:* "goog"/GCC does at least five things for
   FalconJS: 1. simulate classes / inheritance / super calls, 2. solve
   cross-browser issues, 3. manage dependencies (require / provide), 4. link
   all code needed for an application and 5. minimize/optimize JavaScript
   code. Instead of relying on one tool "to rule them all", I chose a "best of
   breed" approach, allowing a "make or buy", and if "buy", choose the best
   tool, *for each concern*. Currently, my answers are 1. too easy in
   generated ECMAScript 5 to bother, 2. use ES5 polyfills for IE < 9, 3. use
   AMD module layout (implemented by RequireJS), 4. use the RequireJS
   "optimizer" tool (rather a "linker"), 5. use any JavaScript minifier you
   like. The last answer will probably later change to 5. optimize JS code
   directly during generation (quick win examples: shortening variable names,
   simple function inlining).
   - *testing:* using GCC does not free us from testing optimized code, so
   this is no argument against generating optimized code directly in the
   cross-compiler. But testing both versions is no big deal, as once set up,
   we expect the exact same results/behavior when running the production code
   as when running the debug code, so we can run the same integration tests
   twice.
   - *source maps:* letting GCC generate a source map does not help, as it
   can only produce a source map from production JavaScript code back to the
   "human readable" JS code we fed in. In contrast, we want a direct (!)
   mapping from production JavaScript code back to ActionScript source code.
   While I wouldn't recommend using the "goog" library, I *do* recommend
   GCC as a JavaScript optimizer and as a Java library to generate source maps
   (I already used it successfully in the Jangaroo compiler to generate
   generated-JS->AS3 source maps!).

I think we can only really compare runtime performance and generated code
size of the two approaches when FalconJx has made some progress and we can
cross-compile a larger code base for testing.
Independent from concrete performance results, my feeling is that in the
long term, we are better off relying only on AMD for dependencies / linking
and on polyfills to make old IE as ECMAScript-5-compatible as possible.
Like in Mikes argumentation about the JBurg / BURM approach, I think that
learning the goog API, GCC's annotations and how to generate JS code so
that GCC can really optimize it and chaining our compiler with GCC
introduces unnecessary complexity. Please have a look at my JS prototype
and convince yourself how simple it is and that such magic is not
necessary! The few things you have to know / learn to understand that
format are JavaScript with some ECMAScript 5 extensions and AMD in its
purest form (something.js: define([dep1, dep2], function(dep1, dep2) { code
using dep1, dep2; return something; })). If we could agree to drop IE < 9
support, that would even make all the shim.js and polyfill stuff
(Object.js, Array...js, Function.bind.js) go away. The few files to
simulate is, as, type casts, method binding and trace would also be needed
when using "goog".
This is also a call to Mike and everybody else who thinks that digging into
the prototype would take 2 weeks or more. There's really only a few lines
of code, and some even have comments! ;-) And everything's there to test
and debug live in the browser, without even downloading, installing or
anything...
Here are the links again: live
demo<http://fwienber.github.com/as-js-runtime-prototype/> (if
you had a look at it before, please clean cache for latest version),
source<https://github.com/fwienber/as-js-runtime-prototype>,
download <https://github.com/fwienber/as-js-runtime-prototype/tags>

Greetings
-Frank-


On Thu, Dec 20, 2012 at 8:22 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:

> Hi,
>
> To complete the party, a few brief comments:
>
> - at the moment, I'm not sure what approach to the eventual UI
> frameworks (AS and JS side) will take. FlexJS is one but it doesn't
> (yet) have the feel of something that meets the standards that Flex
> users have come to expect.
>
> - I'm sure that Google's Closure Tools provide us with a lot of the
> language features that native JS is missing. The ones it doesn't
> (easily) provide, we can have the compiler "replace" as that's what
> compilers do, I understand ;-) After we've finished the unit tests for
> FalconJx, we can focus on "goog" compatible JS output and create an -
> I expect very small - utility class to make up for the difference.
>
> - As we are using "goog" and Closure annotations to match AS language
> features, using the rest of Google's Closure Tools is really low
> hanging fruit. The Closure Compiler is not only a JS optimiser, it's
> an actual compiler which provides much of the features usually only,
> if at all, available if you use multiple libraries. The final piece is
> the Closure Builder, which takes an entire "intermediate" (i.e. human
> readable) JavaScript project and, combining all the tools in the
> Closure set, outputs one JS file, culling out dead code and optimising
> the remaining code. I've done a lot of studying on the Closure Tools
> the last few weeks and have become convinced they will provide us with
> a solid language base to start building the UI frameworks on.
>
> Having said all that, I really welcome Frank's POC and I think that we
> will soon be at a point where we can converge all our efforts and
> figure out a common way forward, accepting input from all previous
> trails.
>
> Mike, a question: can the FalconJx compiler tell when a 'regular'
> public variable is being accessed and when a public property (with
> "get" and "set" methods) is being accessed? I'm asking this because if
> it can, it would make it a whole lot easier and would require a whole
> lot less workarounds to get that part of the language translation
> done...
>
> TL;DR: for now I'm moving ahead with "goog" as the basis for the
> language translation, but I look forward to combining the various
> efforts and starting the build of a suitable replacement for the Flex
> SDK :-)
>
> EdB
>
>
>
> On Thu, Dec 20, 2012 at 7:23 PM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
> >
> > Quoting Frank Wienberg <fr...@jangaroo.net>:
> >
> >> 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.
> >
> >
> > Hi Frank,
> >
> > Just so you know I read this, I wanted to write a couple things.
> >
> > FalconJS uses the JBurg BURM which was donated by Adobe. I choose the
> route
> > of an AST visitor framework that is handcoded for the sake of development
> > ease and allowing myself to try something with the time I can a lot for
> this
> > development. As far as I see, FalconJS is not being developed by anybody
> > beyond the fact I read everywhere that it produces "js code". I guess if
> > FlaconJS is going to be considered an alternative, there has to be
> > developers that can work on it, I'm not one of them. I spent 1+ years
> > learning antlr grammar and not about to figure out all the other
> > prerequisites of the FalconJS code.
> >
> >
> > That being said, I have to be honest that I am in no position to either
> > agree or argue with what you have produced. Besides the years of hands on
> > experience you have with JavaScript and ActionScript issues. I would say
> you
> > have a thing or to to add here. :)
> >
> >
> > It seems that right now, there are a handful of developers/community
> members
> > involved in this topic of AS -> JS. I don't know what will change that
> but,
> > it seems like we will need to decide on something that works sooner than
> > later.
> >
> >
> > The truth is, for me to understand what you have done and have an
> opinion I
> > would probably need 2 or more weeks to understand what you have done. :)
> >
> > I'm probably in the position of, "Show me what you want to generate
> based on
> > the semantics involved and I will generate it" mode.
> >
> > For me, my goal as it stands is to use what I have written to generate
> fully
> > compilable ActionScript source code from Falcon's AST model. Once I have
> > unit tested this, I can focus on the JavaScript side without thinking
> about
> > what I have to implement to cover all the AS conversions.
> >
> > I wonder what Erik has to say... I would be interested since he has put
> time
> > into investigation as well.
> >
> > So in closing, I really have not developed javascript applications. I'm
> > interested in this project because having an HTML/JS target for Flex
> would
> > allow me to do some of my audio experiments with an HTML Flex framework
> in
> > the future for mobile applications.
> >
> > This allows me the excuse for myself to put as much time into it as I
> am. :)
> >
> > Mike
> >
> >
> >> 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-
> >>
> >
> > --
> > Michael Schmalle - Teoti Graphix, LLC
> > http://www.teotigraphix.com
> > http://blog.teotigraphix.com
> >
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

Re: [FalconJx] New JavaScript runtime format prototype

[Erik de Bruin <er...@ixsoftware.nl>]

Hi,

To complete the party, a few brief comments:

- at the moment, I'm not sure what approach to the eventual UI
frameworks (AS and JS side) will take. FlexJS is one but it doesn't
(yet) have the feel of something that meets the standards that Flex
users have come to expect.

- I'm sure that Google's Closure Tools provide us with a lot of the
language features that native JS is missing. The ones it doesn't
(easily) provide, we can have the compiler "replace" as that's what
compilers do, I understand ;-) After we've finished the unit tests for
FalconJx, we can focus on "goog" compatible JS output and create an -
I expect very small - utility class to make up for the difference.

- As we are using "goog" and Closure annotations to match AS language
features, using the rest of Google's Closure Tools is really low
hanging fruit. The Closure Compiler is not only a JS optimiser, it's
an actual compiler which provides much of the features usually only,
if at all, available if you use multiple libraries. The final piece is
the Closure Builder, which takes an entire "intermediate" (i.e. human
readable) JavaScript project and, combining all the tools in the
Closure set, outputs one JS file, culling out dead code and optimising
the remaining code. I've done a lot of studying on the Closure Tools
the last few weeks and have become convinced they will provide us with
a solid language base to start building the UI frameworks on.

Having said all that, I really welcome Frank's POC and I think that we
will soon be at a point where we can converge all our efforts and
figure out a common way forward, accepting input from all previous
trails.

Mike, a question: can the FalconJx compiler tell when a 'regular'
public variable is being accessed and when a public property (with
"get" and "set" methods) is being accessed? I'm asking this because if
it can, it would make it a whole lot easier and would require a whole
lot less workarounds to get that part of the language translation
done...

TL;DR: for now I'm moving ahead with "goog" as the basis for the
language translation, but I look forward to combining the various
efforts and starting the build of a suitable replacement for the Flex
SDK :-)

EdB



On Thu, Dec 20, 2012 at 7:23 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
>
> Quoting Frank Wienberg <fr...@jangaroo.net>:
>
>> 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.
>
>
> Hi Frank,
>
> Just so you know I read this, I wanted to write a couple things.
>
> FalconJS uses the JBurg BURM which was donated by Adobe. I choose the route
> of an AST visitor framework that is handcoded for the sake of development
> ease and allowing myself to try something with the time I can a lot for this
> development. As far as I see, FalconJS is not being developed by anybody
> beyond the fact I read everywhere that it produces "js code". I guess if
> FlaconJS is going to be considered an alternative, there has to be
> developers that can work on it, I'm not one of them. I spent 1+ years
> learning antlr grammar and not about to figure out all the other
> prerequisites of the FalconJS code.
>
>
> That being said, I have to be honest that I am in no position to either
> agree or argue with what you have produced. Besides the years of hands on
> experience you have with JavaScript and ActionScript issues. I would say you
> have a thing or to to add here. :)
>
>
> It seems that right now, there are a handful of developers/community members
> involved in this topic of AS -> JS. I don't know what will change that but,
> it seems like we will need to decide on something that works sooner than
> later.
>
>
> The truth is, for me to understand what you have done and have an opinion I
> would probably need 2 or more weeks to understand what you have done. :)
>
> I'm probably in the position of, "Show me what you want to generate based on
> the semantics involved and I will generate it" mode.
>
> For me, my goal as it stands is to use what I have written to generate fully
> compilable ActionScript source code from Falcon's AST model. Once I have
> unit tested this, I can focus on the JavaScript side without thinking about
> what I have to implement to cover all the AS conversions.
>
> I wonder what Erik has to say... I would be interested since he has put time
> into investigation as well.
>
> So in closing, I really have not developed javascript applications. I'm
> interested in this project because having an HTML/JS target for Flex would
> allow me to do some of my audio experiments with an HTML Flex framework in
> the future for mobile applications.
>
> This allows me the excuse for myself to put as much time into it as I am. :)
>
> Mike
>
>
>> 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-
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: [FalconJx] New JavaScript runtime format prototype

[Michael Schmalle <ap...@teotigraphix.com>]

Quoting Frank Wienberg <fr...@jangaroo.net>:

> 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.

Hi Frank,

Just so you know I read this, I wanted to write a couple things.

FalconJS uses the JBurg BURM which was donated by Adobe. I choose the  
route of an AST visitor framework that is handcoded for the sake of  
development ease and allowing myself to try something with the time I  
can a lot for this development. As far as I see, FalconJS is not being  
developed by anybody beyond the fact I read everywhere that it  
produces "js code". I guess if FlaconJS is going to be considered an  
alternative, there has to be developers that can work on it, I'm not  
one of them. I spent 1+ years learning antlr grammar and not about to  
figure out all the other prerequisites of the FalconJS code.


That being said, I have to be honest that I am in no position to  
either agree or argue with what you have produced. Besides the years  
of hands on experience you have with JavaScript and ActionScript  
issues. I would say you have a thing or to to add here. :)


It seems that right now, there are a handful of developers/community  
members involved in this topic of AS -> JS. I don't know what will  
change that but, it seems like we will need to decide on something  
that works sooner than later.


The truth is, for me to understand what you have done and have an  
opinion I would probably need 2 or more weeks to understand what you  
have done. :)

I'm probably in the position of, "Show me what you want to generate  
based on the semantics involved and I will generate it" mode.

For me, my goal as it stands is to use what I have written to generate  
fully compilable ActionScript source code from Falcon's AST model.  
Once I have unit tested this, I can focus on the JavaScript side  
without thinking about what I have to implement to cover all the AS  
conversions.

I wonder what Erik has to say... I would be interested since he has  
put time into investigation as well.

So in closing, I really have not developed javascript applications.  
I'm interested in this project because having an HTML/JS target for  
Flex would allow me to do some of my audio experiments with an HTML  
Flex framework in the future for mobile applications.

This allows me the excuse for myself to put as much time into it as I am. :)

Mike

> 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-
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

On Fri, Dec 21, 2012 at 1:29 AM, Chema Balsas <jb...@gmail.com> wrote:

> Another thing, is that one can use r.js to pipe the require minification
> process into the closure compiler so you're supposed to get the best of
> both worlds...
>

Exactly, that's what I'm trying to get across. Since we produce VanillaJS,
you can pipe into any optimizer/minimizer you want. Maybe the optimization
rate is not as high, but that does no harm when there's not so much to
optimize in the first place!
Talking about piping into Closure, the RequireJS documentation says that
only works (directly) when running RequireJS on Java/Rhino, which is
supposed to be quite slow compared to Node.js. Does anyone have experience
with that combination? Considering that Falcon is written in Java, using
RequireJS on Java/Rhino would be a perfect fit, but of course we also want
it to be fast. I heard of a new JavaScript engine being announced for Java,
does anybody know more?
Another option: is Closure capable of interpreting AMD modules instead of
goog.require(), too, so could it be used instead of RequireJS for linking,
without changing the syntax of define() / require()?

-Frank-

Re: [FalconJx] New JavaScript runtime format prototype

[Chema Balsas <jb...@gmail.com>]

>
> For implementing the actual resource bundle loading, RequireJS also offers
> a mechanism <http://requirejs.org/docs/api.html#i18n>.


You're right! I totally forgot!

Another thing, is that one can use r.js to pipe the require minification
process into the closure compiler so you're supposed to get the best of
both worlds...

2012/12/21 Frank Wienberg <fr...@jangaroo.net>

> On Fri, Dec 21, 2012 at 12:53 AM, Kevin Newman <Ca...@unfocus.com>
> wrote:
>
> > I wonder if you could use the second argument of Object.create to reduce
> > the number of times Object.defineProperties appears in the source (and if
> > it would matter at all).
> >
> > // Example where we create an object with a couple of sample properties.
> > // (Note that the second parameter maps keys to *property descriptors*.)
> > o = Object.create(Object.**prototype, {
> >   // foo is a regular "value property"
> >   foo: { writable:true, configurable:true, value: "hello" },
> >   // bar is a getter-and-setter (accessor) property
> >   bar: {
> >     configurable: false,
> >     get: function() { return 10 },
> >     set: function(value) { console.log("Setting `o.bar` to", value) }
> > }})
> >
> >
> > Kevin N.
> >
> >
> Yes, completely forgot about that.
> May really make the defineClass() code even more concise--I'll have a go on
> this.
> I'd wouldn't expect a performance impact, though. As mentioned before,
> property structure set-up is only done only once for each class.
>
> -Frank-
>

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

On Fri, Dec 21, 2012 at 12:53 AM, Kevin Newman <Ca...@unfocus.com> wrote:

> I wonder if you could use the second argument of Object.create to reduce
> the number of times Object.defineProperties appears in the source (and if
> it would matter at all).
>
> // Example where we create an object with a couple of sample properties.
> // (Note that the second parameter maps keys to *property descriptors*.)
> o = Object.create(Object.**prototype, {
>   // foo is a regular "value property"
>   foo: { writable:true, configurable:true, value: "hello" },
>   // bar is a getter-and-setter (accessor) property
>   bar: {
>     configurable: false,
>     get: function() { return 10 },
>     set: function(value) { console.log("Setting `o.bar` to", value) }
> }})
>
>
> Kevin N.
>
>
Yes, completely forgot about that.
May really make the defineClass() code even more concise--I'll have a go on
this.
I'd wouldn't expect a performance impact, though. As mentioned before,
property structure set-up is only done only once for each class.

-Frank-

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

On Fri, Dec 21, 2012 at 6:29 PM, Alex Harui <ah...@adobe.com> wrote:

> I saw a brief overview of Require and it seemed way more difficult than
> goog.require, but I could be wrong about that.
>

Hi Alex,

using RequireJS may (only) become difficult if you use its advanced
features (e.g. path mappings), but my prototype *only* uses it as an
implementation of the AMD define() function, so all you really have to know
about it is this:

<mymodule>.js:

define(["<dependent module 1>", "<dependent module 2>", ..., "<dependent
module n>"],
  function(dependent_module_1, dependent_module_2, ..., dependent_module_n)
{
    // use dependent_module_1, dependent_module_2, ..., dependent_module_n
    return <value of mymodule>;
});

Then think module = class (or more precise "compilation unit").
In AMD/RequireJS, require(dependencies, callback) is like a define()
without defining a new module, i.e. without the callback function returning
anything.
The semantics is that when loading the application, each define/require
callback function of each (transitively) required module is executed
*exactly once*.

What may make this look a bit more complex / unfamiliar is that you have to
write down dependencies in two flavors: first, as a symbolic reference
(string), second, as the local variable that receives the value of this
reference. But the advantage is that the local variable allows much shorter
and more efficient access of the other module!

   require(["com.acme.my.very.nested.package.MyClass"], function(MyClass) {
     MyClass.doSomething();
   });


In contrast, using goog.require(), you only use one "name" for the
dependent module, as it converts the symbolic reference to a global
namespaced variable with the same name:

   goog.require("com.acme.my.very.nested.package.MyClass");
   com.acme.my.very.nested.package.MyClass.doSomething();

This nested global access is not very efficient, but during optimization,
GCC replaces it by a local variable much like the AMD style does it in the
first place.

To conclude, when running production code, there is not such a big
difference between CommonJS (Closure) and AMD (RequireJS) style. The
differences are the syntax (see above) and how dependencies are resolved
when running the debuggable, dynamically linked code. Syntactically,
CommonJS style might look a bit shorter and more familiar (although I don't
like the repeating fully qualified names), but running the dynamically
linked code in the browser has clear advantages in AMD style, as it is not
really possible to load modules synchronously in the browser (see
discussion in this thread).

Greetings
-Frank-

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

Referring to the require() discussion above, a colleague just pointed me to
this nice article about JavaScript modules by OSGi Guru Peter Kriens, worth
a read:
http://softwaresimplexity.blogspot.fr/2012/06/modules-in-javascript.html
Among other things, it explains some history of CommonJS modules versus AMD.

Re: [FalconJx] New JavaScript runtime format prototype

[Daniel Wasilewski <de...@gmail.com>]

Hehe, is not your bit I am worry about,

And well, OK I will stop posting for a moment, because looks like 
interrupting people at work.
Will back to discussion when will be able to help physically, for now 
just talking during my breaks, because busy working on something that 
pay my bills.

> By all means man keep working on your project. See a scientist always 
> invents meaningful things on their own time, the masses always follow 
> an "intact" idea. I see 
Lol, I will, but this is completely different approach and there is no 
conflict of interest between Flex an my project. I see Flex and FalconJS 
to even help my project if well done.
> the chances of Flex eventually competing in the HTML5/JS sector as 
> above 50%, thus my involvement in this project.
>
An you are my big hope :)

> Don't take life to seriously, it will eat you apart.
>
> Mike
No worries mate. Got the balance right, just sometimes feel I need to 
hit hard in the table, and listening to which scissors will make a noise ;)

Re: [FalconJx] New JavaScript runtime format prototype

[Michael Schmalle <ap...@teotigraphix.com>]

This is funny, it took me less then 2 weeks to rewrite the cross  
compiler for alternate output formats and we are talking about not  
competeing.

A team is only as strong as it's weakest link. That link is not going  
to be me. I have a feeling Daniel this will get ironed out. Once Erik,  
Alex and Frank get this figured out, there will be something next to  
figure out, big deal.

> because I can't see flex to compete in near future.

By all means man keep working on your project. See a scientist always  
invents meaningful things on their own time, the masses always follow  
an "intact" idea. I see the chances of Flex eventually competing in  
the HTML5/JS sector as above 50%, thus my involvement in this project.

Don't take life to seriously, it will eat you apart.

Mike


Quoting Frank Wienberg <fr...@jangaroo.net>:

> On Sat, Dec 22, 2012 at 12:19 AM, Daniel Wasilewski  
> <de...@gmail.com>wrote:
>
>> With all respect, all the talks on this subject just convinced me more to
>> continue my work on BixBite project, because I can't see flex to compete in
>> near future.
>
>
> Dan, what exactly in this discussion made you think that we don't care
> about performance?
> I am with Alex that there is enough time for moaning and complaining about
> alleged performance problems when we have a real-world application
> cross-compiled.
> At the same time, I am convinced that if there is a performance bottleneck,
> it will be in the rendering (canvas, DOM), not in the actual application
> code. For example, our complex browser UI application only spends about 10%
> CPU time in JavaScript code. All the rest is the browser computing styles,
> DOM repaint / reflow, and the actual rendering.
> My experiments with running cross-compiled Flash games on iOS had their
> best performance boost with every iOS update, providing increased canvas
> rendering speed and JavaScript performance.
>
> -Frank-
>

-- 
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com

Re: [FalconJx] New JavaScript runtime format prototype

[Daniel Wasilewski <de...@gmail.com>]

Frank,

I never said that. Everyone cares that's why we having this discussion 
going. But different people different ideas how we should do care :)
And I do agree with Alex too, he was the one who started with very early 
prototype and kick-started this thread.
I see Alex as a guy of lets-do-it rather lets-talk-about-it which is good.

You are absolutely right that comparing raw speed of execution flash vs 
js is one thing, when comes to display list vs DOM Flash is the winner 
again.
That's why we shouldn't make the advantage the bottleneck. Save raw 
power because we will need some more later on for sure.

I do understand your points, but honestly I can't see advantage of mimic 
exact same structure on the code syntax level.
Debugging? Maybe if we speak of production level of the flacon Jx 
itself, but for developers it is absolutely unnecessary.

If I will forget import some class or dependency, my AS3 IDE will tell 
me that before I will hit compile button.
After all, on AS3 side, if everything is done correctly the only thing I 
expect from JS output is to be represented right way. And that I can 
trust compiler to do the job.
Will not be diging and tweaking inside JS directly. If I would, then go 
for any JS framework, why even bother translate this from different 
language?
Because if during a development if something goes wrong with my web app, 
in order to fix it I will back to the source of application, AS3.

Don't get me wrong. I am not moaning, you at least doing something and 
showing us different aspects. I know you have big experience with that 
after jangaroo development. I wish requireJS will prove to be useful but 
it comes with a price. Even if we see adventage mostly for debugging 
purposes for production we have to turn this into optimisation mode. 
Which is another additional step and the whole system will be as strong 
as the weakest link in this chain. And we have quite long already.

It would be useful to see side by side requireJS output and goog or even 
vanilla and see this whole discussion in numbers.
But for this reason as Alex said let's get going. And I am not saying 
don't try your way. Go for it prove your point, show us it can be done 
efficiently.
More options better for us.

Happy Christmas one again!
Dan


On 12/22/2012 11:01 AM, Frank Wienberg wrote:
> On Sat, Dec 22, 2012 at 12:19 AM, Daniel Wasilewski <de...@gmail.com>wrote:
>
>> With all respect, all the talks on this subject just convinced me more to
>> continue my work on BixBite project, because I can't see flex to compete in
>> near future.
>
> Dan, what exactly in this discussion made you think that we don't care
> about performance?
> I am with Alex that there is enough time for moaning and complaining about
> alleged performance problems when we have a real-world application
> cross-compiled.
> At the same time, I am convinced that if there is a performance bottleneck,
> it will be in the rendering (canvas, DOM), not in the actual application
> code. For example, our complex browser UI application only spends about 10%
> CPU time in JavaScript code. All the rest is the browser computing styles,
> DOM repaint / reflow, and the actual rendering.
> My experiments with running cross-compiled Flash games on iOS had their
> best performance boost with every iOS update, providing increased canvas
> rendering speed and JavaScript performance.
>
> -Frank-
>

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

On Sat, Dec 22, 2012 at 12:19 AM, Daniel Wasilewski <de...@gmail.com>wrote:

> With all respect, all the talks on this subject just convinced me more to
> continue my work on BixBite project, because I can't see flex to compete in
> near future.


Dan, what exactly in this discussion made you think that we don't care
about performance?
I am with Alex that there is enough time for moaning and complaining about
alleged performance problems when we have a real-world application
cross-compiled.
At the same time, I am convinced that if there is a performance bottleneck,
it will be in the rendering (canvas, DOM), not in the actual application
code. For example, our complex browser UI application only spends about 10%
CPU time in JavaScript code. All the rest is the browser computing styles,
DOM repaint / reflow, and the actual rendering.
My experiments with running cross-compiled Flash games on iOS had their
best performance boost with every iOS update, providing increased canvas
rendering speed and JavaScript performance.

-Frank-

Re: [FalconJx] New JavaScript runtime format prototype

[Daniel Wasilewski <de...@gmail.com>]

I was trying hard to get the best performing framework in AS3 ever. 
Pushing platform to its limits. And I made it happen.
I made it the faster AS3 framework ever. Maybe broken few rules, maybe 
is not pure MVC, However,

Let this picture speak for itself.

http://bixbite.org/bixbite.jpg

With a right approach it is possible to write JS that performs better 
than Flash Player these days. With a pure JS you can get even better 
performance on IE and Opera as well as mobile devices. Writing code to 
be optimised for one particular browser will always favour one solution 
over another, and put that only solution forward. Lets not get involved 
in browser wars. This is completely different subject. But even so, all 
4 major browser players can outperform flash player, or at least match 
it. Do not ruin this opportunity establishing JS output for Flex.

With all respect, all the talks on this subject just convinced me more 
to continue my work on BixBite project, because I can't see flex to 
compete in near future.

Dan

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

On Fri, Dec 21, 2012 at 5:43 PM, Kevin Newman <Ca...@unfocus.com> wrote:

> BTW, what do you mean by startup times - do you mean the actual parsing,
> loading and setting up of the classes (I think this)? Or is there an speed
> issue with class instantiation as well (it seems like no)? I'm not actually
> familiar enough with require.js just yet to know how that works.


Only the former one. The require() (or rather define()) callbacks are only
needed for getting "acquainted to your dependencies". As class
instantiation is performed synchronously, you wouldn't even have the chance
to wait for a dependent class to load. In my prototype, the only runtime
overhead of a class instantiation (new A()) comes from the support for
"lazy class initialization".

Thanks for supporting my AMD approach by pointing at the ES-harmony spec!
That was what I meant by being "more standard" than goog.require().

I also had a closer look at TypeScript and because it claims "enabling
ECMAScript 6 today", thought of using it as a compile target. I scrapped
that idea in the meantime for reasons I'll explain in an upcoming blog post
on the Jangaroo blog.

About your idea to use DOM elements to have JavaScript objects with
functioning getters/setters in IE8, yes, it's a wild idea. But I am afraid
that a) DOM elements inherit too many members you don't want to have and
you'd have to hide / get rid of and b) there will probably a performance
problem. Bernd Paradies once said on his blog that there were even
performance problems with getters/setters in several browsers that fully
supported the feature and thus he wanted to emulate them through normal
methods. While I assume the performance problem has gone away in the
meantime, we could still follow that approach to support IE8. After all, we
should have all the information at hand whether a property is a "real"
field or actually a getter/setter and rewrite the calling code accordingly.
The downside is that such properties could not be used straight-forwardly
from plain JavaScript code.

Greetings
-Frank-

Re: [FalconJx] New JavaScript runtime format prototype

[Alex Harui <ah...@adobe.com>]

Startup Time must meet a certain threshold of acceptability before enough
folks will use your app and worry about runtime performance.

IMO, startup time has several metrics:
-First visual indicator: a progress bar or splash screen, enough to tell you
that something is running
-first screen: enough to tell what is running
-first interaction: when you can start using the app
-first goal: when you feel like you've accomplished some task with the app.

Small apps collapse all of these into one, but the framework needs to
support them being separate in really large apps.

Also, IMO, standards are a double-edged sword.  It is nice to have the
consistency in your targets, but they can also be heavy and slow.  It isn't
clear we should just automatically use any standard.  We chose the DOM event
model in Flash/Flex because Macromedia was all about standards at the time,
and I'm not clear it was the right decision.  More efficient notification
schemes were certainly possible, especially outside the actual display list.
I saw a brief overview of Require and it seemed way more difficult than
goog.require, but I could be wrong about that.

There's some adage about premature optimization.  These conversations are
starting to feel like that.  Let's get more code running, try to get people
to use it, then figure out where we need to optimize.  One of the good/bad
things about JS it that it seems infinitely malleable.

On 12/21/12 8:43 AM, "Kevin Newman" <Ca...@unFocus.com> wrote:

> My personal preference is to prioritize runtime performance over startup
> times, though keeping in mind that startup time can be an issue,
> especially for mobile. We don't want this thing to start up horrendously
> slowly (I don't think that'll be the case here though). The best way to
> measure will be to actually measure. Maybe a jsperf comparison of the
> linked JS file, and a closure method is worth exploring (both startup
> and runtime).
> 
> BTW, what do you mean by startup times - do you mean the actual parsing,
> loading and setting up of the classes (I think this)? Or is there an
> speed issue with class instantiation as well (it seems like no)? I'm not
> actually familiar enough with require.js just yet to know how that works.
> 
> For those on the list that may not be aware, AMD/require.js modules are
> [likely] coming to JS as they are currently in the ES-harmony spec:
> http://wiki.ecmascript.org/doku.php?id=harmony:modules
> 
> So are classes for that matter:
> http://wiki.ecmascript.org/doku.php?id=harmony:classes
> 
> These are the patterns that TypeScript is currently targeting
> (AMD/require), and they are also increasingly popular by JS programmers
> (being spec backed to a degree helps), so Flex would be in good company
> if we choose to go the require.js/modules route, as Frank has done with
> his vanilla.js with require.js prototype.
> 
> Kevin N.
> 
> P.S. It sounds like a bad idea, but I wonder if anyone has ever tried to
> to use IE's Element as the base class for everything (instead of
> Object), to gain access to getter/setter in IE lt 9. Does an Element
> have to be on the DOM tree for get/set to work? I guess that would blow
> up memory use, and maybe slow down all property access, so it's maybe
> not useful for serious work (unless some jsperf charts shows it is), but
> I'm still curious if it could work.
> 
> 
> On 12/21/12 5:56 AM, Frank Wienberg wrote:
>> We could also move all the AS3 helper functions (as, is, bind, cast, etc.)
>> into one module (maybe even the same module), but that would actually
>> introduce one more property dereferencing when using these functions at
>> application run time (in contrast to start-up time, at which classes and
>> interfaces are defined, where ultimate performance is not so much of an
>> issue).
>> 
>> What do you think?
> 

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: [FalconJx] New JavaScript runtime format prototype

[Kevin Newman <Ca...@unFocus.com>]

My personal preference is to prioritize runtime performance over startup 
times, though keeping in mind that startup time can be an issue, 
especially for mobile. We don't want this thing to start up horrendously 
slowly (I don't think that'll be the case here though). The best way to 
measure will be to actually measure. Maybe a jsperf comparison of the 
linked JS file, and a closure method is worth exploring (both startup 
and runtime).

BTW, what do you mean by startup times - do you mean the actual parsing, 
loading and setting up of the classes (I think this)? Or is there an 
speed issue with class instantiation as well (it seems like no)? I'm not 
actually familiar enough with require.js just yet to know how that works.

For those on the list that may not be aware, AMD/require.js modules are 
[likely] coming to JS as they are currently in the ES-harmony spec:
http://wiki.ecmascript.org/doku.php?id=harmony:modules

So are classes for that matter:
http://wiki.ecmascript.org/doku.php?id=harmony:classes

These are the patterns that TypeScript is currently targeting 
(AMD/require), and they are also increasingly popular by JS programmers 
(being spec backed to a degree helps), so Flex would be in good company 
if we choose to go the require.js/modules route, as Frank has done with 
his vanilla.js with require.js prototype.

Kevin N.

P.S. It sounds like a bad idea, but I wonder if anyone has ever tried to 
to use IE's Element as the base class for everything (instead of 
Object), to gain access to getter/setter in IE lt 9. Does an Element 
have to be on the DOM tree for get/set to work? I guess that would blow 
up memory use, and maybe slow down all property access, so it's maybe 
not useful for serious work (unless some jsperf charts shows it is), but 
I'm still curious if it could work.


On 12/21/12 5:56 AM, Frank Wienberg wrote:
> We could also move all the AS3 helper functions (as, is, bind, cast, etc.)
> into one module (maybe even the same module), but that would actually
> introduce one more property dereferencing when using these functions at
> application run time (in contrast to start-up time, at which classes and
> interfaces are defined, where ultimate performance is not so much of an
> issue).
>
> What do you think?

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

Good morning,

I just followed your advice and simplified defineClass.js a bit (pushed to
GitHub repo and GitHub pages, so you should see the update, maybe after
cleaning your browser cache).

Another thing:
Because defineInterface.js is really so small I thought about uniting both
define*.js into one file / AMD module.
Would look like this:
define(["runtime/runtime.js"], function(AS3) {
  function A() {
    ...
  }
  // either...
  AS3.class_(A, ...);
  // ...or
  AS3.interface_("com.acme.I", []);
});

Of course, AS3 could be dynamically renamed by the compiler to any free
variable name.

We could also move all the AS3 helper functions (as, is, bind, cast, etc.)
into one module (maybe even the same module), but that would actually
introduce one more property dereferencing when using these functions at
application run time (in contrast to start-up time, at which classes and
interfaces are defined, where ultimate performance is not so much of an
issue).

What do you think?

-Frank-

On Fri, Dec 21, 2012 at 12:53 AM, Kevin Newman <Ca...@unfocus.com> wrote:

> I wonder if you could use the second argument of Object.create to reduce
> the number of times Object.defineProperties appears in the source (and if
> it would matter at all).
>
> // Example where we create an object with a couple of sample properties.
> // (Note that the second parameter maps keys to *property descriptors*.)
> o = Object.create(Object.**prototype, {
>   // foo is a regular "value property"
>   foo: { writable:true, configurable:true, value: "hello" },
>   // bar is a getter-and-setter (accessor) property
>   bar: {
>     configurable: false,
>     get: function() { return 10 },
>     set: function(value) { console.log("Setting `o.bar` to", value) }
> }})
>
>
> Kevin N.
>
>

Re: [FalconJx] New JavaScript runtime format prototype

[Kevin Newman <Ca...@unFocus.com>]

I wonder if you could use the second argument of Object.create to reduce 
the number of times Object.defineProperties appears in the source (and 
if it would matter at all).

// Example where we create an object with a couple of sample properties.
// (Note that the second parameter maps keys to *property descriptors*.)
o = Object.create(Object.prototype, {
   // foo is a regular "value property"
   foo: { writable:true, configurable:true, value: "hello" },
   // bar is a getter-and-setter (accessor) property
   bar: {
     configurable: false,
     get: function() { return 10 },
     set: function(value) { console.log("Setting `o.bar` to", value) }
}})


Kevin N.

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

On Thu, Dec 20, 2012 at 11:23 PM, Daniel Wasilewski <de...@gmail.com>wrote:

> http://jsperf.com/global-**namespace-chain-vs-string-**
> based-local-modules/12<http://jsperf.com/global-namespace-chain-vs-string-based-local-modules/12>
>
> This is what worries me the most.


If I understand this test correctly, it measures the overhead of using
require() to hand over references and comes to the conclusion that there is
a considerable overhead.
Note that my prototype uses require() / define() only to set up static
inter-class-dependencies. Once a require() call returns, the result is a
local variable (the parameter) and is accessed directly in the outer
lexical scope of the defined functions -- there can't be any real overhead.
So I understand the performance impact can only negatively influence
application startup or dynamically loading application modules. This is a
point, but what I am more interested in is performance once the application
has started. We use ActionScript to build single-page RIAs, so start-up
time is not so much a concern.

-Frank-

Re: [FalconJx] New JavaScript runtime format prototype

[Daniel Wasilewski <de...@gmail.com>]

http://jsperf.com/global-namespace-chain-vs-string-based-local-modules/12

This is what worries me the most.

On 12/20/2012 9:55 PM, Frank Wienberg wrote:
> Er... I hope I already did. Did you read by previous post in this thread?
>
> On Thu, Dec 20, 2012 at 10:49 PM, Daniel Wasilewski <de...@gmail.com>wrote:
>
>> Please enlight us on why you think goog is not a good solution.

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

On Thu, Dec 20, 2012 at 11:34 PM, Daniel Wasilewski <de...@gmail.com>wrote:

> I don't know why but it looks like it iss adding extra stars:
>
> http://fwienber.github.**com/**as-js-runtime-prototype/<http:**
> //fwienber.github.com/as-js-**runtime-prototype/<http://fwienber.github.com/as-js-runtime-prototype/>
>
> I obviously realised that, and was able to see your sources,


Sorry again for the garbled link. Using gmail...


> but it didn't change my mind about impact on performance using RequiredJS.
> It is putting you down to JQuery level pretty much.
>

See above, I disagree. JQuery introduces considerable runtime overhead,
even while the application is running.
Again, I propose to use RequireJS for class linking only, so for a normal
application, all define()/require() callbacks are done during application
start-up and then never again.
We would have to create a performance comparison that takes into account
that a class is only loaded once (involving a require() callback), but
instantiated many times without that overhead, and also that an application
does usually not consist of ten-thousands of classes (while
ten-thousands of objects are not unlikely at all). The complex enterprise
RIA we develop runs with a bit over 3000 classes.
Even if using AMD would increase start-up time by some linear factor, do
you really think start-up time / performance is so crucial that you would
sacrifice a clean dependency management that helps avoiding global
namespace pollution and allows even for circular static dependencies?

-Frank-


>
> Dan
>
>
>
>
> On 12/20/2012 10:27 PM, Frank Wienberg wrote:
>
>> Oops? Can you give me a pointer which link does not work? I can't
>> reproduce.
>> Maybe the new subdomain created by GitHub pages (fwienber.github.com) is
>> not "spread around the world" yet?
>>
>> On Thu, Dec 20, 2012 at 11:18 PM, Daniel Wasilewski <devudesign@gmail.com
>> >wrote:
>>
>>  Btw, yes I have checked your links, but stuff on github is 404.
>>>
>>
>

Re: [FalconJx] New JavaScript runtime format prototype

[Daniel Wasilewski <de...@gmail.com>]

I don't know why but it looks like it iss adding extra stars:

http://fwienber.github.**com/as-js-runtime-prototype/<http://fwienber.github.com/as-js-runtime-prototype/

I obviously realised that, and was able to see your sources, but it didn't change my mind about impact on performance using RequiredJS.
It is putting you down to JQuery level pretty much.

Dan



On 12/20/2012 10:27 PM, Frank Wienberg wrote:
> Oops? Can you give me a pointer which link does not work? I can't reproduce.
> Maybe the new subdomain created by GitHub pages (fwienber.github.com) is
> not "spread around the world" yet?
>
> On Thu, Dec 20, 2012 at 11:18 PM, Daniel Wasilewski <de...@gmail.com>wrote:
>
>> Btw, yes I have checked your links, but stuff on github is 404.

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

Oops? Can you give me a pointer which link does not work? I can't reproduce.
Maybe the new subdomain created by GitHub pages (fwienber.github.com) is
not "spread around the world" yet?

On Thu, Dec 20, 2012 at 11:18 PM, Daniel Wasilewski <de...@gmail.com>wrote:

> Btw, yes I have checked your links, but stuff on github is 404.

Re: [FalconJx] New JavaScript runtime format prototype

[Daniel Wasilewski <de...@gmail.com>]

Btw, yes I have checked your links, but stuff on github is 404.

On 12/20/2012 9:55 PM, Frank Wienberg wrote:
> Er... I hope I already did. Did you read by previous post in this thread?
>
> On Thu, Dec 20, 2012 at 10:49 PM, Daniel Wasilewski <de...@gmail.com>wrote:
>
>> Please enlight us on why you think goog is not a good solution.

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

On Thu, Dec 20, 2012 at 11:12 PM, Daniel Wasilewski <de...@gmail.com>wrote:

> You keep saying, for debugging reasons, your goal is to mimic as3 vs JS
> output into even exact line of code.
>

Only in the debuggable compiler output. The optimized production code might
look like machine code.


> We are about to get compiler that can optimise everything before it will
> get translated to JS, we don't care about the output in terms of accuracy
> of representing input.
> We do care about efficiency of how it performs and do, what input platform
> wants it to do without errors. Our debugger and protector should be the
> input platform.
>

You are arguing like the Java GWT guys: "we provide you with a 'hosted
environment' for developing/debugging. If everything works, your
application is optimized and deployed to the Web."
The flaw is that the browser is not such a reliable environment like a
Java- or Flash-VM. If you have browser-specific bugs in your highly
optimized, un-debuggable code, you are screwed.
JavaScript source maps (see above) might overcome this problem, but they
are not there yet.


> We have a descent tools to make it happen these days. Even if my code
> needs to get over heavy lifting, closure compiler etc, I don't care.
>

My argumentation is that when we have fully-resolved ActionScript-AST or
ABC as input format, we can deliver much better optimizations that Closure
which has to reverse-engineer non-dynamic structures from JavaScript code
(that's why it needs the annotations).


> JS  in many cases is faster that Flash Player these days. Sad, but true
> statement. I still believe is possible to translate AS3 into JS without
> loosing those benefits.
>

Why should we lose this benefit just because in debug mode, we keep
ActionScript code untouched if it can be executed in JavaScript as-is?


> It is possible to write AS3 language like in pure Java script, not other
> way around. For this reason I cannot accept something that for sake of just
> accurate translation ruin performance.
>

No, of course I'm trying to achieve both: accurate translation *and*
performance!


>
> If flex will not get to this point, better look at Haxe JS output. Because
> is the best performer for time being.
>

I had a look at Haxe JS output and was a bit disappointed. They tailored
the language towards being easy to translate to JavaScript and sometimes
chose the least common denominator, for example by abandoning private
members. They generate nothing like lazy class initialization (running
static code of a class exactly when FlashPlayer would). My goal is that at
least on language level, most ActionScript 3 code runs as-is, otherwise we
are implementing a different language.

-Frank-

Re: [FalconJx] New JavaScript runtime format prototype

[Daniel Wasilewski <de...@gmail.com>]

Don't get me wrong, I am asking about how 'goog' or vanilla and your 
approach solition performs on various browsers.

You keep saying, for debugging reasons, your goal is to mimic as3 vs JS 
output into even exact line of code.

We are about to get compiler that can optimise everything before it will 
get translated to JS, we don't care about the output in terms of 
accuracy of representing input.
We do care about efficiency of how it performs and do, what input 
platform wants it to do without errors. Our debugger and protector 
should be the input platform.
We have a descent tools to make it happen these days. Even if my code 
needs to get over heavy lifting, closure compiler etc, I don't care.

JS  in many cases is faster that Flash Player these days. Sad, but true 
statement. I still believe is possible to translate AS3 into JS without 
loosing those benefits.
It is possible to write AS3 language like in pure Java script, not other 
way around. For this reason I cannot accept something that for sake of 
just accurate translation ruin performance.

If flex will not get to this point, better look at Haxe JS output. 
Because is the best performer for time being.

Dan

On 12/20/2012 9:55 PM, Frank Wienberg wrote:
> Er... I hope I already did. Did you read by previous post in this thread?
>
> On Thu, Dec 20, 2012 at 10:49 PM, Daniel Wasilewski <de...@gmail.com>wrote:
>
>> Please enlight us on why you think goog is not a good solution.

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

Er... I hope I already did. Did you read by previous post in this thread?

On Thu, Dec 20, 2012 at 10:49 PM, Daniel Wasilewski <de...@gmail.com>wrote:

> Please enlight us on why you think goog is not a good solution.

Re: [FalconJx] New JavaScript runtime format prototype

[Daniel Wasilewski <de...@gmail.com>]

Please enlight us on why you think goog is not a good solution.

On 12/20/2012 9:06 PM, Frank Wienberg wrote:
> Hi Alex,
>
> thanks for your prompt reply anyway! I don't think this is very urgent, I
> only felt the need to provide a concrete alternative to the "goog" approach
> before everybody runs off in that direction... ;-)
> I'd appreciate your opinion on the topic and look forward to your response.
> Best,
> -Frank-
>
>
> On Thu, Dec 20, 2012 at 8:23 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> 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
>>
>>

Re: [FalconJx] New JavaScript runtime format prototype

[Frank Wienberg <fr...@jangaroo.net>]

Hi Alex,

thanks for your prompt reply anyway! I don't think this is very urgent, I
only felt the need to provide a concrete alternative to the "goog" approach
before everybody runs off in that direction... ;-)
I'd appreciate your opinion on the topic and look forward to your response.
Best,
-Frank-


On Thu, Dec 20, 2012 at 8:23 PM, Alex Harui <ah...@adobe.com> wrote:

> 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
>
>

Re: [FalconJx] New JavaScript runtime format prototype

[Alex Harui <ah...@adobe.com>]

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