flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: [ASJS] Integration with existing JS libraries and components
Date Mon, 28 Jan 2013 07:36:56 GMT

> entire library + application". My example was that you change a single
> file, but change it in a way that you add a dependency. Without
> re-generating deps.js, base.js could not know in advance that the newly

We're talking AS -> JS cross compilation. So changing one file would
be changing one AS file. To turn that AS file into a JS file needs a
compilation step. The generation of 'deps.js' is part of the
compilation step. So, in the scenario we're discussing, the
regeneration is of no consequence. Also, more importantly, 'deps.js'
is only needed for the 'intermediate' output, not in the release
output. I think if we're going to be comparing anything, we should be
comparing 'production/release' code, not 'convinience/intermediate'
code, right?

>> > and compile it with Jangaroo 3 and also deploy the output. What do you
>> > think?
>> I enabled "View Source" on the Flash output, so you can grab the AS
>> source and put it through Jangaroo if you please. You can also pick up
>> Alex's FlexJS source and do the same with that.Might be interesting to
>> see what comes out and compare the various approaches when using a
>> different compiler.
> Yes, I'll try to do that, but except from the deps.js file discussed above
> I expect the difference to be rather small.

So, if 'deps.js' is not needed -- like it's not needed in the
'release' output of my proof of concept -- there really isn't any
practical difference between our approaches?

> However, I still think it is better to consolidate than to offer too much
> to chose from (where it brings no benefit). And I'd still like to hear your

I'd love to consolidate, and I'm reading your Wiki pages with interest
on how to tackle some of the language inconsistencies between AS and
JS. I just wish that we could work together on code, instead of going
round and round on theory and relative merits of two different but
equal approaches.

> opinion on my warning that the input language for GCC is a dialect of
> JavaScript (restrictions, extensions), not standard JavaScript.

If by GCC you are referring to the compiler, [1] should answer your
question. The Google Tools (which include, but are not limited to, the
compiler) like to have their JavaScript in a 'pseudo-classical'
pattern, but that doesn't mean they won't gladly handle other
patterns, like "AMD". The JSDoc annotations are only there to help the
GCC do an even better job, but are not required for the code to
function as coded. What about the "input language for GCC" do you
regard as a dialect of "vanilla JS"?


1: https://developers.google.com/closure/compiler/faq#restrictions

Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

View raw message