Google Closure and CommonJS

I would love to use CommonJS modules syntax (require and module.exports) for Google Closure Library. Why?

• Because I want to write code, which everyone can use even without Closure.
• I want to use Closure Library and Compiler for Node.js code too.
• I want to use Node.js code in browser.

tl;dr We don’t need CommonJS for that. Read whole story:

Sure I can write smart task to migrate Closure Library to CommonJS, but I don’t want it. The main reason is that (Este.js) does not need it, let me explain leter. The second reason is, CommonJS in browser is slow and always will be. We can use Browserify but it’s way slower than goog.provide and goog.require. It’s because Browserify needs to parse whole source code to get its AST and initial load can take minutes for large project, which is clearly not acceptable. I can imagine some crazy caching approach but, it would not work for deploy build and, we don’t need it anyway.

goog.provide and goog.require is and probably always will be the fastest way to (re)build aplication for developement. Read why. tl;dr Closure is using regular expression instead of code parsing.

How to write Closure code that everyone can use without Closure dev stack itself.

Compile it and publish compiled output as classic NPM module. Done.

Remember, you should never write code for specific Angular/Grunt/Gulp ecosystem. Don’t make the same mistake I made with my Grunt plugins. I wrote code directly for Grunt, and when I later decided to port them to Gulp, I have to rewrite everything. Wrong. For instance take a look at steida/closure-dicontainer and steida/gulp-closure-compiler. First I wrote NPM module, then I wrote wrapper for Gulp. You got it.

So what If I decided to publish este/router? I would create separate repo, with este-library as bower dependency and package.json to export compiled Router. Done.

How to use Closure Library and Compiler in Node.js?

Take a look at github.com/steida/este/tree/master/app/server. I decided to write Node.js code in Closure style. It has these advantages: Super fast deploy (only compiled code is deployed) and of course, great compiler static check. And we can still use Node.js require ofc. Externs are included.

Node.js code in browser

Browserify. It’s defacto standard. But there is a aforementioned performance problem. It’s slow as hell. So what we can do with it? Use it anyway, but smartly. We need to rebuild everything only for extenal code and only once. For instance, we would like to use jprichardson/string.js, how? Add it via npm install, then use browserify to get browser version, then add output file via gulpfile. Well configured and tuned stack do the rest.

Why not AMD?

Because it’s slow, old, over-engineered, and it’s dying. Whole JS world is moving towards CommonJS. And we don’t need AMD, when we have Closure.

ES6?

Closure Compiler will support it, which is another reason I decided to not add CommonJS directly inside library. Let’s wait what Google will do.

Verdict

I designed Este.js to be super fast. I am continuously evaluating all options and carefully listening all Este.js users. I will not add CommonJS until Google itself decide how. And I hope explained why we do not need it now anyway.