Hey Erik, comments inline as usual:
On 26 January 2013 08:28, Erik de Bruin <e...@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
