On Mon, Jan 28, 2013 at 8:36 AM, Erik de Bruin <e...@ixsoftware.nl> wrote:
> Hi, > > > 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? > > No, I *do* talk about the "intermediate" code, as I see it as the *primary* compilation result, and the production/release code as a derived artifact. The former is the code developers see during debugging their application. Nobody cares about how the production code looks like as long as it works, it concise and performant. Self-cite: > I know that for some Flex folks, development turn-around to the browser > is not such an important issue, as they see the JS output more like an > alternative deployment format, so they'll test in Flash or AIR and only > deploy and QA in HTML5. I see a different scenario, where Flex is > used to develop primarily for HTML5, which makes fast development > turn-around to the browser a necessity. > >> > 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? > I have some experience in building an incremental-compiling IDE plugin, and believe me, it *does* make a practical difference. Generating one output file for each source input file was straight-forward, but generating additional files per compile run was introducing complexity and made things less reliable. Sorry, I just don't like that deps.js file, it seems so monolithic and redundant. > > 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. > I'd still like to, but Mike talked me out of it ;-) He said currently it'd be more help if I continued on the Wiki spec, so I did that. I do think that features like compilation unit initialization (correct static code execution time) are orthogonal to the goog vs. RequireJS discussion and should make it into the goog solution as well. > > 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"? > > EdB > > 1: https://developers.google.com/closure/compiler/faq#restrictions > > I am talking about this passage from my initial response on Closure: > The problem I have is that Closure is not only a runtime library plus > a build tool, but it defines *extensions and restrictions to the > JavaScript language itself*. And because it defines extensions > *and* restrictions, I consider the input Closure requires *another* > *language* than JavaScript. This makes the decision for Closure > much more than whether we want to use synchronous or asynchronous require. > > Look at the long list of > restrictions<https://developers.google.com/closure/compiler/docs/limitations> > the Closure Compiler imposes > on your JavaScript code. Especially when using ADVANCED_OPTIMIZATIONS > (without which using Closure misses much of its value), you cannot > expect your completely strict-mode, jslinted, cross-browser-compatible, > fully-tested JavaScript code to still work. > There are many > annotations<https://developers.google.com/closure/compiler/docs/js-for-compiler> > you need to use and patterns<https://developers.google.com/closure/compiler/docs/api-tutorial3> you need > to follow to take advantage of ADVANCED_OPTIMIZATIONS mode. > When you use a wrong annotation (or no annotation where one was > needed), the optimized code works incorrectly, thus the annotations > are not "just for better optimization", but actually part of the "goog" > language semantics, at least if you use ADVANCED_OPTIMIZATIONS. > That sounds to me like the JavaScript code Closure wants as input is > a custom (proprietary) version of JavaScript, and not the JavaScript we know.
