> 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
