These are a lot of the reasons why I chose RequireJS over Google Closure for my JavaScript work.
Just saying. -omar On Sunday, January 27, 2013, Frank Wienberg wrote: > On Sat, Jan 26, 2013 at 7:55 AM, Erik de Bruin > <e...@ixsoftware.nl<javascript:;>> > wrote: > > > > code and vice versa. I still think that RequireJS is the better choice, > > as > > > Closure implements *synchronous* require() which does not work > > dynamically > > > in the browser, and the Closure Library comes with many many more > > features, > > > > I really wish you would stop saying this. It is simply not true. > > Please look at the 'js-intermediate' output to see how 'base.js' > > dynamically loads only those files from the 'goog' library it actually > > uses, in the order needed to allow proper instantiation. How is that > > different from RequireJS? > > > > No, I won't stop saying this. (I'm a bit stubborn, you know.) Maybe I'll > stop saying it like above, as this is a very short and simplified form, > which I just chose because I thought we had this discussion before. But I > am willing to pick it up again, and I hope you are, too. > > That your prototype uses goog.require() and works in the browser is fine, > but it is not a proof that this is the best approach. > > I am arguing from a conceptual viewpoint: how can a module loader that uses > *synchronous* require load scripts dynamically, as needed, in the browser, > where everything can only be loaded asynchronously? When looking at this > Google Closure "Getting > Started"<https://developers.google.com/closure/library/docs/gettingstarted > >, > I understand that > goog.require("Foo"); > var foo = new Foo(); > can only work if you split it into two scripts (one doing the require, one > using it) or, in your build process, apply the GoogleBuilder tool that > analyzes the code so that the required script is loaded in advance. The > only solution I can think of to make the above example work *as-is* in the > browser would be to do it like Sencha Ext 4 and, in "development mode", > load code via a *synchronous* XHR and then using eval() on the response > text, both of which sounds evil to me. > > So to make JavaScript code written the "goog" way actually work in the > browser, you need the GoogleBuilder / Google Closure Compiler tool, right? > > RequireJS is different in that it respects the browser's nature of loading > things asynchronously. Thus, it is built into the concept of *Asynchronous* > Module Definitions (AMD) that script loading needs a callback: > require(["scriptA", "scriptB"], function() { ... }); Also see > http://requirejs.org/docs/whyamd.html > > > > Also, how is 'many, many more features' a bad thing? > > > > That statement was too general, sorry. I wouldn't have a problem with > Closure having many (optional) features. 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. > > In contrast, RequireJS introduces its Domain-Specific Language for modules > and module dependencies purely based on original JavaScript language > constructs, namely functions. You need no annotations and no build tool to > make the JavaScript code run in the browser as-is, only a library written > in JavaScript, too (require.js or almond.js or any of the many other > implementations). Only to optimize all module scripts into one or several > larger chunks, you need to use the provided build tool (r.js). Even this > build tool does not do much magic, but is only needed to allow the > syntactic sugar to not repeat the module name in the module JS code (it > deduces the module name from the file name when concatenating scripts). > Since we generate the JS code and manage dependencies ourselves, we could > easily add the module name and concatenate the needed scripts ourselves. > Another advantage of AMD is that it does not rely on global variables, but > hands over module references into the callback function's parameters: > require(["com/acme/very/long/Foo"], function(Foo) { /* access > com.acme.very.long.Foo as Foo */ }); These are more efficient to access > without any optimization, and can easily be further optimized (e.g. > abbreviate a long class name) by any JavaScript minifier that is capable of > shortening local variables. > > Goggle Closure library + compiler work on many different conceptual levels, > so you don't "buy" a module management system, but a complete JavaScript > (and beyond) ecosystem. It's a matter of choice, but I am more the > standards / modular / cherry-picking type and don't like to rely on an > all-in-one solution by a specific vendor, especially in the JavaScript > world where there are always many alternative libraries / frameworks to > chose from. (So there we also have a connection to the original topic of > this thread ;-)!) > > > > > > Please take a look at the proof of concept (both the intermediate and > > release code) before making these kinds of statements. > > > > I'd like to, but you admitted yourself that it has quite an initial > overhead to set up. Could you perhaps set up an online demo where one can > observe a running system? Or a download of the compiled application? At > least that's what I did for the AMD approach: > > * pure JavaScript prototype: > http://fwienber.github.com/as-js-runtime-prototype/index.html > * Open Flash Chart demo, compiled with Jangaroo 3: > http://jangaron.net/ofc5/data-files/joo.html#joo.debug > > Greetings > -Frank- >
