Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAJs+wW2Zxyawh8VQ=jFkbBk-Fqffmf1uOcwYaxVMJf-J5P-p9A@mail.gmail.com>
References: 
 <CAAgciqp7E4WxyQFvo9subcEihH-vaxT_NLm90Rjm+FyrGAOCCg@mail.gmail.com>
	<CAJs+wW3buzu5svXVCy4R23n5wHVh3ycsxi6=JxwKgcGbtzCDQw@mail.gmail.com>
	<CAAgciqq=gWhWokifN3HzKoFFMaPa2Ak1JAre=5wcnBWAc4eVOQ@mail.gmail.com>
	<CAJs+wW1hY=gwGN9RnYy1evkYv38-CQshvi6dVnLWTs=yCNFdQA@mail.gmail.com>
	<CAAgciqq0ge1p2aS-r6NBAnQD173v86-W1vzUvkyzgUcaR9TB=w@mail.gmail.com>
	<CAD8jDG+TB0YFA6ug+gdyqJNsC7HuDaq_8OZhvwYV1JYcP4BRKA@mail.gmail.com>
	<CAJs+wW21e-t2=esX5ZGVpWYE4+--2jR=RKaX3_R=i_qdtFmzfA@mail.gmail.com>
	<CAD8jDGKr4JfX9rV_=KgCej1zGvYWEpSvO83LevZr4b7rpx3UCA@mail.gmail.com>
	<CAJs+wW2D+6rU98NNGZjQprobaCRGEYcxm2dJjKMDbHhfqEttMQ@mail.gmail.com>
	<CAD8jDG+Kvf7LJOcBeTnkzKM+wSKmKxPThRib22gnp9PE6LHJ+g@mail.gmail.com>
	<CAJs+wW2Zxyawh8VQ=jFkbBk-Fqffmf1uOcwYaxVMJf-J5P-p9A@mail.gmail.com>
Date: Sun, 27 Jan 2013 22:55:27 +0100
Message-ID: 
 <CAD8jDGJKQxSqasrSzyHHPyWF23gTNMvvf-o_fq5wTJNdP9bSLA@mail.gmail.com>
Subject: Re: [ASJS] Integration with existing JS libraries and components
From: Frank Wienberg <frank@jangaroo.net>
To: dev@flex.apache.org
Content-Type: multipart/alternative; boundary=047d7bea3518e8f81604d44c3740

--047d7bea3518e8f81604d44c3740
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jan 27, 2013 at 5:52 PM, Erik de Bruin <erik@ixsoftware.nl> wrote:

> > I think I can now pinpoint the difference to RequireJS: It is in the
> > existence of deps.js.
> > deps.js says it's generated, and seems to be the extracted dependencies
> of
> > all the other JS files, right? Aha, so this is how the necessary scripts
> > get loaded in advance. And this is where you need the build tool: To
> > extract the dependencies and generate this additional file deps.js.
>
> No, the deps.js is just a list of ALL the require statements in the
> entire library + application (indeed generate during the publish
> process. However, ONLY the files listed that are ACTUALLY USED are
> loaded dynamically by the code in 'base.js'. If you look in either
> Chrome or FF you can see which script files are actually loaded and
> compare that list agains the 'deps.js' list. You'll see that the only
> file hard-coded into the HTML is 'base.js', which is the equivalent of
> 'require.js' in your approach. All the other script files are loaded
> dynamically, in order, based on the dependencies as given in their
> contents, much like with Require.js.
>
> > With the AMD approach, you can re-generate exactly one file and reload in
> > the browser, and everything will work.
>
> Same with the 'goog' way.


> > One more thing, something I didn't find out is how deps.js gets loaded.
> It
> > has to be triggered by base.js somehow. Can you please explain?
>
> It's a kind of magic :-) As I explain above, 'base.js' uses it,
> together with the 'provide' and 'require' statements to figure out
> which other project files to load. Let me press that point, since it
> seems to be pivotal to the discussion: ONLY the files that are
> ACTUALLY needed to run the application are loaded into the browser.
> NOT all the files in 'deps.js' and certainly not all the files in the
> Closure Library.
>
>
To get one misunderstanding out of the way, I never claimed base.js would
load more scripts than required.
I just wonder all the time how base.js can know *in advance* which scripts
to load. And deps.js seems to be the answer to that question.
Believe me, I'm just trying to understand how it works and where it is
substantially different from RequireJS.
So deps.js is not only the list of all require statements starting at the
"main" class, but as you say a "list of ALL the require statements in the
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
dependent module is needed, so just generating the class' own output file
would result in a non-working state. And (re-)generating deps.js is exactly
the pre-processing step AMD so elegantly avoids from the start.


> > Okay, we can wait for that, but since Michael says what I did with
> Jangaroo
> > 3 is easily re-implemented in Falcon, why not compare now? The output
> > will/should be very very similar to what the Jangaroo 3 output looks like
> > now, e.g. the one of the Open Flash Chart example.
> > Another idea would be I take your example code (or any other code you
> want)
> > 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.


> I think you're not going to convince me to throw away all the work I
> did so far (and I strongly believe is at least as valid for our
> purpose as what you are suggesting) and start the whole process again
> based on your approach, only to do away with one step in the build
> process of the intermediate output (the 'deps.js' you object to plays
> no role in generating the 'release' code). I'll continue development
> of my proof of concept and I hope to find other contributors willing
> to help out.
>

Nobody asks you to throw away your work. We are discussing which library /
tool better supports the JS target of Apache Flex. From a code-generation
point of view, our approaches are fairly similar, and there are suggestions
(see Roland's thread) that it should be easy to switch between such similar
code output patterns. So we'll probably have both of them.
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
opinion on my warning that the input language for GCC is a dialect of
JavaScript (restrictions, extensions), not standard JavaScript.

-Frank-

--047d7bea3518e8f81604d44c3740--