One thing I'm not sure has been mentioned here is localization support. It's not a requirement for the pure AS->JS translation, but I have the sense it's quite important for Flex.
I think the Closure Compiler offers Templates and some kind of internationalization automation, which could come in handy. Otherwise, we'll probably need to use another templating engine or develop our own. Not rooting for anyone here, by the way, just throwing some more concerns into the mix ;) Cheers, Chema 2012/12/21 Erik de Bruin <e...@ixsoftware.nl> > > This the overall impression I have with the GCC approach: it introduced > > complexity only to optimize it later on. > > I think we better avoid complexity in the first place! > > Well, it introduces "complexity" in order to facilitate BETTER > optimisation later on. So, by avoiding that "complexity" - simply > because we like "simplicity" - we'd end up with an inferior product. > > > For goog.provide and goog.require, RequireJS provides alternatives that > > better fit our needs: asynchronous module loading much better reflects > the > > nature of script loading in the browser. Synchronous require calls were > > made for Node.js or other environments that allow to load scripts > > synchronously. RequireJS concentrates exactly on that task and does > nothing > > else. > > The point of the Closure Builder is that there are no modules. It's > all one file (and a small one at that). There is no need to manage the > loading of any modules (with the added overhead required to make it > work) at all. > > > goog.inherits and goog.base are IMHO not needed at all. In JS code > > generated from ActionScript, what goog.base does can be expressed by a > > direct function call (see my prototype). goog.inherits is replaced by my > > defineClass() utility, which consists of just 60 lines of code and > supports > > many more AS3 language features than just inheritance. I also had an > > alternative "VanillaJS" version that did not even use a helper method for > > inheritance (since it is so easy using ES5 API), but adding the other > > language feature, I found that this introduced too much repetitive, > boiler > > plate code. > > Again: personal preference, but I prefer the readability and > consistency that comes from using "goog" for this. And I don't see > (other than stepping into, instead of over the lines with "goog") any > real difference in using one utility method over another. Let's > revisit this when I have had the chance to mock up some more code so > we can compare "intermediate" JS formats. > > > One thing I'd like to know: can you use the Closure Tools *completely > > without* using the goog library in your JS code and still achieve > > ADVANCED_OPTIMIZATIONS? If not, I think that is exactly where the > > vendor-lock-in comes into play. > > Yes. > > > See above. When talking about 1500 lines of code, I don't worry about > code > > size, but about complexity that shines through during debugging. > > Step over? > > >> *tool/vendor dependency:* The Google Closure Tools are Open Source, > >> available under the Apache License 2.0. > >> > > > > I know that. Still, it is Google's own interpretation of modules, > > inheritance, ... for which there are at least partially standards in > > JavaScript (ECMAScript 5, AMD). > > Well, all code is someones interpretation of a requirement. And I > think that for suppliers of frameworks (like Google and ourselves), > that "partially" that you so casually throw in there really makes a > difference. I'm sure no-one with a corporate client is willing to > ditch IE 8 support "just yet". As long as Windows XP still holds at > least a third of the total OS market share, that browser isn't going > anywhere soon. > > > To make the UI framework run cross-browser, I have no objections against > > using an existing JavaScript framework. But this is my point when talking > > about "separations of concerns". I wouldn't hard-wire the pure language > > translation to "goog" just because it is a good base for a cross browser > UI > > framework. And any UI framework should be compatible with VanillaJS! > > A difference in approach, I guess. You focus on a single requirement > and select the best tool for that, ending up with lots of tools when > the number of requirements increase. I tend to look at the larger > picture and select a tool that is best for the overall job... And > knowing the kind of products Google has produced and maintained - > using large teams, many different coders on one project - with that > tool, I'm pretty confident it will serve this project very well > indeed. > > > What makes a difference to me is that to link with RequireJS, you do not > > have use a RequireJS-specific syntax, but an AMD-specific one. They > > separate syntax and implementation, which GCC apparently doesn't. > > GCC does not need specific syntax. It offers you the ability to add > annotation (but doesn't require it!) in order to help it do a better > job, but it will do an excellent job on vanilla JS as well. > > > Yes, that's my point. I argue that it does *too much* in one tool, so we > > don't have fine-grained control over the code generation process. > > Actually, I'm talking about the complete set of Closure Tools: JSDoc > annotations, Library, Compiler and Builder. That's 4 tools tailored to > work together, but at least the Library and the Compiler are > separately and independently usable. However, used together they > complement each other in a way no other combination of tools I know of > does. > > > Yes, but the code is still generated (even if only in-memory) and parsed, > > which is an unnecessary overhead in any case. > > So you suggest we build our own optimiser/minifier (not an easy task, > it seems to me) and loose the ability to output "intermediate" code > just because we want to shave of (maybe, at most) a couple of seconds > from the compile time? > > > I'm talking about a new feature available so far in Chrome only to let > the > > browser debugger map the JavaScript code to the original source code, see > > for example > > http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ > > If this feature was present in all major browsers, there would no longer > be > > a need for a debuggable JavaScript code format if we generated source > maps. > > Firefox has published an implementation plan, but it may take a while. IE > > 10 will probably follow, now that Microsoft pushes TypeScript. > > Waiting for a non-standard feature to be implemented across browser > and JS VMs might take "a while" :-P > > EdB > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl >
