google / closure-compiler-npm

Package for managing and documenting closure-compiler for use via npm
Apache License 2.0
333 stars 66 forks source link

Transition to closure-compiler-js #31

Closed appsforartists closed 8 years ago

appsforartists commented 8 years ago

The Closure Compiler JAR has been transpiled to JavaScript:

https://github.com/google/closure-compiler-js/issues/2

We should investigate how well it works with this library, perhaps providing it as an option, or perhaps completely replacing the JAR. Since it's a transpilation, it should take the same command line arguments as the JAR.

From what I've heard, Java takes a while to start up, but runs faster. So, the performance tradeoff between the Node and JVM versions will depend on how big the compilation jobs are relative to the startup cost of the JVM.

ChadKillingsworth commented 8 years ago

Sweet I've been waiting for this. @Dominator008 had been working on it, but this is the first I've seen that it's ready.

I'll see what we can do with this. I will probably have a lot of questions.

MatrixFrog commented 8 years ago

Yup, @samthor got closure-compiler-js onto npm, but we haven't wanted to make a lot of noise about it just yet since there may be subtle bugs / differences from the Java version, the interface for it may change, we don't have a good idea of how well it performs, etc. That said, he will be announcing it more loudly soon, with the caveat that it's still experimental at this point. Some informal tests done several months ago suggest that small compilations are faster with the JS version (no JVM startup cost) while larger compilations are faster with the Java version.

ChadKillingsworth commented 8 years ago

So at Monday's meeting, let's discuss the future and revisit whether this repo should be moved to the Google org. In the mean time, I'll try to find time to play around with integrating the pure-js version as a non-default option in this repo.

samthor commented 8 years ago

So my uneducated opinion is that we might still want both options since they have unique performance characteristics.

I'm also happy to have contributions to closure-compiler-js because right now it is just a single compile method.

appsforartists commented 8 years ago

Crap. I totally opened this in the wrong repo.

But yay - still helpful!

ChadKillingsworth commented 8 years ago

@appsforartists You're good - this repo was as good a place as any. Most of the compiler team monitors this repo as well.

Our npm usage has also been climbing steadily: https://npm-stat.com/charts.html?package=google-closure-compiler

appsforartists commented 8 years ago

I meant to open it on webpack-closure-compiler, but I should check with Sam and Tyler first to make sure I'm not spreading too much word. 😝

ChadKillingsworth commented 8 years ago

Ahh I see. One of the reasons I bundled the grunt and gulp plugins into this repo is frequently users care more about which compiler version they are using than the plugin version. It's hard to specify versions with npm in a way that gives users that control separate from plugin features.

Looking at the webpack plugin - they have exactly that problem. https://github.com/roman01la/webpack-closure-compiler/blob/master/package.json#L23