> We are basically using Closure Library based on Erik’s recommendation, but > at the time I still wanted to support IE8. We are now making the minimum > IE9 because we want decent SVG support and Object.defineProperties. So, > now is a good time to revisit how much of Closure Library we need. IIRC, > we are using > > -goog.events: This gets us a decent event model on non-DOM objects. > -goog.provide/require: This gets us a way to order the loading of multiple > JS files which I find useful when debugging JS code during development. > -goog.inherits: This provides a way to set up inheritance and call base > class methods. > > I might be forgetting something. Hopefully Erik as time to offer his > thoughts.
Well, using the Closure Library to support FlexJS helps us in several ways, but I think the most important one is that it allows the Google Closure compiler to get the most out of it's re-compilation of the JS. Following the GC coding conventions (mostly for OOP) and using the GC JSDoc annotations allows us to get really the most out of the GCC. On the other hand, FlexJS has not been using the above abilities to the max. The use of '@expose' for public properties (an annotation that is now deprecated in the GCC, by the way) and the new 'non-collapsable' (underscore) namespaces really works against the GCC. So maybe another minimizer might achieve the same gains as the handicapped GCC. So maybe it's time for FlexJS to reconsider this dependency... But for VFJS I'm planning on using the GC tools to the max, going back to dot notation and discarding '@expose'. And a final thought: if you get rid of the GC tools, what comes in their place? Some other library? That seems to be silly, why change one for another? And if you're going to roll your own... good luck. Especially the event handling will prove 'interesting', I'm sure ;-) EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
