4 ms·

Why is the closure library not as popular as other alternatives (ex: jquery)? It looks like a solid library, used by gmail, google docs and other google apps, I

Why is the closure library not as popular as other alternatives (ex: jquery)? It looks like a solid library, used by gmail, google docs and other google apps, I'm guessing is the java requirement for the compiler.

drcode 11y ago
You can't write regular code to take advantage of its advanced features- It requires you to program in a strict subset of regular javascript, and that is a bit of a PITA.
thomasfoster96 11y ago
The Java requirement is a real pain. If someone made an npm package that took care of the Java requirements, we'd probably all be using Closure rather than something like Uglify. Closure usually does slightly better minification wise, but it's a pain to work with.
- dkarapetyan 11y ago
  Huh? I mean I'm a little confused. The js ecosystem is full of transpilers, build tools, frameworks, and a bunch of package managers but installing java is one too many?
  - thomasfoster96 11y ago
    Well all those build tools are usually npm packages, and are easily managed as dependencies using package.json (hence why there are so many being used). Adding Java and and a secondary set of dependencies isn't really worth the 5% decrease in minified file size that closure might give you. I did try to use closure instead of uglify in a project recently - closure was a real pain to deal with compared to tools with equivalent functionality that are written in JavaScript. Cross-language ecosystem tools rarely work well it seems.
    - cromwellian 11y ago
      I don't see why the language the tool is written in matters. Lots of NPM modules have native C dependencies and it works fine. Closure advanced mode will do a lot better than 5% compared with Uglify.
      - thomasfoster96 11y ago
        It shouldn't matter - but it does. Native dependencies are pretty important so a lot of effort has gone into solving that issue - but I don't think making Java and Node.js work together well is a high priority for anyone. That said, closure being in JavaScript has more to do with choosing rhino than anything else. If you were starting a project like closure today you wouldn't use Java. Re: advanced mode, totally depends on what kind of code you've got. Lots of inlineable functions and constants? Double digits easily. Lots of objects and DOM? 5% better than uglify is optimistic.
        cromwellian 11y ago
        Actually if it was started at Google today, it probably would use Java or Go. Very few development tools are written in JS at Google. Angular and Polymer (and maybe Traceur) build tools being the exception. Our internal tooling works far better with statically typed languages. It should be rather trivial to have a gulp/grunt task that installs Java and runs CC. CC could even be packaged as a EXE if desired.
      - hokkos 11y ago
        It works fine because node take care of compiling it and lot of packages in npm need it so you are practically forced to install a C / C++ compiler, but java here is almost alone, so the requirement is more painfull.
masklinn 11y ago
Because really taking advantage of it (enabling advanced compilation options) requires using a fairly specific subset of the language otherwise it will DCE half the project. Integration with "regular" javascript libraries can also be annoying. ClojureScript uses Closure as an optimisation backend, since the primary cljs compiler is already in java.
- chrisoakman 11y ago
  FYI - I'm fairly certain that CLJS does not use Google Closure because it is "already in java", but rather because of it's maturity and awesome features like DCE. https://github.com/clojure/clojurescript/wiki/Rationale#google-leads-the-way https://github.com/clojure/clojurescript/wiki/Rationale#goog...
  - masklinn 11y ago
    This and that are not exclusive. There are good reasons to use closure, but would integrating closure and the tooling it requires even have been considered had the cljs compiler been in anything but java? How many alt.js languages implemented in !java use closure?
munro 11y ago
When playing with this library, I had the same thought because it provides such powerful static analysis. JSDoc generation is nice. There's even externs for common libraries like Node.js core [1]. I stopped working with it (for now at least), because I couldn't figure out how to get my Node.js library to compile correctly. So at least for me the learning curve was a barrier to use it. [1] https://github.com/dcodeIO/node.js-closure-compiler-externs https://github.com/dcodeIO/node.js-closure-compiler-externs
Touche 11y ago
Because no one likes to code in the style it requires.

drcode 11y ago

You can't write regular code to take advantage of its advanced features- It requires you to program in a strict subset of regular javascript, and that is a bit of a PITA.

thomasfoster96 11y ago

The Java requirement is a real pain. If someone made an npm package that took care of the Java requirements, we'd probably all be using Closure rather than something like Uglify. Closure usually does slightly better minification wise, but it's a pain to work with.

dkarapetyan 11y ago
Huh? I mean I'm a little confused. The js ecosystem is full of transpilers, build tools, frameworks, and a bunch of package managers but installing java is one too many?
- thomasfoster96 11y ago
  Well all those build tools are usually npm packages, and are easily managed as dependencies using package.json (hence why there are so many being used). Adding Java and and a secondary set of dependencies isn't really worth the 5% decrease in minified file size that closure might give you. I did try to use closure instead of uglify in a project recently - closure was a real pain to deal with compared to tools with equivalent functionality that are written in JavaScript. Cross-language ecosystem tools rarely work well it seems.
  - cromwellian 11y ago
    I don't see why the language the tool is written in matters. Lots of NPM modules have native C dependencies and it works fine. Closure advanced mode will do a lot better than 5% compared with Uglify.
    - thomasfoster96 11y ago
      It shouldn't matter - but it does. Native dependencies are pretty important so a lot of effort has gone into solving that issue - but I don't think making Java and Node.js work together well is a high priority for anyone. That said, closure being in JavaScript has more to do with choosing rhino than anything else. If you were starting a project like closure today you wouldn't use Java. Re: advanced mode, totally depends on what kind of code you've got. Lots of inlineable functions and constants? Double digits easily. Lots of objects and DOM? 5% better than uglify is optimistic.
      - cromwellian 11y ago
        Actually if it was started at Google today, it probably would use Java or Go. Very few development tools are written in JS at Google. Angular and Polymer (and maybe Traceur) build tools being the exception. Our internal tooling works far better with statically typed languages. It should be rather trivial to have a gulp/grunt task that installs Java and runs CC. CC could even be packaged as a EXE if desired.
    - hokkos 11y ago
      It works fine because node take care of compiling it and lot of packages in npm need it so you are practically forced to install a C / C++ compiler, but java here is almost alone, so the requirement is more painfull.

masklinn 11y ago

Because really taking advantage of it (enabling advanced compilation options) requires using a fairly specific subset of the language otherwise it will DCE half the project. Integration with "regular" javascript libraries can also be annoying. ClojureScript uses Closure as an optimisation backend, since the primary cljs compiler is already in java.

chrisoakman 11y ago
FYI - I'm fairly certain that CLJS does not use Google Closure because it is "already in java", but rather because of it's maturity and awesome features like DCE. https://github.com/clojure/clojurescript/wiki/Rationale#google-leads-the-way https://github.com/clojure/clojurescript/wiki/Rationale#goog...
- masklinn 11y ago
  This and that are not exclusive. There are good reasons to use closure, but would integrating closure and the tooling it requires even have been considered had the cljs compiler been in anything but java? How many alt.js languages implemented in !java use closure?

munro 11y ago

When playing with this library, I had the same thought because it provides such powerful static analysis. JSDoc generation is nice. There's even externs for common libraries like Node.js core [1]. I stopped working with it (for now at least), because I couldn't figure out how to get my Node.js library to compile correctly. So at least for me the learning curve was a barrier to use it. [1] https://github.com/dcodeIO/node.js-closure-compiler-externs https://github.com/dcodeIO/node.js-closure-compiler-externs

Touche 11y ago

Because no one likes to code in the style it requires.