Transpiling to JavaScript causes problems

[alexeagle]

Many users don't have Java on their machines anymore. Installing it is slow and confusing and a major blocker to adoption. Currently Closure Compiler uses GWT to transpile to a native JS distro.

There are a bunch of bugs with the current approach.

• GWT unicode support J2CL transpiled compiler Scanner.java doesn't understand non-ascii characters. #2383
• Node process runs out of heap memory Node process runs out of memory closure-compiler-js#23
• Not 100% feature compatible [citation needed]

Aside from these bugs, supporting compiling to JS is an unnecessary distraction for the core team. Will you chase down the long tail of compatibility issues? What if we just stopped doing this?

Users may also want to use Bazel. (Angular has announced at ngConf day3 keynote that we'll push this.) So we still need a way to get a Java runtime onto their machines.
Bazel is about to release their solution to this problem:
bazelbuild/bazel#1666

The approach:

• ship an OpenJDK JRE to npm (for the three major architectures, windows, darwin x64, linux x64)
• either statically link it into the google-closure-compiler package or make it a separate peerDependency
• closure compiler binary runs Java without the user needing to know about it.

[kylecordes]

This is a potentially good idea, if the machinery is smart enough to use an already present JRE. Other than the folks selling hard drives, noone wants to expand the NPM install-another-copy-of-everything-in-every-package approach to installing another JRE for every Angular project on a dev's machine(!).

This approach is an interesting symmetry to what folks are doing from the Java side of things - a Maven package (Maven plugin) that installs a local Node for gulp/grunt/etc based sub-project builds.

https://github.com/eirslett/frontend-maven-plugin

It's not clear to me whether Maven or NPM deserves the topmost position as the package manager / ecosystem which installs a local copy of the other as needed. I imagine by 2018 there will be projects which install multiple nested copies of various JRE and Node versions using these mechanisms!

[MatrixFrog]

We're not really spending time on the JS version. We have it marked as "experimental" or something along those lines, and probably will keep it that way indefinitely. I think it makes sense for Angular to recommend to its users Bazel plus the Java version of the compiler.

[alexeagle]

@MatrixFrog I sat with a user yesterday at ngConf and spent the majority of the time installing Java over conference wifi. We'll recommend the Java version of the compiler, but still need to axe the Java installation step.
Just because they have Bazel on the machine doesn't give us a good way of running Closure (unless we do ../../../path/to/bazel/external/location/of/jre/java closure.jar

Why keep an "experimental" broken thing laying around? You're still getting new issues on the closure-compiler-js repo. We could resolve all those issues if closure-compiler-js used Java under the covers.

[Dominator008]

The JS version should work for most use cases so I don't think it's broken. Getting the Bazel integration working better and recommending it over the JS version is an orthogonal issue.

[MatrixFrog]

I would object to your characterization as "broken". There are some bugs. Some of those bugs will be a deal-breaker for some users. Most of them will probably get fixed eventually; the "experimental" labels serves primarily as a signal that they are not a priority for us at this time.

[dimvar]

@alexeagle due to lack of resources, we can't spend time on the JS version for the next few months.

[ChadKillingsworth]

First off let me say that I'm very excited about the public Bazel support. Using bazel with a front-end package has seemed like an incredibly powerful tool - but one that was a secondary thought.

As for using the Java version of the compiler - that is also the correct choice (though I fear it may be unpopular as there is a large population of NO JAVA ON MY MACHINE devs).

However, the idea of installing a JVM via npm is absolutely not a good idea. Prior to me creating the official NPM distribution of closure-compiler, one of the most popular plugins installed a JVM along with it. The experience was nothing but horrible. Bloated downloads and long post-install scripts are all part of what makes front-end developers dislike Java. In addition, if you aren't shipping some kind of auto-update facility, then it's just asking to create security issues.

For windows and Mac, the Java install is very easy and painless. Yes it's an extra step, but I've never had a developer have problems. For other unix based systems, it is admittedly a bit more work - but that's a good description for those OS's in the first place. Time would be much better spent using nailgun or drip to prevent incurring the JVM startup penalty for each small compile job.

As stated, the JS version of the compiler isn't really maintained by the closure-compiler team. And I can definitely say it's presence doesn't impede development on the java version in any way (though I do share your concerns about the gwt compilation process).

If you would like to help add a postinstall script to the java distribution to check for a compatible JRE and give install instructions if missing, I think that would be great. Feel free to file an issue at https://github.com/google/closure-compiler-npm and we can see what we can get done.

I'm closing this particular issue however as it's clear that the JS version isn't the destraction that has been assumed.