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


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

Roland

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