flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Zwaga <rol...@stackandheap.com>
Subject Re: [ASJS] Integration with existing JS libraries and components
Date Sat, 26 Jan 2013 13:38:56 GMT
Hey Erik,

comments inline as usual:

On 26 January 2013 08:28, Erik de Bruin <erik@ixsoftware.nl> wrote:

> Hi,
> > My main problem with using Closure is that it introduces a second parsing
> > and manipulation
> > pass while, IMHO, all of the necessary work can be done inside Falcon
> since
> > all necessary
> > information is contained within the AST. Therefore implementing the whole
> > shebang inside
> > Falcon will be faster.
> The goal is to move the functionality that is currently in the ant
> script into FalconJx. After all, it's just 2 calls to a Python script
> and some file manipulation.

Ehm, does that mean that FalconJx will have a dependency on Python as well?
That would be another dependency then and also making the install process
quite a bit more complicated. Or am I misunderstanding?

> As to the 'second pass': that will always be needed, as the Falcons
> are compilers, not optimisers. It has been discussed and dismissed
> that we would write our own JS optimiser; there are so many excellent
> ones available all over the place. Using the Closure Compiler gives us
> the added advantage of doing an actual re-compile of the JS, instead
> of plain optimisation. This means that it can achieve incredibly
> efficient and small code. Please look at the 'release' output from my
> proof of concept.

Ok, I guess I missed that discussion, I thought eventually it would be a
idea to write our own optimizer. Since working straight off the original AST
sounded to me like a the most efficient choice. But whatever the group
decided, then

> > Plus it removes a dependency, which is always good,
> > again IMHO.
> How is replacing Closure for RequireJS removing a dependency?

The way I see it the generated JS will already have a dependency on one ore
more JS
libraries (such as your vanilla SDK), so adding requireJS is just another
JS lib.
While I saw Closure more as a dependency on a tool (a tool that,
potentially, has dependencies
on other libraries or tools as well). So I agree with you to a certain
extend that it is indeed
replacing one dependency with another, but requireJS seems to be more
lightweight, that is all.

> > The fact that your requireJS approach is also asynchronous is a big boon
> as
> > well. It means
> > an application could be loaded incrementally much easier, and from what I
> > understand
> > incredibly granular.
> The same goes for Closure. Please look at my previous email for more
> on this particular topic.

Yes, I saw the other email, so my apologies for that confusion. I was
relying on faulty info apparently.

> Again, I like the approach you mention as an excellent addition to the
> future of Flex. I don't mind (much ;-)) that you prefer one solution
> over another. What I do mind is when the choice is made based on
> faulty information. This email is merely intended to put to rest some
> of the FUD that seems to be going around about Closure.

Alright, thanks for clearing all of this up :)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message